微服务的好处

Gene Kim（主持人）、Gary Gruver、Andrew Phillips 和 Randy shoup 在一次最近的在线座谈会上讨论了微服务的好处。

XebiaLabs 组织了这次题为“探索微服务的未知边界”的在线研讨，以下参与者讨论了微服务带来的好处：Gene Kim 作为主持人，同时也是一名作家、研究员，并曾任Tripwire 公司的CTO；Gary Gruver 是Practive Large Scale Agile 有限公司的总裁，曾任HP 公司LaserJet 企业部门的工程总监；Randy Shoup 是Randy Shoup 咨询公司的顾问CTO ，曾任Google 公司云计算部门工程总监；Andrew Phillips 是XebiaLabls 公司产品管理副总裁。我们摘取了与会者的主要观点，并以精简的方式转述给大家。

Gruver 说，微服务让架构师可以将大型系统拆解为细粒度的服务，这些服务封装了单个业务特性所关联的所有功能。相比于大型企业级单块（monolithic）应用的设计，这种方式在此类大型项目的团队工作管理、代码变更与发布周期方面都更具优势。

大型单块架构系统的代码库让我们无法获得及时的反馈回路，Gruver 提到了一个案例，在该案例中，代码中的一处问题花了六个月才得以发现，并且用了一周时间才得以解决。

Shoup 认为一些成功的互联网公司——Amazon、eBay、Google、Netflix、Twitter 等等都已经转向了微服务，因为单块应用的规模在不断膨胀，团队沟通协调的开销如此之大，团队对代码变更的恐惧如此之强，以至于所有事情都被拖慢了脚步。

Shoup 补充说：微服务、敏捷以及 DevOps 是同一理念的不同方面，把我们所做的事情拆解成小且可管理的条目，并且分而治之，可以使大型公司如同小公司一样行动敏捷。围绕微服务来组织整个公司，让三到五人的自治团队为一个或多个服务负责，让这些团队自己决定需要使用的技术和方法。这种方式使得开发人员对小且专业化的代码库更有责任感，并对代码能有更深的认识，从而能够更高效的进行功能优化和缺陷修复。

Google MegaStore 服务的开发团队仅有六人，但它却服务于众多包括 Google App Engine 和 Google Cloud DataStore 等其它服务。而 Cloud DataStore 更是世界上最大的 NoSQL 服务之一，但是据 Shoup 说这个团队也仅仅只有六到八人。

代码变更所带来的风险与所修改的代码行数并不是线性相关的。在一个单块应用中，当代码变更的数量增加时，由于相关的依赖项越来越多，变更风险往往呈指数级上升。而在微服务的世界里，由于采用持续发布的方式，每次变更的范围有限，开发人员可以很快的发现并修复变更带来的缺陷，减少每次系统上线部署所带来的风险。Shoup 补充说，微服务的这种方式在提高效率的同时降低了关联性风险。

Gruver 接着说，与微服务的方式相比，单块应用的一次大的发布可能包含由数百开发人员完成的数千个变更，管理和协调这样的发布是令人恐惧的，人们需要确保每一样东西各就其位并且能相互协调一致。

Phillips 说，和敏捷、DevOps 以及持续发布一样，微服务并不是解决所有问题的银弹，但它确实在一定场景下奏效，同时也需要付出一些代价。对于企业来讲，单块应用仍有发展空间。尽管如此，大型代码库会是问题丛生的，Phillips 提到了一个 Microsoft Word 的 bug，该 bug 自 1995 年就已经存在，却没人能将其定位修复。

Phillips 提到了另一个微服务带来的好处，更小的代码库可以让程序员更加专注，并且与产品客户有更投入的关系，这样程序员就能够对工作有更明晰的认识和更积极的动力。与用户联系紧密后会得到更快的反馈，程序员可以更及时的发现产品所暴露的缺陷以及应当去实现的新功能。

与会者同时也提出一些难题，涉及单块应用如何向微服务架构进行迁移。Gruver 建议，不要重新构建每样东西，要从小做起，找一些有价值且适于进行微服务改造的业务功能，改造实现后与整个系统集成测试。要检查新实现的服务与其他流程结合以及持续集成的情况，如果一切运转良好，就使用新的服务来替代旧的代码。检验改造是否成功的准则，取决于组织是否能通过研发和发布独立的微服务而变得更加敏捷。如果这个目标没有达成，那引入微服务架构并没有意义。

Shoup 分享了他在 eBay 工作的经验，首先按照营业收入的多少将所有功能排序，从最赚钱的功能开始重构，接着去逐渐修改盈利能力低一些的功能。由于有些功能对业务经营的影响微不足道，以至于改造只会得不偿失，这些功能将永远不会被重构。当重构功能组件的时候，第一步是引入一个接口，分离出组件与系统其它部分的依赖关系，接着再按照设想的方式改变接口的实现。这个过程同样也适用于其他组件的改造。

Philips 认为，测试套件对于重构功能组件的工作非常重要。通过针对新接口进行测试，比对新老两种实现是否结果一致，从而确保代码的变动并不会影响系统的行为。

Gruver 补充说，在没有自动化测试套件的前提下，他不会启动重构的过程。在重构或实现微服务之前，应当确保你理解需要解决的业务问题，接着再去设定自己认可并为其负责的方向和目标。

Phillips 提到服务之间的强耦合比数据冗余更糟糕，他宁愿有两份同样的数据也不会让两个服务为了一份数据而搅和在一起。（也有一些人认为服务之间让数据冗余是一种反模式，详见 Udi Dahan 谈定义服务边界)

Shoup 在回答参会者的一个问题时表示，将单块应用重构为微服务系统的过程中，人们可能需要将数据从关系型数据库中迁移到 NoSql 数据存储中。一种方式是将领域实体在私有的 NoSql 数据库中进行持久化，并通过微服务的接口暴露出来。每个实体应当只有一份可写数据集，而出于性能的考虑，可以有多份缓存的只读数据集，

谈到服务之间大量的互联依赖关系难以管理时，Shoup 回答说，Amazon 和 Google 并没有使用 API 网关或 ESB 去控制依赖的拓扑关系，因为站在服务的角度，依赖关系一目了然。每一个微服务并不需要了解所有其他服务之间的交互关系，它只需要清楚哪些客户端依赖于它以及它依赖于哪些其他服务即可。与下游客户端之间的关系可能包含授权关系以及每秒钟的请求流量配额等，而与上游其他服务的关系则仅仅意味着简单的服务请求。服务之间的通信通道应当是标准化的，保证服务之间能够相互理解，可选的调用方式包括 RESTful WebAPI、RPC 等等，同时支持同步和异步的调用机制。他提到 Google 刚刚开源了一种 RPC 协议，正可用于微服务之间的调用。

在服务治理上，Shoup 建议每个团队应当对他们自己的服务全权负责，同时还包含运维的工作。同时，功能需求的服务水平协议应当得到上下游的一致认可。

查看英文原文： The Benefits of Microservices

感谢赵震一对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。