微服务定义
过去几年中出现了“微服务架构”这一术语，它描述了将软件应用程序设计为可独立部署的服务套件的特定方法。虽然没有对这种架构风格的精确定义，但围绕业务能力，自动部署，端点智能以及语言和数据的分散控制等组织存在某些共同特征。
“微服务” - 在拥挤的软件架构街道上又一个新名词。虽然我们的自然倾向是通过轻蔑的眼神来传递这些东西，但这一点术语描述了一种我们发现越来越有吸引力的软件系统的风格。我们已经看到许多项目在过去几年中使用了这种风格，到目前为止的结果是积极的，以至于对于我们的许多同事而言，这已经成为构建企业应用程序的默认风格。然而，遗憾的是，没有太多信息可以概述微服务的风格以及如何实现。
简而言之，微服务架构风格是一种将单个应用程序开发为一套小型服务的方法，每个小型服务都在自己的流程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。这些服务围绕业务功能构建，可通过全自动部署机制独立部署。对这些服务的集中管理几乎是最低限度的，可以用不同的编程语言编写，并使用不同的数据存储技术。
为了开始解释微服务风格，将它与单片风格进行比较是有用的：作为单个单元构建的单片应用程序。企业应用程序通常由三个主要部分构成：客户端用户界面（由用户机器上的浏览器中运行的HTML页面和javascript组成）数据库（由插入到公共数据库管理中的许多表组成，通常是关系数据库管理系统）和服务器端应用程序。服务器端应用程序将处理HTTP请求，执行域逻辑，从数据库检索和更新数据，以及选择和填充要发送到浏览器的HTML视图。这个服务器端应用程序是一个整体 - 一个逻辑可执行文件。对系统的任何更改都涉及构建和部署新版本的服务器端应用程序。
这种单片服务器是构建这种系统的自然方式。处理请求的所有逻辑都在一个进程中运行，允许您使用语言的基本功能将应用程序划分为类，函数和命名空间。需要注意的是，您可以在开发人员的笔记本电脑上运行和测试应用程序，并使用部署管道确保对更改进行适当测试并将其部署到生产环境中。您可以通过在负载均衡器后面运行许多实例来水平扩展整体。
单片应用程序可以取得成功，但越来越多的人对它们感到沮丧 - 特别是随着更多应用程序被部署到云中。变更周期联系在一起 - 对应用程序的一小部分进行了更改，需要重建和部署整个整体。随着时间的推移，通常很难保持良好的模块化结构，使得更难以保持应该只影响该模块中的一个模块的更改。扩展需要扩展整个应用程序，而不是需要更多资源的部分。
这些挫折导致了微服务架构风格：将应用程序构建为服务套件。除了服务可独立部署和扩展的事实之外，每个服务还提供了牢固的模块边界，甚至允许以不同的编程语言编写不同的服务。他们也可以由不同的团队管理。
我们并不认为微服务风格是新颖的或创新的，其根源至少可以归结为Unix的设计原则。但我们认为没有足够的人考虑微服务架构，如果使用它们，许多软件开发会更好。
微服务架构的特征
我们不能说微服务架构风格有正式的定义，但我们可以尝试描述我们认为适合标签的架构的共同特征。与概述共同特征的任何定义一样，并非所有微服务架构都具有所有特征，但我们确实期望大多数微服务架构具有大多数特征。虽然我们的作者一直是这个相当宽松的社区的积极成员，但我们的目的是尝试描述我们在自己的工作中所看到的以及我们所知道的团队的类似努力。特别是我们没有规定一些符合的定义。
通过服务进行组件化
只要我们参与软件行业，就一直希望通过将组件集成在一起来构建系统，就像我们在物理世界中看到事物的方式一样。在过去的几十年中，我们已经看到了大多数语言平台的大型公共库的大量进展。
在谈论组件时，我们遇到了组件构成的困难定义。我们的定义是 组件是一个可独立更换和升级的软件单元。
微服务架构将使用库，但是他们将自己的软件组件化的主要方式是分解为服务。我们将库定义 为链接到程序中并使用内存中函数调用调用的组件，而服务是与Web服务请求或远程过程调用等机制进行通信的进程外组件。（这与许多面向对象程序中的服务对象的概念不同。）
将服务用作组件（而不是库）的一个主要原因是服务可以独立部署。如果您在单个进程中有一个由多个库组成的应用程序，则对任何单个组件的更改都会导致必须重新部署整个应用程序。但是，如果将该应用程序分解为多个服务，则可以预期许多单个服务更改仅需要重新部署该服务。这不是绝对的，一些变化将改变服务接口，从而产生一些协调，但良好的微服务架构的目标是通过服务合同中的紧密服务边界和演化机制来最小化这些。
将服务用作组件的另一个结果是更明确的组件接口。大多数语言没有很好的机制来定义显式的已发布接口。通常，它只是文档和规程，可以防止客户端破坏组件的封装，从而导致组件之间过于紧密的耦合。通过使用显式远程调用机制，服务可以更容易地避免这种情况。
使用这样的服务确实有缺点。远程调用比进程内调用更昂贵，因此远程API需要更粗糙，这通常更难以使用。如果您需要更改组件之间的职责分配，那么当您跨越流程边界时，这种行为的变化就更难。
在第一次近似中，我们可以观察到服务映射到运行时进程，但这只是第一次近似。服务可能包含多个始终一起开发和部署的进程，例如应用程序进程和仅由该服务使用的数据库。
围绕业务能力进行组织
在将大型应用程序拆分为多个部分时，通常管理侧重于技术层，从而导致UI团队，服务器端逻辑团队和数据库团队。当团队按照这些方式分开时，即使是简单的更改也可能导致跨团队项目需要时间和预算批准。一个聪明的团队将围绕这个进行优化，并为两个恶魔中的较小者提供丰富的优势 - 只需将逻辑强制转换为他们可以访问的任何应用程序。换句话说，逻辑无处不在。这是康威定律的一个例子。
设计系统（广泛定义）的任何组织都将生成一种设计，其结构是组织通信结构的副本。
微服务划分方法是不同的，分为围绕业务能力组织的服务 。此类服务为该业务领域采用广泛的软件实现，包括用户界面，持久存储和任何外部协作。因此，团队是跨职能的，包括开发所需的全部技能：用户体验，数据库和项目管理。
以这种方式组建的一家公司是www.comparethemarket.com。跨职能团队负责构建和运营每个产品，每个产品分为多个通过消息总线进行通信的单独服务。
大型单片应用程序也可以围绕业务功能进行模块化，尽管这不是常见的情况。当然，我们会敦促一个庞大的团队构建一个单一的应用程序，以便在业务线上划分自己。我们在这里看到的主要问题是，它们往往围绕太多的背景进行组织。如果整体跨越许多这些模块化边界，团队中的个体成员可能难以将它们放入短期记忆中。此外，我们看到模块化生产线需要大量的纪律来执行。服务组件所需的更明确的分离使得更容易保持团队边界清晰。
微服务有多大？
虽然“微服务”已经成为这种架构风格的流行名称，但它的名称确实导致了对服务规模的不幸关注以及关于什么构成“微观”的争论。在我们与微服务从业者的对话中，我们看到了一系列服务规模。报道的最大尺寸遵循亚马逊的Two Pizza Team的概念（即整个团队可以由两个比萨饼喂养），意味着不超过十几个人。在规模较小的规模上，我们已经看到了一个由六人组成的团队支持六项服务的设置。这导致了这样的问题：在这个尺寸范围内是否存在足够大的差异，即每个人的服务和每人服务的尺寸不应该集中在一个微服务标签下。目前我们认为将它们组合在一起会更好，但当我们进一步探索这种风格时，我们肯定会改变主意。
产品不是项目
我们看到的大多数应用程序开发工作都使用项目模型：其目的是提供一些软件然后被认为是完成的。完成后，软件将移交给维护组织，构建它的项目团队将被解散。
微服务支持者倾向于避免这种模式，而是倾向于认为团队应该在其整个生命周期内拥有产品。对此的一个共同启示是亚马逊的概念“你构建，运行它”，开发团队对生产中的软件负全部责任。这使开发人员能够日常接触他们的软件在生产中的行为，并增加与用户的联系，因为他们必须承担至少一些支持负担。
产品心态，与业务能力的联系紧密相连。不是将软件视为一组要完成的功能，而是存在一种持续的关系，其中的问题是软件如何帮助其用户增强业务能力。
没有理由为什么这种方法不能与单一应用程序一起使用，但较小的服务粒度可以使创建服务开发人员与其用户之间的个人关系变得更加容易。
智能端点和哑管
在不同流程之间建立沟通结构时，我们已经看到许多产品和方法都强调将重要的智慧放入沟通机制本身。一个很好的例子是企业服务总线（ESB），其中ESB产品通常包括用于消息路由，编排，转换和应用业务规则的复杂工具。
微服务社区倾向于采用另一种方法： 智能端点和哑管。从微服务构建的应用程序旨在尽可能地分离和凝聚 - 它们拥有自己的域逻辑，并且在经典的Unix意义上更多地充当过滤器 - 接收请求，适当地应用逻辑并产生响应。这些是使用简单的RESTish协议而不是复杂的协议（如WS-Choreography或BPEL或中央工具的编排）编排的。
最常用的两种协议是HTTP请求 - 响应资源API和轻量级消息传递。第一个最好的表达方式是做网络的主人，而不是网络背后的主人。
微服务团队使用万维网（在很大程度上，Unix）构建的原则和协议。经常使用的资源可以通过开发人员或操作人员的非常小的努力来缓存。
常用的第二种方法是通过轻量级消息总线进行消息传递。选择的基础设施通常是愚蠢的（如同仅作为消息路由器那样愚蠢） - 像RabbitMQ或ZeroMQ这样的简单实现不仅仅提供可靠的异步结构 - 智能仍然存在于生成和消费消息; 在服务中。
在整体中，组件在进程中执行，它们之间的通信是通过方法调用或函数调用。将整体变为微服务的最大问题在于改变通信模式。从内存中方法调用到RPC的简单转换导致繁琐的通信，这些通信效果不佳。相反，您需要用粗粒度的方法替换细粒度的通信。
去中心化治理
集中治理的后果之一是在单一技术平台上实现标准化的趋势。经验表明，这种方法是有限的 - 不是每个问题都是钉子，而不是每个解决方案都是锤子。我们更喜欢使用正确的工具来完成工作，而单片应用程序可以在一定程度上利用不同的语言，但这并不常见。
将monolith的组件拆分为服务，我们可以在构建每个组件时做出选择。您想使用Node.js站起来一个简单的报告页面吗？去吧。C ++是否适用于特别近乎实时的组件？精细。您想交换不同风格的数据库，以更好地适应一个组件的读取行为？我们有重建他的技术。
当然，仅仅因为你可以做某事，并不意味着你应该 - 但以这种方式对系统进行分区意味着你可以选择。
构建微服务的团队也更喜欢采用不同的标准方法。他们不是使用在纸上某处写下的一组定义标准，而是更愿意生成有用的工具，其他开发人员可以使用它来解决与他们面临的类似问题。这些工具通常从实现中收集并与更广泛的组共享，有时，但不仅仅是使用内部开源模型。现在git和github已成为事实上的版本控制系统，开源实践在内部变得越来越普遍。
Netflix是遵循这一理念的组织的一个很好的例子。共享有用的，最重要的是经过实战考验的代码，因为库鼓励其他开发人员以类似的方式解决类似问题，但如果需要，可以选择不同的方法。共享库往往侧重于数据存储，进程间通信的常见问题，我们将在下面进一步讨论基础架构自动化。
对于微服务社区来说，管理费用特别缺乏吸引力。这并不是说社区不重视服务合同。恰恰相反，因为往往会有更多。只是他们正在寻找管理这些合同的不同方式。模式，如 容错读者和消费者驱动的契约通常应用于微服务。这些援助服务合同独立发展。在构建过程中执行消费者驱动的合同可以增强信心，并提供有关您的服务是否正常运行的快速反馈。事实上，我们知道澳大利亚的一个团队通过消费者驱动的合同推动新服务的建设。他们使用简单的工具来定义服务合同。在编写新服务的代码之前，这将成为自动构建的一部分。然后，服务建立在满足合同的地步 - 避免'YAGNI'的优雅方法构建新软件时的两难选择。这些技术和围绕它们成长的工具通过减少服务之间的时间耦合来限制中央合同管理的需要。
也许分散治理的最高点是建立它/运行它由亚马逊推广的精神。团队负责他们构建的软件的所有方面，包括全天候运行软件。这种责任水平的下放绝对不是常态，但我们确实看到越来越多的公司将责任推向开发团队。Netflix是另一个采用这种精神的组织。每天晚上凌晨3点被您的寻呼机唤醒，无疑是在编写代码时专注于质量的强大动力。这些想法与传统的集中治理模式相差甚远。
去中心化管理
数据管理的分散化以多种不同的方式呈现。在最抽象的层面上，它意味着世界的概念模型在不同系统之间会有所不同。在整合大型企业时，这是一个常见问题，客户的销售视图将与支持视图不同。在销售视图中称为客户的某些内容可能根本不会出现在支持视图中。那些做的可能具有不同的属性和（更糟糕的）具有微妙不同语义的共同属性。
此问题在应用程序之间很常见，但也可能在应用程序中发生，特别是在将应用程序划分为单独的组件时。一种有用的思考方式是有界上下文的领域驱动设计概念 。DDD将复杂域划分为多个有界上下文，并映射出它们之间的关系。此过程对单片和微服务体系结构都很有用，但服务和上下文边界之间存在自然关联，这有助于澄清，正如我们在业务功能部分中所述，强化了分离。
除了关于概念模型的分散决策之外，微服务还分散了数据存储决策。虽然单一应用程序更喜欢使用单个逻辑数据库来存储持久性数据，但企业通常更喜欢在一系列应用程序中使用单个数据库 - 其中许多决策是通过供应商围绕许可的商业模型来实现的。微服务更喜欢让每个服务管理自己的数据库，可以是同一数据库技术的不同实例，也可以是完全不同的数据库系统 - 这种方法称为Polyglot Persistence。您可以在整体中使用多语言持久性，但它在微服务中更常出现。
跨微服务分散数据责任对管理更新有影响。处理更新的常用方法是在更新多个资源时使用事务来保证一致性。这种方法通常用于整体结构中。
使用这样的事务有助于保持一致性，但会产生显着的时间耦合，这在多个服务中是有问题的。众所周知，分布式事务很难实现，因此微服务架构强调服务之间的无事务协调，并明确认识到一致性可能只是最终的一致性，而问题通过补偿操作来处理。
选择以这种方式管理不一致是许多开发团队面临的新挑战，但它通常与业务实践相匹配。企业通常会处理一定程度的不一致，以便快速响应需求，同时采取某种逆转流程来应对错误。只要修复错误的成本低于在更大的一致性下丢失业务的成本，那么权衡是值得的。
基建自动化
基础设施自动化技术在过去几年中发生了巨大变化 - 特别是云和AWS的发展降低了构建，部署和运行微服务的操作复杂性。
许多使用微服务构建的产品或系统都是由具有丰富的持续交付经验的团队构建的，并且是前身的持续集成。以这种方式构建软件的团队广泛使用基础设施自动化技术。这在下面显示的构建管道中说明。
由于这不是关于持续交付的文章，我们将在这里引起注意几个关键功能。我们希望尽可能多的信心使我们的软件正常工作，因此我们进行了大量的自动化测试。推广工作软件“向上”管道意味着我们自动部署 到每个新环境。
一个单一的应用程序将非常愉快地构建，测试和推动通过这些环境。事实证明，一旦你投资自动化整体生产的生产之路，那么部署更多的应用程序似乎不再那么可怕了。请记住，CD的目标之一就是使部署无聊，所以无论是一个还是三个应用程序，只要它仍然无聊就无所谓。
我们看到团队使用广泛的基础设施自动化的另一个领域是管理生产中的微服务。与我们上面的断言相反，只要部署很无聊，单块和微服务之间没有太大的区别，每个部署的运营环境可能会截然不同。
设计失败
使用服务作为组件的结果是，需要设计应用程序以便它们能够容忍服务的失败。由于供应商不可用，任何服务呼叫都可能失败，客户必须尽可能优雅地对此做出响应。与单片设计相比，这是一个缺点，因为它引入了额外的复杂性来处理它。结果是微服务团队不断反思服务失败如何影响用户体验。Netflix的Simian Army 在工作日引发服务甚至数据中心的故障，以测试应用程序的弹性和监控。
这种生产中的自动化测试足以让大多数操作组在休息一周之前就会发抖。这并不是说整体式建筑风格不具备复杂的监控设置 - 在我们的经验中它不常见。
由于服务可能随时发生故障，因此能够快速检测故障并在可能的情况下自动恢复服务非常重要。微服务应用程序非常重视应用程序的实时监控，检查架构元素（数据库每秒获得多少请求）和业务相关度量（例如每分钟收到多少订单）。语义监控可以提供出现问题的早期预警系统，从而触发开发团队跟进和调查。
这对于微服务架构尤为重要，因为微服务对编排和事件协作的偏好 会导致紧急行为。虽然许多权威人士赞扬偶然出现的价值，但事实是，新兴行为有时可能是一件坏事。监控对于快速发现不良紧急行为至关重要，因此可以修复。
Monoliths可以像微服务一样透明 - 事实上，它们应该是。不同之处在于您绝对需要知道在不同进程中运行的服务何时断开连接。对于同一过程中的库，这种透明性不太可能有用。
微服务团队希望看到针对每个服务的复杂监控和日志记录设置，例如显示上/下状态的仪表板以及各种运营和业务相关指标。有关断路器状态，当前吞吐量和延迟的详细信息是我们经常遇到的其他示例。
进化设计
微服务从业者通常来自进化设计背景，并将服务分解视为进一步的工具，使应用程序开发人员能够控制应用程序中的更改，而不会降低变更速度。变更控制并不一定意味着改变 - 通过正确的态度和工具，您可以对软件进行频繁，快速和良好控制的更改。
每当您尝试将软件系统分解为组件时，您就面临着如何划分各个部分的决定 - 我们决定将应用程序分割的原则是什么？组件的关键属性是独立替换和可升级性的概念 - 这意味着我们寻找可以想象在不影响其协作者的情况下重写组件的点。实际上，许多微服务组通过明确期望许多服务被废弃而不是长期发展来进一步考虑这一点。
Guardian网站是一个设计和构建为整体的应用程序的一个很好的例子，但是已经在微服务方向上发展。monolith仍然是网站的核心，但他们更喜欢通过构建使用monolith API的微服务来添加新功能。这种方法对于本质上是临时的功能尤其方便，例如处理体育赛事的专用页面。网站的这一部分可以使用快速开发语言快速组合在一起，并在事件结束后删除。我们在金融机构看到了类似的方法，为市场机会添加新服务，并在几个月甚至几周后丢弃。
这种对可替换性的强调是模块化设计的更一般原则的一个特例，即通过变化模式驱动模块化。您希望在同一模块中保持同时更改的内容。很少变化的系统部分应该与目前正在经历大量流失的系统处于不同的服务中。如果您发现自己一再改变两项服务，那就表明它们应该合并。
将组件放入服务中可以为更细粒度的发布计划添加机会。对于整体，任何更改都需要完整构建和部署整个应用程序。但是，使用微服务，您只需要重新部署您修改的服务。这可以简化并加快发布过程。缺点是您必须担心一项服务的变化会打破其消费者。传统的集成方法是尝试使用版本控制来解决这个问题，但微服务领域的偏好是仅使用版本控制作为最后的手段。我们可以通过将服务设计为对供应商变更尽可能宽容来避免大量版本控制。
微服务是未来吗？
我们写这篇文章的主要目的是解释微服务的主要思想和原则。通过花时间来做到这一点，我们清楚地认为微服务架构风格是一个重要的想法 - 值得认真考虑企业应用程序。我们最近使用这种方式构建了几个系统，并了解其他已经使用并支持这种方法的系统。
我们知道谁在某种程度上开创了建筑风格，包括亚马逊，Netflix，卫报，英国政府数字服务，realestate.com.au，Forward和comparethemarket.com。2013年的会议电路充满了一些公司的例子，这些公司正在转向可以归类为微服务的公司 - 包括Travis CI。此外，有很多组织长期以来一直在做我们称之为微服务的东西，但没有使用过这个名字。（通常这被标记为SOA - 尽管如我们所说，SOA有许多相互矛盾的形式。
然而，尽管有这些积极的经验，但我们并不认为我们确信微服务是软件架构的未来发展方向。虽然到目前为止我们的经验与整体应用相比是积极的，但我们意识到没有足够的时间让我们做出充分的判断。
通常，您的架构决策的真正后果只有在您制作它们几年后才会明显。我们已经看到一个项目，一个优秀的团队，对模块化的强烈渴望，已经建立了一个多年来已经腐朽的单片架构。许多人认为微服务不太可能出现这种衰退，因为服务边界是明确的，很难修补。然而，在我们看到足够的系统具有足够的年龄之前，我们无法真正评估微服务架构是如何成熟的。
人们可能会期望微服务成熟得很好。在组件化的任何努力中，成功取决于软件在组件中的适用程度。很难弄清楚组件边界的确切位置。进化设计认识到正确边界的困难，因此很容易重构它们的重要性。但是当您的组件是具有远程通信的服务时，那么重构比使用进程内库要困难得多。跨服务边界移动代码很困难，需要在参与者之间协调任何接口更改，需要添加向后兼容性层，并且测试变得更加复杂。
另一个问题是如果组件没有干净地组成，那么您所做的就是将复杂性从组件内部转移到组件之间的连接。这不仅仅是移动复杂性，而是将其移动到一个不那么明确且难以控制的地方。当你在一个小而简单的组件内部查看时，很容易认为事情会更好，同时缺少服务之间的混乱连接。
最后，还有团队技能的因素。新技术往往被更熟练的团队所采用。但对于技能更高的团队来说，一种更有效的技术并不一定适用于技能较低的团队。我们已经看到很多不太熟练的团队构建混乱的单片架构，但是当微服务发生这种混乱时，需要花时间看看会发生什么。一个糟糕的团队总是会创建一个糟糕的系统 - 很难说微服务是否可以减少这种情况下的混乱或使情况变得更糟。
我们听到的一个合理的论点是，您不应该从微服务架构开始。相反， 从整体开始，保持模块化，并在整体成为问题时将其拆分为微服务。（虽然 这个建议并不理想，但是好的进程内接口通常不是一个好的服务接口。）
因此，我们谨慎乐观地写下这一点。到目前为止，我们已经看到了足够多的微服务风格，觉得它是 一条值得走的路。我们无法确定最终会在哪里结束，但软件开发的挑战之一是您只能根据您当前必须提供的不完善信息做出决策。