微服务介绍

原文作者：Sanchit Gera

原文地址：https://medium.freecodecamp.org/an-introduction-to-microservices-2705e7758f9?source=search_post

近年来，基于微服务模式的网络架构得到了广泛的应用。微服务已经成为大型、笨拙的单应用的解决方案。

这种设计试图解决当代码库增长超过一定规模时出现的问题，并且维护变得越来越困难的情况。

小规模服务是出于快速扩展的需要，同时仍然保持代码的可管理性。Netflix、亚马逊(Amazon)和Spotify都是一些规模更大、更有趣的公司，它们正朝着这种模式发展。让我们一下探索原因。

什么是微服务？

定义微服务是一件棘手的事情。为了被认为是“微”，您的代码库不应该满足任何设置要求或规范。相反，开发人员和架构师必须坚持一套通用的思想，才能设计出适合他们的系统。

微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在其自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。马丁福勒

在构建微服务中，Sam Newman列出了设计这些服务时必须牢记的两个关键思想：松耦合性和高内聚性。无可否认，这些话听起来更像是浮夸的字眼，但请允许我详细说明。

松耦合性

理想情况下，您希望服务在彼此之间几乎没有依赖关系。服务应该是可变的，可以独立部署，而不需要对系统的其他部分进行修改。

服务必须只公开绝对必要的信息，以防止使用其数据的应用程序与它们绑定得太紧。这使得在未来推出变更变得更容易。

高内聚性

高内聚可以被认为是松耦合的一个推论。内聚指的是，系统中与特定实体相关的所有逻辑都应该集中在一个地方。这使得修改系统的一部分行为更容易，因为它最小化了需要更新代码的位置。

重要的是要记住，没有任何关于单一结构会阻止你应用同样的原则。任何代码库都鼓励模块化。传统上，大型代码库依赖于共享模块和库的概念，以实施类似程度的逻辑分离。微服务更进一步，使这些界限更明显，也更难以打破。

诱导因素

为了理解微服务，您应该了解传统的单一结构中存在一些不足，这就是开发人员正在转向更松散耦合的服务的原因。

技术多样性

随着应用程序的规模越来越大，它实现的特性的数量也会越来越多，扩展开来，对系统的技术要求也会越来越多。

例如，应用程序的某些部分可能需要使用特定语言编写的特定库，而该库恰好是应用程序的正确工具。应用程序的某些部分可能受益于Java的静态类型、安全特性。而其他部分可能要求更少。类似地，最优数据库在不同的应用程序中可能存在很大的差异。

这也提供了一个在有​​限范围内尝试新语言和框架的好机会。从某种意义上来说，实验的风险较小，因为它仅限于能够相当快地恢复到原始状态的少数服务。

一般来说，在单应用程序中，您选择的工具最终通常是“最小公分母”，而不是针对当前的任务进行优化。

然而，这一切都有一个缺点。实际上，不同服务使用的大量框架和语言本身可能会变得一团糟。如果不熟悉新堆栈，那么在团队之间移动开发人员(通常是一个服务团队)可能是一场噩梦。

有趣的是，Spotify - 微服务架构模式的主要倡导者 - 在其产品服务中使用的各种语言上有一个零容忍政策。本质上，部署到生产环境中的每个服务都只能用Java编写(从而使这个参数失效)。

尽管如此，对于基于微服务的设计来说，技术多样性是一个关键的优势，即使只使用少量。

容错性

容错的思想与前面讨论的松耦合的概念密切相关。团队应该集中精力使每项服务尽可能独立。这确保了如果一个服务关闭，它不会影响其他服务（除了立即依赖它的服务）。

作为最终用户，您的体验可能会降级并受到限制，但应用程序仍应保持功能。在大多数情况下，这比整个应用程序崩溃要好得多。

以Amazon为例。假设Amazon由几个不同的服务组成，每个服务处理应用程序的关键部分。

• 库存服务：负责管理亚马逊销售的所有物品以及库存水平
• 订单服务：负责接收客户订单并派遣项目
• 推荐服务：负责提出有关客户可能感兴趣的产品的建议

这绝不是对亚马逊结构的完整或准确描述。但在这个例子中它很能说明问题。

考虑一下这样的场景:推荐服务崩溃了。现在，在传统的单一应用程序中，这可能会导致亚马逊的关闭！

然而，在目前的情况下，用户可能在没有任何推荐的情况下获得一个页面，而应用程序的其他部分则继续发挥同功能。这是次最佳体验，但仍然有效。不错!

可扩展性

对于一个快速发展的公司来说，可扩展性是一个非常重要的问题。当您有一个单一的大型应用程序时，并不是所有的部分都具有同等的负载强度。有些可能负责更被动、更普通的事情，比如服务静态信息，而另一些可能更密集，需要大量的数据库交互和/或计算能力。

单一代码库的问题在于，无论执行哪种不同类型的操作，都需要根据需求上下扩展整个应用程序。由于这不是您系统实际需求的准确表示，因此会导致大量浪费的计算能力和资源。

这是微服务试图解决的问题之一。因为功能被分割成不同的“盒子”，所以每个盒子可以独立地放大或缩小，而不会影响系统的其他部分。所以你最终从一个看起来像这样的系统开始：

易于部署

最后，让我们谈谈如何部署这些服务。考虑到正在部署的服务的数量，这在一开始可能有点像一个反论点。然而，需要记住的关键是，应用程序中特定部分的行为的任何更改通常都需要对应用程序的一个部分(最好是应用程序的一个部分)进行更改，在本例中，这些更改被隔离为一个微服务。

当您有一个小的变更时，这个差别可以归结为重新部署一个小的服务，而不是重新部署一个百万行的应用程序。实际上，单片应用程序很少以这种速度重新部署。因此，在发布版本之间通常会产生变化，从而产生更大、更全面的版本。部署的大量更改本身可能是一个潜在的风险。

但和往常一样，这里有一个权衡。尽管微服务允许您快速部署更改，但是它们需要您的服务的所有客户端与您的发布同步。如果依赖于您的服务的服务数量很少，那么这可能是微不足道的，但在较大的组织中，情况可能并非总是如此。可能会达成妥协，您可能最终会为依赖于它们的客户端支持先前版本的微服务，直到他们开始升级!