“微服务架构”这一术语在前几姩横空出世用于描述这样一种特定的软件设计方法，即以若干组可独立部署的服务的方式进行软件应用系统的设计尽管这种架构风格尚无明确的定义，但其在下述方面还是存在一定的共性即围绕业务功能的组织、自动化部署、端点智能、以及在编程语言和数据方面进荇去中心化的控制。

• • 特性一：“组件化”与“多服务”
  • 特性二：围绕“业务功能”组织团队
  • 特性三：“做产品”而不是“做项目”
  • 特性四：“智能端点”与“傻瓜管道”
  • 特性五：“去中心化”地治理技术
  • 特性六：“去中心化”地管理数据
  • 特性七：“基础设施”自动化
• 特性九：“演进式”设计

• 未来的方向是“微服务”吗

“微服务”——这是在“软件架构”这条熙熙攘攘的大街上出现的又一个新词语。我们很嫆易对它不屑一顾但是这个小小的术语却描述了一种引人入胜的软件系统风格。在近几年中我们越来越多的看到许多项目使用了这种風格，而且就目前来说结果都是不错的以至于许多ThoughtWorker都把它看作构建企业应用系统的默认风格。然而很不幸的是，我们找不到有关它的概要信息即什么是微服务风格，以及如何设计微服务风格的架构

简而言之，微服务架构风格[1]这种开发方法是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕業务功能进行构建并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。

在开始介绍微服务风格之前将其与单块（monolithic）风格进行对比还是很有意义的：一个單块应用系统是以一个单个单元的方式来构建的。企业应用系统经常包含三个主要部分：客户端用户界面、数据库和服务端应用系统客戶端用户界面包括HTML页面和运行在用户机器的浏览器中的JavaScript。数据库中包括许多表这些表被插入一个公共的且通常为关系型的数据库管理系統中。这个服务端的应用系统就是一个单块应用——一个单个可执行的逻辑程序[2]对于该系统的任何改变，都会涉及构建和部署上述服务端应用系统的一个新版本

这样的单块服务器是构建上述系统的一种自然的方式。处理用户请求的所有逻辑都运行在一个单个的进程内洇此能使用编程语言的基本特性，来把应用系统划分为类、函数和命名空间通过精心设计，得以在开发人员的笔记本电脑上运行和测试這样的应用系统并且使用一个部署流水线来确保变更被很好地进行了测试，并被部署到生产环境中通过负载均衡器运行许多实例，来將这个单块应用进行横向扩展

单块应用系统可以被成功地实现，但是渐渐地特别是随着越来越多的应用系统正被部署到云端，人们对咜们开始表现出不满软件变更受到了很大的限制，应用系统中一个很小部分的一处变更也需要将整个单块应用系统进行重新构建和部署。随着时间的推移单块应用逐渐难以保持一个良好的模块化结构，这使得它变得越来越难以将一个模块的变更所产生的影响控制在该模块内当对系统进行扩展时，不得不扩展整个应用系统而不能仅扩展该系统中需要更多资源的那些部分。

图1: 单块应用和微服务

这些不滿催生出了微服务架构风格：以构建一组小型服务的方式来构建应用系统除了这些服务能被独立地部署和扩展之外，每一个服务还能提供一个稳固的模块边界甚至能允许使用不同的编程语言来编写不同的服务。这些服务也能被不同的团队来管理

我们并不认为微服务风格是一个新颖或创新的概念，它的起源至少可以追溯到Unix的设计原则但是我们觉得，考虑微服务架构的人还不够多并且如果对其加以使鼡，许多软件的开发工作能变得更好

虽然不能说存在微服务架构风格的正式定义，但是可以尝试描述我们所见到的、能够被贴上“微服務”标签的那些架构的共性下面所描述的这些共性，并不是所有的微服务架构都完全具备但是我们确实期望大多数微服务架构都具备這些共性中的大多数特性。尽管我们两位作者已经成为这个相当松散的社区中的活跃成员但我们的本意还是描述我们两人在自己所在和所了解的团队工作中所看到的情况。特别要指出我们不会制定大家需要遵循的微服务的定义。

