微服务

通过服务进行组件化

只要我们参与软件行业，就一直渴望通过将组件插入在一起来构建系统，就像我们在物质世界中看到事物的方式一样。在过去的几十年里，我们已经看到，作为大多数语言平台的一部分，常见的库的大量汇编取得了相当大的进展。

在谈论组件时，我们遇到了什么构成组件的困难定义。我们的定义是，组件是一个可以独立替换和升级的软件单元。

微服务架构将使用库，但它们组件化自身软件的主要方式是分解成服务。我们将库定义为链接到程序中并使用内存函数调用调用的组件，而服务是进程外组件，它们使用 Web 服务请求或远程过程调用等机制进行通信。（这与许多面向对象程序中的服务对象的概念不同 [3]。）

使用服务作为组件（而不是库）的一个主要原因是服务是可独立部署的。如果您有一个应用程序 [4]，它由单个进程中的多个库组成，那么对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果将该应用程序分解为多个服务，则您可以预期许多单一服务更改只需要重新部署该服务。这不是绝对的，有些更改会更改服务接口，从而导致一些协调，但良好的微服务架构的目标是通过内聚的服务边界和服务契约中的演进机制来最大程度地减少这些更改。

使用服务作为组件的另一个结果是更明确的组件接口。大多数语言都没有很好的机制来定义显式的 发布接口。通常，只有文档和纪律才能防止客户端破坏组件的封装，从而导致组件之间过度紧密的耦合。服务通过使用显式的远程调用机制，可以更容易地避免这种情况。

像这样使用服务确实有缺点。远程调用比进程内调用更昂贵，因此远程 API 需要更粗粒度，这通常更难使用。如果您需要更改组件之间的职责分配，那么在跨越进程边界时，这种行为的移动更难做到。

初步看来，我们可以观察到服务映射到运行时进程，但这只是一个初步的近似值。服务可能由多个进程组成，这些进程将始终一起开发和部署，例如应用程序进程和仅由该服务使用的数据库。

围绕业务能力组织

在寻求将大型应用程序拆分成多个部分时，管理层通常会关注技术层，从而导致 UI 团队、服务器端逻辑团队和数据库团队。当团队按照这些路线分开时，即使是简单的更改也可能导致跨团队项目需要时间和预算批准。一个聪明的团队会围绕这一点进行优化，并选择两害相权取其轻——只需将逻辑强制到他们可以访问的任何应用程序中。换句话说，逻辑无处不在。这是 康威定律 的一个例子。

任何设计系统（广义定义）的组织，其产生的设计结构都是该组织通信结构的副本。

——梅尔文·康威，1968 年

图 2：康威定律在行动

微服务方法的划分是不同的，它被划分为围绕业务能力组织的服务。此类服务采用该业务领域的软件的广泛堆栈实现，包括用户界面、持久存储和任何外部协作。因此，团队是跨职能的，包括开发所需的所有技能：用户体验、数据库和项目管理。

图 3：由团队边界强化的服务边界

一家以这种方式组织的公司是 www.comparethemarket.com。跨职能团队负责构建和运营每个产品，每个产品都被拆分为许多通过消息总线进行通信的独立服务。

大型单体应用程序也可以围绕业务能力进行模块化，尽管这并不常见。当然，我们建议构建单体应用程序的大型团队按照业务线进行划分。我们在这里看到的主要问题是，它们往往围绕着*太多*的上下文进行组织。如果单体跨越了许多这样的模块边界，团队中的个别成员可能难以将它们放入短期记忆中。此外，我们看到模块化线需要大量的纪律来执行。服务组件所需的更明确的分离使得团队边界更容易保持清晰。

产品而非项目

我们看到的大多数应用程序开发工作都使用项目模型：目标是交付一些软件，然后将其视为已完成。完成后，软件被移交给维护组织，构建它的项目团队被解散。

微服务支持者倾向于避免这种模式，而是更倾向于团队应该在其整个生命周期内拥有产品的理念。这种理念的一个常见灵感来自亚马逊的“你构建，你运行”的理念，即开发团队对生产环境中的软件负全部责任。这使得开发人员能够每天接触到他们的软件在生产环境中的行为，并增加与用户的联系，因为他们必须承担至少一部分的支持负担。

