Martin Fowler关于微服务的原文翻译

原文如下：http://martinfowler.com/articles/microservices.html

微服务

有关这个新的技术架构术语的定义

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

2014年3月25日

目录

微服务架构的九大特性

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

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

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

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

特性五：“去中心化”地治理技术

特性六：“去中心化”地管理数据

特性七：“基础设施”自动化

特性八：“容错”设计

特性九：“演进式”设计

未来的方向是“微服务”吗/p>

扩展阅读

一个微服务应该有多大/p>

微服务与SOA

多种编程语言，多种选择可能

“实战检验”的标准与“强制执行”的标准

让“方向正确地做事”更容易

“断路器”与“可随时上线的代码”

“同步调用”有害

“微服务”——这是在软件架构这条熙熙攘攘的大街上出现的又一个新词儿。我们自然会对它投过轻蔑的一瞥，但是这个小小的术语却描述了一种引人入胜的软件系统的风格。最近几年，我们已经看到许多项目使用了这种风格，而且至今其结果都是良好的，以至于对于我们许多ThoughtWorks的同事来说，它正在成为构建企业应用系统的缺省的风格。然而，很不幸的是，我们找不到有关它的概要信息，即什么是微服务风格，以及如何设计微服务风格的架构。

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

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

在我的“微服务资源指南”中(http://martinfowler.com/microservices/)能找到有关微服务最好的文章、视频、图书和播客媒体。

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

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

图2：康威定律在起作用

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

图5：基本的构建流水线

一个单块应用程序，能够相当愉快地在上述各个环境中，被构建、测试和推送。其结果是，一旦在下述工作上进行了投入，即针对一个单块系统将其通往生产环境的通道进行自动化，那么部署更多的应用系统似乎就不再可怕。记住，持续交付的目的之一，是让“部署”工作变得“无聊”。所以不管是一个还是三个应用系统，只要部署工作依旧很“无聊”，那么就没什么可担心的了[12]。

让“方向正确地做事”更容易

那些因实现持续交付和持续集成所增加的自动化工作的副产品，是创建一些对开发和运维人员有用的工具。现在，能完成下述工作的工具已经相当常见了，即创建工件(artefacts)、管理代码库、启动一些简单的服务、或增加标准的监控和日志功能。Web上最好的例子可能是Netflix提供的一套开源工具集(http://netflix.github.io/)，但也有其他一些好工具，包括我们已经广泛使用的Dropwizard (http://dropwizard.codahale.com/)。

我们所看到的各个团队在广泛使用基础设施自动化实践的另一个领域，是在生产环境中管理各个微服务。与前面我们对比单块系统和微服务所说的正相反，只要部署工作很无聊，那么在这一点上单块系统和微服务就没什么区别。然而，两者在运维领域的情况却截然不同。

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

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

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

我们听到一个合理的说法，是说不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点(http://martinfowler.com/bliki/MonolithFirst.html)，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。（尽管这个建议并不理想(http://martinfowler.com/articles/dont-start-monolith.html)，因为一个良好的单一进程内的接口，通常不是一个良好的服务接口。）

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

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

参考资料

博客和线上文章

演讲