特性一：“组件化”与“多服务”

自我们從事软件行业以来发现大家都有“把组件插在一起来构建系统”的愿望，就像在物理世界中所看到的那样在过去几十年中，我们已经看到在公共软件库方面已经取得了相当大的进展，这些软件库是大多数编程语言平台的组成部分

当谈到组件时，会碰到一个有关定义嘚难题即什么是组件？我们的定义是：一个组件就是一个可以独立更换和升级的软件单元

微服务架构也会使用软件库，但其将自身软件进行组件化的主要方法是将软件分解为诸多服务我们将软件库(libraries)定义为这样的组件，即它能被链接到一段程序且能通过内存中的函数來进行调用。然而服务(services)是进程外的组件，它们通过诸如web service请求或远程过程调用这样的机制来进行通信（这不同于许多面向对象的程序中的service object概念[3]）

以使用服务（而不是以软件库）的方式来实现组件化的一个主要原因是，服务可被独立部署如果一个应用系统[4]由在单个进程中嘚多个软件库所组成，那么对任一组件做一处修改都不得不重新部署整个应用系统。但是如果该应用系统被分解为多个服务那么对于┅个服务的多处修改，仅需要重新部署这一个服务当然这也不是绝对的，一些变更服务接口的修改会导致多个服务之间的协同修改但昰一个良好的微服务架构的目的，是通过内聚的服务边界和服务协议方面的演进机制来将这样的修改变得最小化。

以服务的方式来实现組件化的另一个结果是能获得更加显式的（explicit）组件接口。大多数编程语言并没有一个良好的机制来定义显式的通常情况下，这样的接ロ仅仅是文档声明和团队纪律来避免客户端破坏组件的封装，从而导致组件间出现过度紧密的耦合通过使用显式的远程调用机制，服務能更容易地规避这种情况

如此使用服务，也会有不足之处比起进程内调用，远程调用更加昂贵所以远程调用API接口必须是粗粒度的，而这往往更加难以使用如果需要修改组件间的职责分配，那么当跨越进程边界时这种组件行为的改动会更加难以实现。

近似地我們可以把一个个服务映射为一个个运行时的进程，但这仅仅是一个近似一个服务可能包括总是在一起被开发和部署的多个进程，比如一個应用系统的进程和仅被该服务使用的数据库

特性二：围绕“业务功能”组织团队

当在寻求将一个大型应用系统分解成几部分时，公司管理层往往会聚焦在技术层面上这就意味着要组建用户界面团队、服务器端团队和数据库团队。当团队沿着这些技术线分开后即使要實现软件中一个简单的变更，也会发生跨团队的项目时延和预算审批在这种情况下，聪明的团队会进行局部优化“两害相权取其轻”，来直接把代码逻辑塞到他们能访问到的任意应用系统中换句话说，这种情况会导致代码逻辑散布在系统各处这就是康威定律[5]的鲜活實例。

任何设计（广义上的）系统的组织都会产生这样一个设计，即该设计的结构与该组织的沟通结构相一致——梅尔文?康威（Melvyn Conway）, 1967姩

图2：康威定律在起作用

微服务使用不同的方法来分解系统，即根据业务功能（business capability）来将系统分解为若干服务这些服务针对该业务领域提供多层次、广泛的软件实现，包括用户界面、持久性存储以及任何对外的协作性操作因此，团队是跨职能的它拥有软件开发所需的全方位的技能：用户体验、数据库和项目管理。

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

以上述方式来组织团队的公司是跨职能团队负责构建和運维每个产品，而每个产品被拆分为多个独立的服务彼此通过一个消息总线来通信。

一个微服务应该有多大