产品思维与业务能力的联系紧密相连。与其将软件视为一组要完成的功能，不如将其视为一种持续的关系，其中的问题是如何让软件帮助其用户增强业务能力。

单体应用程序没有理由不能采用同样的方法，但是服务的粒度越小，就越容易在服务开发人员和他们的用户之间建立个人关系。

智能端点和哑管道

在构建不同流程之间的通信结构时，我们已经看到许多产品和方法都强调在通信机制本身中加入重要的智能。企业服务总线（ESB）就是一个很好的例子，ESB产品通常包括用于消息路由、编排、转换和应用业务规则的复杂设施。

微服务社区倾向于另一种方法：*智能端点和哑管道*。由微服务构建的应用程序的目标是尽可能地解耦和内聚——它们拥有自己的域逻辑，并且更像是经典Unix意义上的过滤器——接收请求，根据需要应用逻辑并生成响应。这些是使用简单的RESTish协议而不是像WS-Choreography或BPEL这样的复杂协议或由中央工具进行编排的。

最常用的两种协议是带有资源API的HTTP请求-响应和轻量级消息传递[7]。第一个的最佳表达是

成为Web的一部分，而不是Web的背后

-- Ian Robinson

微服务团队使用构建万维网（以及在很大程度上，Unix）的原则和协议。经常使用的资源可以被缓存，而开发人员或运营人员几乎不需要付出任何努力。

第二种常用的方法是通过轻量级消息总线进行消息传递。所选择的基础设施通常是哑的（哑的意思是只充当消息路由器）——像RabbitMQ或ZeroMQ这样的简单实现除了提供可靠的异步结构之外，没有做太多其他的事情——智能仍然存在于生产和消费消息的端点中；在服务中。

在单体中，组件在进程内执行，它们之间的通信是通过方法调用或函数调用进行的。将单体更改为微服务的最大问题在于更改通信模式。将内存中的方法调用简单地转换为RPC会导致性能不佳的频繁通信。相反，您需要用粗粒度的方法来代替细粒度的通信。

去中心化治理

集中治理的后果之一是倾向于在单一技术平台上进行标准化。经验表明，这种方法是有限制的——并非所有问题都是钉子，并非所有解决方案都是锤子。我们更喜欢使用合适的工具来完成工作，虽然单体应用程序可以在一定程度上利用不同的语言，但这并不常见。

将单体的组件拆分为服务，我们在构建每个组件时都有选择。你想使用Node.js来建立一个简单的报表页面吗？放手去做吧。为一个特别棘手的近实时组件使用C++？没问题。你想换一种更适合一个组件的读取行为的数据库吗？我们有技术来重建它。

当然，仅仅因为你*可以*做某事，并不意味着你*应该*做——但是以这种方式对你的系统进行分区意味着你有选择。

构建微服务的团队也更喜欢不同的标准方法。他们不喜欢使用写在纸上的既定标准，而是更喜欢生成有用工具的想法，其他开发人员可以使用这些工具来解决他们面临的类似问题。这些工具通常是从实现中收集的，并与更广泛的群体共享，有时（但不限于）使用内部开源模型。现在，git和github已经成为事实上的首选版本控制系统，开源实践在企业内部正变得越来越普遍。

Netflix是一个遵循这种理念的组织的很好的例子。将有用且经过实战检验的代码作为库共享，鼓励其他开发人员以类似的方式解决类似的问题，但在需要时也为选择不同的方法敞开了大门。共享库往往侧重于数据存储、进程间通信以及我们在下面进一步讨论的基础设施自动化的常见问题。

对于微服务社区来说，开销特别不具吸引力。这并不是说社区不重视服务契约。恰恰相反，因为它们的数量往往要多得多。只是他们正在寻找不同的方式来管理这些契约。像*容错读取器*和*消费者驱动的契约*这样的模式通常应用于微服务。这些有助于服务契约独立发展。将执行消费者驱动的契约作为构建的一部分，可以增加信心，并提供关于服务是否正常运行的快速反馈。事实上，我们知道澳大利亚的一个团队使用消费者驱动的契约来驱动新服务的构建。他们使用简单的工具来定义服务的契约。这在编写新服务的代码之前就成为了自动化构建的一部分。然后，服务只构建到满足契约的程度——这是一种避免在构建新软件时出现“YAGNI”[8]困境的优雅方法。这些技术以及围绕它们不断发展的工具，通过减少服务之间的时间耦合，限制了对中央契约管理的需求。