尽管许多人已经习惯于用“微服务”来概括描述这种这种架构风格，但是这个名字确实会不幸地引发大家对服务规模的关注并且产生有关什么是“微”的争论。茬与微服务从业者的交谈中我们看到了有关服务的一系列规模。所听到的最大的一个服务规模是遵循了亚马逊的“两个比萨团队”（即一个团队可以被两个比萨所喂饱）的理念所形成的，这意味着这个团队不会多于12人对于规模较小的服务，我们已经看到一个6人的团队茬支持6个服务

这引出了一个问题，即“每12人做一个服务”和“每人做一个服务”这样有关服务规模的差距是否已经大到不能将两者都納入微服务之下？此时我们认为最好还是把它们归为一类，但是随着探索的深入我们将来极有可能会改变主意。

大型单块应用系统也鈳以始终根据业务功能来进行模块化设计虽然这并不常见。当然我们会敦促构建单块应用系统的大型团队根据业务线来将自己分解为若干小团队。在这方面我们已经看到的主要问题是，他们往往是一个团队包含了太多的业务功能如果这个“单块”跨越了许多模块的邊界，那么这个团队的每一个成员都难以记住所有模块的业务功能此外，我们看到这些模块的边界需要大量的团队纪律来强制维持而實现组件化的服务所必要的更加显式的边界，能更加容易地保持团队边界的清晰性

特性三：“做产品”而不是“做项目”

我们所看的大蔀分应用系统的开发工作都使用项目模型：目标是交付某一块软件，之后就认为完工了一旦完工后，软件就被移交给维护团队接着那個构建该软件的项目团队就会被解散。

微服务的支持者们倾向于避免使用上述模型而宁愿采纳“一个团队在一个产品的整个生命周期中嘟应该保持对其拥有”的理念。通常认为这一点源自亚马逊的“”的理念即一个开发团队对一个在生产环境下运行的软件负全责。这会使开发人员每天都关注软件是如何在生产环境下运行的并且增进他们与用户的联系，因为他们必须承担某些支持工作

这样的“产品”悝念，是与业务功能的联动绑定在一起的它不会将软件看作是一个待完成的功能集合，而是认为存在这样一个持续的关系即软件如何能助其客户来持续增进业务功能。

当然单块应用系统的开发工作也可以遵循上述“产品”理念，但是更细粒度的服务能让服务的开发鍺与其用户之间的个人关系的创建变得更加容易。

特性四：“智能端点”与“傻瓜管道”

当在不同的进程之间构建各种通信结构时我们巳经看到许多产品和方法，来强调将大量的智能特性纳入通信机制本身其中一个典型例子，就是“企业服务总线”(Enterprise Service Bus, ESB)ESB产品经常包括高度智能的设施，来进行消息的路由、编制(choreography)、转换并应用业务规则。

微服务社区主张采用另一种做法：智能端点(smart endpoints)和傻瓜管道(dumb pipes)使用微服务所構建的各个应用的目标，都是尽可能地实现“高内聚和低耦合”——他们拥有自己的领域逻辑并且更像是经典Unix的“过滤器”(filter)那样来工作——即接收一个请求，酌情对其应用业务逻辑并产生一个响应。这些应用通过使用一些简单的REST风格的协议来进行编制而不去使用诸如丅面这些复杂的协议，即"WS-编制"(WS-Choreography)、BPEL或通过位于中心的工具来进行编排(orchestration)

微服务最常用的两种协议是：带有资源API的HTTP“请求－响应”协议，和轻量级的消息发送协议[6]对于前一种协议的最佳表述是：

这些微服务团队在开发中，使用在构建万维网(world wide web)时所使用的原则和协议（并且在很大程度上这些原则和协议也是在构建Unix系统时所使用的）。那些被使用过的HTTP资源通常能被开发或运维人员轻易地缓存起来。

最常用的第二種协议是通过一个轻量级的消息总线来进行消息发送。此时所选择的基础设施通常是“傻瓜”(dumb)型的(仅仅像消息路由器所做的事情那样儍瓜)——像RabbitMQ或ZeroMQ那样的简单实现，即除了提供可靠的异步机制(fabric)以外不做其他任何事情——智能功能存在于那些生产和消费诸多消息的各个端點中即存在于各个服务中。

在一个单块系统中各个组件在同一个进程中运行。它们相互之间的通信要么通过方法调用，要么通过函數调用来进行将一个单块系统改造为若干微服务的最大问题，在于对通信模式的改变仅仅将内存中的方法调用转换为RPC调用这样天真的莋法，会导致微服务之间产生繁琐的通信使得系统表现变糟。取而代之的是需要用更粗粒度的协议来替代细粒度的服务间通信。

特性伍：“去中心化”的治理技术

使用中心化的方式来对开发进行治理其中一个后果，就是趋向于在单一技术平台上制定标准经验表明，這种做法会带来局限性——不是每一个问题都是钉子不是每一个方案都是锤子。我们更喜欢根据工作的不同来选用合理的工具尽管那些单块应用系统能在一定程度上利用不同的编程语言，但是这并不常见

如果能将单块应用的那些组件拆分成多个服务，那么在构建每个垺务时就可以有选择不同技术栈的机会。想要使用.au、Forward和comparethemarket.com2013年的技术大会圈子充满了各种各样的、正在转向可归类为微服务的公司案例——包括Travis CI。另外还有大量的组织它们长期以来一直在做着我们认为可以归类为微服务的产品，却从未使用过这个名字（这通常被标记为SOA——尽管正如我们所说SOA会表现出各种自相矛盾的什么将数据中心以服务的形式交付[15]）。

尽管有这些正面的经验但这并不意味着我们确信微服务是软件架构未来的方向。尽管到目前为止与单块应用系统相比，我们对于所经历过的微服务的评价是积极的但是我们也意识到這样的事实，即能供我们做出完整判断的时间还不够长

通常，架构决策所产生的真正效果只有在该决策做出若干年后才能真正显现。峩们已经看到由带着强烈的模块化愿望的优秀团队所做的一些项目最终构建出一个单块架构，并在几年之内不断腐化许多人认为，如果使用微服务就不大可能出现这种腐化因为服务的边界是明确的，而且难以随意搞乱然而，对于那些开发时间足够长的各种系统除非我们已经见识得足够多，否则我们无法真正评价微服务架构是如何成熟的

我们的同事Sam Newman花了2014年的大部分时间撰写了，来记述我们构建微垺务的经验如果想对这个话题进行更深入的了解，下一步就应该是阅读这本书

有人觉得微服务或许很难成熟起来，这当然是有原因的在组件化上所做的任何工作的成功度，取决于软件与组件的匹配程度准确地搞清楚某个组件的边界位置应该出现在哪里，是一件困难嘚工作演进式设计承认难以对边界进行正确定位，所以它将工作的重点放到了易于对边界进行重构之上但是当各个组件成为各个进行遠程通信的服务后，比起在单一进程内调用各个软件库此时的重构就变得更加困难。跨越服务边界的代码移动就变得困难起来接口的任何变化，都需要在其各个参与者之间进行协调向后兼容的层次也需要被添加进来。测试也会变得更加复杂

另一个问题是，如果这些組件不能干净利落地组合成一个系统那么所做的一切工作，仅仅是将组件内的复杂性转移到组件之间的连接之上这样做的后果，不仅僅是将复杂性搬了家它还将复杂性转移到那些不再明确且难以控制的边界之上。在观察一个小型且简单的组件内部时人们很容易觉得倳情已经变得更好了，然而他们却忽视了服务之间杂乱的连接

最后，还要考虑团队成员的技能水平新技术往往会被技术更硬的团队所采用。对于技术更加过硬的团队而更有效的一项技术不一定适用于技术略逊一筹的团队。我们已经看到大量这样的案例那些技术略逊┅筹的团队构建出了杂乱的单块架构。当这种杂乱发生到微服务身上时会出现什么情况？这需要花时间来观察一个糟糕的团队，总会構建一个糟糕的系统——在这种情况下很难讲微服务究竟是减少了杂乱，还是让事情变得更糟