也许，去中心化治理的顶峰是由亚马逊推广的“构建它/运行它”的精神。团队负责他们构建的软件的各个方面，包括全天候运营软件。这种责任下放绝对不是常态，但我们确实看到越来越多的公司将责任推向开发团队。Netflix是另一个采用这种理念的组织[10]。每天晚上都被你的寻呼机吵醒，这无疑是一个强大的动力，让你在编写代码时专注于质量。这些想法与传统的集中治理模式相去甚远。

去中心化数据管理

数据管理的去中心化以多种不同的方式呈现。在最抽象的层面上，这意味着世界观的概念模型在不同的系统之间会有所不同。这是在大型企业中进行集成时的一个常见问题，销售人员对客户的看法与支持人员的看法不同。在销售视图中被称为客户的某些东西可能根本不会出现在支持视图中。那些出现的客户可能具有不同的属性，并且（更糟糕的是）具有微妙不同的语义的通用属性。

这个问题在应用程序之间很常见，但也可能发生在应用程序*内部*，特别是当应用程序被划分为不同的组件时。考虑这个问题的一个有用方法是领域驱动设计中的*限界上下文*概念。DDD将一个复杂的领域划分为多个限界上下文，并绘制出它们之间的关系。这个过程对于单体和微服务架构都很有用，但是在服务和上下文边界之间存在自然的关联，这有助于澄清，并且正如我们在关于业务能力的部分中所描述的那样，加强了分离。

除了对概念模型的决策进行去中心化之外，微服务还对数据存储决策进行了去中心化。虽然单片应用程序更倾向于为持久数据使用单一逻辑数据库，但企业通常更倾向于在各种应用程序中使用单一数据库 - 其中许多决策是根据供应商围绕许可的商业模式做出的。微服务更倾向于让每个服务管理自己的数据库，无论是相同数据库技术的不同实例，还是完全不同的数据库系统 - 这种方法称为多语言持久化。您可以在单片架构中使用多语言持久化，但它在微服务中更为常见。

将跨微服务的数据责任分散会对更新管理产生影响。处理更新的常用方法是使用事务来保证更新多个资源时的一致性。这种方法经常在单片架构中使用。

像这样使用事务有助于保持一致性，但会造成显著的时间耦合，这在多个服务中是一个问题。众所周知，分布式事务难以实现，因此微服务架构强调服务之间无事务协调，并明确认识到一致性可能只是最终一致性，并且问题是通过补偿操作来解决的。

选择以这种方式管理不一致性对许多开发团队来说是一个新的挑战，但这通常与业务实践相一致。企业通常会处理一定程度的不一致性，以便快速响应需求，同时拥有一些逆向流程来处理错误。只要修复错误的成本低于在更高一致性下损失业务的成本，那么这种权衡就是值得的。

基础设施自动化

在过去几年中，基础设施自动化技术得到了极大的发展 - 云计算，特别是 AWS 的发展，降低了构建、部署和运营微服务的运营复杂性。

许多使用微服务构建的产品或系统是由具有丰富持续交付及其前身持续集成经验的团队构建的。以这种方式构建软件的团队广泛使用基础设施自动化技术。下图所示的构建管道说明了这一点。

图 5：基本构建管道

由于这不是一篇关于持续交付的文章，因此我们将在这里只关注几个关键特性。我们希望尽可能确信我们的软件能够正常工作，因此我们运行了大量的自动化测试。将工作软件“向上”提升到管道意味着我们将自动化部署到每个新环境。

一个单片应用程序将通过这些环境顺利地构建、测试和推送。事实证明，一旦您投资于自动化单片架构的生产路径，那么部署更多应用程序就不再那么可怕了。请记住，持续交付的目标之一是使部署变得枯燥乏味，所以无论是部署一个还是三个应用程序，只要它仍然枯燥乏味，那就无所谓了[11]。