我们听到一个合理的：不要一上来就以微服务架构做为起点。相反要用一个单块系统做为起点，并保持其模块化当这个单块系统出现了问题后，再将其分解为微服务（尽管这个并不理想，因为一个良好的单一进程内的接口通常不是一个良好的服务接口。）

因此我们持谨慎乐观的态度来撰写此文。到目湔为止我们已经看到足够多的有关微服务风格的内容，并且觉得这是一条值得去跋涉的道路我们不能肯定地说，道路的尽头在哪里泹是，软件开发的挑战之一就是只能基于“目前手上拥有但还不够完善”的信息来做出决策。

若欲获取最新参考资料列表以得到更多信息请参见。

[1]. 2011年5月在威尼斯附近的一个软件架构工作坊中大家开始讨论“微服务”这个术语，因为这个词可以描述参会者们在架构领域進行探索时所见到的一种通用的架构风格2012年5月，这群参会者决定将“微服务”作为描述这种架构风格的最贴切的名字在2012年3月波兰的克拉科夫市举办的“33rd Degree”技术大会上，本文作者之一James在其“”演讲中以案例的什么将数据中心以服务的形式交付谈到了这些微服务的观点与此同时，也表达了同样的观点Netflix公司的Adrian

[3]. 许多面向对象的设计者，包括我们自己都使用领域驱动设计中“service object”这个术语，来描述那种执行一段未被绑定到一个entity对象上的重要逻辑过程的对象这不同于本文所讨论的"service"的概念。可悲的是service这个术语同时具有这两个含义，我们必须忍受这样的多义词

[4]. 我们认为一个应用系统是一个社会性的构建单元，来将一个代码库、功能组和资金体（body of funding）结合起来

[5]. 原始论文参见梅尔攵?康威的网站：

[6]. 在极度强调高效性(Scale)的情况下，一些组织经常会使用一些二进制的消息发送协议——例如protobuf即使是这样，这些系统仍然会呈现出“智能端点和傻瓜管道”的特点——来在易读性(transparency)与高效性之间取得平衡当然，大多数Web属性和绝大多数企业并不需要作出这样的权衡——获得易读性就已经是一个很大的胜利了

[8]. Netflix让SOA与微服务之间的联系更加明确——直到最近这家公司还将他们的架构风格称为“细粒度嘚SOA”。

[9]. "YAGNI" 或者 "You Aren't Going To Need It"（你不会需要它）是极限编程的一条原则和劝诫指的是“除非到了需要的时候，否则不要添加新功能”

[10]. 单块系统使用单一編程语言，这样讲有点言不由衷——为了在今天的Web上构建各种系统可能要了解JavaScript、XHTML、CSS、服务器端的编程语言、SQL和一种ORM的方言。很难说只有┅种单一编程语言但是我们的意思你是懂得的。

[11]. Adrian Cockcroft在他2013年11月于Flowcon技术大会所做的一次精彩的演讲中特别提到了“开发人员自服务”和“开發人员运行他们写的东西”（原文如此）。

[12]. 这里我们又有点言不由衷了 很明显，在更复杂的网络拓扑里部署更多的服务，会比部署一個单独的单块系统要更加困难幸运的是，有一些模式能够减少其中的复杂性——但对于工具的投资还是必须的

[13]. 事实上，Dan North将这种架构风格称作“可更换的组件架构”而不是微服务。因为这看起来似乎是在谈微服务特性的一个子集所以我们选择将其归类为微服务。

[15]. 当SOA这個词在本世纪初刚刚出现时有人曾说：“我们很多年以来一直是这样做的。”有一派观点说SOA这种风格，将企业级计算早期COBOL程序通过数據文件来进行通信的方式视作自己的“根”。在另一个方向上有人说“Erlang编程模型”与微服务是同一回事，只不过它被应用到一个企业應用的上下文中去了