我们看到团队在生产环境中管理微服务时广泛使用基础设施自动化的另一个领域是。与我们上面断言的只要部署枯燥乏味，单片架构和微服务之间就没有太大区别相反，每种架构的运营环境可能截然不同。

图 6：模块部署通常不同

为故障而设计

使用服务作为组件的结果是，需要对应用程序进行设计，使其能够容忍服务的故障。任何服务调用都可能由于供应商不可用而失败，客户端必须尽可能优雅地对此做出响应。与单片设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。因此，微服务团队不断反思服务故障如何影响用户体验。Netflix 的Simian Army会在工作日内引发服务甚至数据中心的故障，以测试应用程序的弹性和监控能力。

这种在生产环境中进行的自动化测试足以让大多数运营团队不寒而栗，通常是在休假一周之前。这并不是说单片架构风格不能进行复杂的监控设置 - 只是根据我们的经验，这种情况不太常见。

由于服务随时可能发生故障，因此能够快速检测故障并尽可能自动恢复服务非常重要。微服务应用程序非常重视应用程序的实时监控，检查架构元素（数据库每秒接收多少请求）和业务相关指标（例如每分钟收到多少订单）。语义监控可以提供早期预警系统，提醒开发团队进行跟进和调查。

这对微服务架构尤为重要，因为微服务倾向于编排和事件协作会导致紧急行为。虽然许多专家都称赞意外出现的价值，但事实是，紧急行为有时可能是一件坏事。监控对于快速发现不良紧急行为以便及时修复至关重要。

可以将单片架构构建为与微服务一样透明 - 事实上，它们应该如此。区别在于，您绝对需要知道在不同进程中运行的服务何时断开连接。对于同一进程中的库，这种透明性不太可能有用。

微服务团队希望看到每个服务的复杂监控和日志记录设置，例如显示正常运行时间/停机时间的仪表板，以及各种运营和业务相关指标。有关断路器状态、当前吞吐量和延迟的详细信息是我们经常遇到的其他示例。

演进式设计

微服务实践者通常来自演进式设计背景，并将服务分解视为一种额外的工具，使应用程序开发人员能够控制应用程序中的更改，而不会减缓更改速度。变更控制并不一定意味着减少变更 - 只要态度和工具正确，您就可以对软件进行频繁、快速且良好控制的变更。

每当您尝试将软件系统分解为组件时，您都面临着如何划分各个部分的决定 - 我们根据哪些原则来决定如何切分我们的应用程序？组件的关键属性是独立替换和可升级性的概念[12] - 这意味着我们要寻找可以想象在不影响其协作者的情况下重写组件的点。事实上，许多微服务团队更进一步，明确期望许多服务会被废弃，而不是在长期内进行演进。

《卫报》网站是一个很好的例子，它最初被设计和构建为一个单片应用程序，但一直在向微服务方向发展。单片架构仍然是网站的核心，但他们更喜欢通过构建使用单片架构 API 的微服务来添加新功能。这种方法对于本质上是临时的功能特别方便，例如处理体育赛事的专门页面。网站的这一部分可以使用快速开发语言快速拼凑起来，并在赛事结束后删除。我们已经在一家金融机构看到了类似的方法，其中会针对市场机会添加新服务，并在几个月甚至几周后弃用。

这种对可替换性的强调是更通用的模块化设计原则的一个特例，即通过变更模式来驱动模块化[13]。您希望将同时发生变化的内容保存在同一个模块中。很少发生变化的系统部分应该与当前正在经历大量变更的系统部分使用不同的服务。如果您发现自己反复地同时更改两个服务，那么这就是一个信号，表明它们应该合并。

将组件放入服务中为更精细的发布计划提供了机会。对于单片架构，任何更改都需要对整个应用程序进行完整的构建和部署。但是，对于微服务，您只需要重新部署您修改过的服务即可。这可以简化和加快发布过程。缺点是您必须担心对一个服务的更改会破坏其使用者。传统的集成方法是尝试使用版本控制来解决这个问题，但在微服务领域，人们更倾向于仅将版本控制作为最后的手段。我们可以通过设计服务以尽可能容忍其供应商的变化来避免大量的版本控制。