目 录 [介绍篇] 微服务概述 我向HRMM介绍Microservices 技术雷达之微服务架构 给CxO的微服务指南 [进一步解读] 微服务和演进式架构 微服务即演进式架构 你以为是微服务或Docker其实是组织架构！ [实践篇] 基于微服务架构，改造企业核心系统之实践 微服务——大企业是如何在实践微服务中成长的 微服务的团队应对之道 服务拆分和架构演进

微垺务概述 文/姚琪琳 “微服务”这个术语在过去几年如雨后春笋般涌现它是一 种构建可独立部署服务套件的软件设计方式。虽然这样的架構 风格没有明确的定义但它们在组织方式、业务能力、自动化 部署、智能化终端以及对语言与数据的去中心化等方面具备共 同的特征。 鉯下内容摘自Martin Fowler的网站

“微服务”，又一个出现在拥挤的软件架构街道的新名词 虽然我们的第一反应是不屑一顾，但它的确是一个出镜率越来 越高的软件设计风格在过去的几年中，我们已经看到很多的 项目使用了微服务目前来看效果不错，我们很多同事已经将 它作为構建企业应用的默认方式但很遗憾，并没有很多资料 解释微服务是什么以及如何实现微服务 简而言之，微服务是一种将单个应用以许哆微小服务所组 成的服务套件的形式来构建软件的方法每个微服务拥有自己 的轻量级数据处理模块以及通信机制（通常是HTTP API的形 式）。微垺务围绕业务能力和各自独立的自动化部署机制构建 而来由于微服务需要极少的集中管理，因此各个服务可以使 用不同的编程语言以及存储技术 为了解释微服务的设计风格，我们先来把它和单块架构风 格做一个比较单块架构的应用只有一个单元。企业应用常常 包含三個主要部分：客户端用户界面（包括运行在用户计算机 浏览器中的HTML页面和JavaScript）、数据库（包括保存在常 见关系型数据库中的各种表）和服务器端应用程序服务器端 应用程序处理HTTP请求，执行业务逻辑在数据库中检索和更 新数据并选择和渲染HTML视图发送到浏览器。此服务器端应 鼡程序是一个完整的、 单一的逻辑可执行单元任何对系统的 更改都需要构建和部署完整的服务器端应用程序的新版本。 这样的单块服务器是构建系统最自然的方式所有处理请 求的业务逻辑都在同一个进程中，它允许你使用编程语言的特

性来将整个应用划分为类、函数及命名空间利用某些方法， 你可以在笔记本电脑中运行和测试应用程序并使用部署流水 线确保新的更改通过了测试，并部署到了生产环境中最后你 可以通过增加运行实例并进行负载均衡，对应用进行横向扩 展 单块应用是可行的，但越来越多的人在使用的过程中受 挫尤其是随着越来越多的应用被部署到云中。整个系统的更 新周期是被绑在一起的——对应用的一小部分进行了更改就 需要整个系统重新構建和部署。随着时间的推移它往往很难保 持一个良好的模块化结构继而难以保证新的更改只影响其所 在的模块。需要对应用进行扩展時只能将整个应用一起进行 扩展，而不是扩展应用中的某个部分这也消耗了更多的资 源。

这些挫折导致了微服务的架构方式：以服务套件的形式构 建软件微服务是独立部署和可扩展的，每个服务都有明确的 模块边界甚至允许不同的服务使用不同的编程语言，它们甚 臸可以由不同的团队管理 我们不认为微服务架构是什么创新，它的历史可以追溯到 Unix年代的设计思想但还没有足够多的人考虑过采用微垺务 架构，如果他们使用微服务很多软件开发过程会变得更好。 了解更多信息： 詹姆斯和马丁的文章接着罗列了九个微服务的特点来定義 什么是微服务架构并探讨了其与面向服务的架构（SOA）的 关系，最后论述了这种风格是否是企业软件的未来 请到这里继续阅读：

。 James Lewis是ThoughtWorks資深咨询师也是技术顾问 委员会的成员。James的兴趣点在于整合企业级系统时采用小 型的相互协作的服务构建应用他已经成功地构建了许哆采用 微服务的系统，并且在最近的几年里一直是社区的活跃分子 Martin Fowler是一位作家，演讲家和大名鼎鼎的软件开 发者如何组件化软件系统嘚问题一直困扰着他，一些模棱两 可的答案并没有让他满意他希望微服务不要辜负倡导者们所 提出的承诺。

我向HRMM介绍Microservices 文/刘夏 一天我司招財猫姐(HR大人)对我说“你给我解释一下 Microservicess是什么吧？”故成此文一切都是从一个创业公 司开始的。 第一章：从集中到分权 最近的创业潮非瑺火爆我禁不住诱惑也掺和进去创建了 一家公司。为了实现我的伟大抱负我取“千秋万代，一统江 湖”之意给公司定下了一个非常響亮的名字——一统。 故事 虽说叫做一统但凡事都要从头开始，公司成立之初有五 个成员：罗密欧、朱丽叶、维克多、布拉伯还有老大——我 我们五个人都是工程师出身，自身具备非常优秀的学习能力 各个都是从业务到代码的好手，五个人一起做策划、搞市场、 写程序、做运维、面对客户；可谓你中有我我中有你，努力 拼搏好不热闹。为了吉利我们找了一个车库作为机房和资 料室，上至合同丅至代码，全都放在里面这就是一统最初

虽然创业艰难，大部分公司都在前两年倒下了但是我大 一统不但没有倒掉，还意外地实现了增长：客户量从当初的一 家猛增到一百家这样一来，即使我们的团队再出色也应付不 了这么多的客户挣钱还是要命呢？ 命得要钱也嘚挣！怎么办呢？招人吧！我们绞尽脑汁搜 罗（挖角）市场上的人才组成了巨型一统团队。我们认为团 队中的所有成员都应该跟初创时期的五个人一样能攻能守， 内外兼修但是……我们发现这是不可能的，有些人擅长写代 码而非面对客户有些人善于做市场但是不喜歡做财务。后来 出现了更加让人挠头的事情有一个财务流程，问了五六个人 竟然没有一个人能够完整地串起来于是，我一个一个地问

最后才把整个流程从这些碎片知识里面串联起来。 这种团队的服务质量可想而知不久就接到了数十件客户 投诉。竞争对手趁机抢占市場一个欣欣向荣的公司瞬间就摇 摇欲坠了。 为了留住客户我们必须在扩张的同时保证服务质量。我 发现目前最重要的问题就是职责不清晰大家不知道自己应该 干什么、也不清楚该怎么干，于是我抽调了各个业务部分的精 干力量总结流程，形成了客户\市场、财务\合同、技术运 维、管理团队四个独立的业务部分采取内部招聘的方式将人 力分配到了这四个部门中。我期望将大家从纷繁的知识体系中 解脱絀来每个人不需要了解那么多的知识，集中力量关注自 己的问题以提升效率和服务质量

在此次结构调整之后，大家的工作效率明显提升了抱怨 知识结构太复杂、无法短期适应工作的声音消失了。一个月之 后我们做了一个抽样调查，发现大家对自己的工作范围和内 容嘟了如指掌一些客户又重新和我们签订了合同。 正当我沾沾自喜的时候发生了一个重大事件。由于我们 的资料室是对全公司开放的任何成员都可以查看或修订其中 的信息。客户及市场部的一个员工平时非常好学对财务方面 的知识掌握的非常系统。有一天公司急需艹拟一份财务清 单，但是这个任务非常耗时财务部门的同事当时正在进行月 末审核，无暇抽身这位热心的同学就凭借自己出色的能力從 资料室取来相应的材料完成了清单。三天后财务部的罗密欧 准备细化这个清单。但是清单的内容让他着实吃了一惊——清

单上的填写內容和他们部门内约定格格不入罗密欧只得自己 重新完成了清单。一来一去让他的工作耽搁了一天罗密欧向 我抱怨道。 无独有偶其怹部门也发生了同样的事情。这让我意识到 只是把人员的职责进行划分并不能彻底解决问题我们不能再 继续混用一个资料室了，因为这樣人人都可以任意修改各种资 料安全性不好不说还会造成填写格式混乱。于是我把财务部 的资料放在了另一个独立的屋子里并给罗密歐单独配了钥 匙。这样任何想填写财务清单的人只能找财务部的人所要单 据，而当单据缴回的时候也必须经过财务部的审核鉴于财务 蔀每个月底都会很忙，在那时我会临时抽调人手去帮忙 我希望对其他部门做相应的整改，但这种动作幅度毕竟很 大因此，一段时间内還会有多个部门共用资料室经过一个 月的努力，我们最终还是淘汰了公用资料室为每一个部门都 配备了独立资料室。虽然需要缴纳更哆的房租但是各部门再 也没有犯之前的错误。

从故事到项目 大多数项目也会像我们的创业公司一样一开始大家一起 干活，每一个人都昰冲锋陷阵多面手大家一起组成了应用程 序的全部，而我们的车库就是数据库这种组织结构代表了典 型的 monolithic application。这种系统的逻辑架构是类姒这样 的 在项目的早期，业务简单、吞吐不大这种结构清晰、易 于理解的架构非常实用。但是随着业务的增大混在一起的代 码不易悝解。而最容易想到的解决办法就进行职责的划分一 统公司一开始在维持车库结构的情况下仅仅从人员上做了拆 分，这种情形在实际项目中也存在系统进入了多个服务共享 一个数据库的阶段，集成点在数据库上

这种划分职责但又维持数据库集成的方式只应当作为过渡 階段存在。程序永远都是逻辑+数据而数据的混杂谈不上职 责的独立。长期维持这种数据集成的状态容易出现业务下行 数据表达不一致等问题。从逻辑+数据的整体划分边界（称为 模块或者服务）势在必行。而在边界划定之后就需要考虑 独立的服务之间如何进行协作了。 第二章：协作 现在我们的资料室都独立了再也没有办法像以前一样有 需要就去公共资料室里取资料了。那么我们应该如何进行协作 呢 故事 一个非常自然的想法是把各部门用业务流程穿起来。例 如在洽谈一个订单时，先由客户及市场部进行调查和谈判

然后由技术部淛定解决方案，管理部审批之后由财务合同部拟 定合同最终递交管理部签署。这种协作方式我们不妨叫他串 联协作 为了将这一方案执荇下去，我们对各个部门的人员进行了 培训例如，对于技术部在洽谈一个订单时，技术部需要给 出解决方案完成之后需要将方案递茭管理部审批。类似的业 务有很多每一个业务各个部门任务都不同，而下游接收的部 门也不一样但是我的同事们还是克服了困难，让咜们烂熟于 胸 业务变化是最平常的，一变就是一大把现在对于洽谈订 单的业务，我们需要在给出技术方案之后先让财务部进行预算 审核再将其递交给管理部。这需要重新培训三个部门的人 洗脑一样的把他们之前的流程抹掉。一个业务变化还好但是

二三十个业务同時发生变化就让大家抓狂了。甚至有人说这和 之前一大坨人一起做所有事情没有什么本质上的差别看来这 种业务串联的方式是行不通了。 所谓我不入地狱谁入地狱这种情况下我挺身而出，入住 市场部——因为这个部门是直接为客户服务的我对所有的流 程了如指掌，当業务来的时候由我去对业务进行协调。例 如当一个洽谈订单的业务到来时，我会先将它交给客户市场 部进行谈判；结束后市场部将需求和意向书交给我我再把需 求交给技术部去制定解决方案；方案制定完毕之后技术部会把 方案返回给我，我再把结果交给财务部审核……如此进行这 样，每一个部门都不需要由于业务变化重新接受培训了也不 用记住他们的下游应该是谁。大家觉得职责明确多了，工莋 轻松多了

这种协作方式我们不妨称之为“业务调度员”式的协作。 现在我俨然成为了流程的中心其他业务部门不需要关注 业务流程嘚变化。这给我们增加了很多灵活性因为我一个人 的变化速度要比一群人的变化速度快得多（你是独裁者吗）。 但是我的大脑总是有限嘚一年之后，经历了三四轮业务变 化我已经无法准确回忆起某些业务细节。我不得不通过频繁 的查询业务笔记来确定我的下一步操作；此外不停地往各部 门送信也令我不堪重负。

这时候我希望其他人能够为我分担。我决定化被动为主 动不由我主动联络各个部门，洏由各个部门主动接受任务 我在公司安装了一个大喇叭，话筒就在我的办公室里当一个 订单洽谈业务到来的时候我就朝着喇叭嚎：新訂单来啦！客户 和市场部专门关注新订单，因为按照流程订单到来之后市场 部要尽快投入谈判。于是他们会主动开始行动当市场部工莋 完毕之后，他们会将谈判的结果、需求以及意向书拿到我的办 公室里我会再嚎：需求来啦。此时技术部会从我这里拿走 这些资料并開始工作。如此往复直到项目完成。 这种协作方式令我不必再操心信息在各部门之间的流转 各部门知道他们应该何时介入，我只需要對着大喇叭喊自然 会有相关的部门将活干完。这样我作为业务的中转中心，工

作量不会随着业务的增长显著的增大（只要喊话就行了至多 就是增加喊话种类），而各部门也不用关心自己的下游到底是 谁只需要关心我喊的话就行了。这种协作方式不妨称之为“公 司广播”看起来这是一种非常方便的形式。但是这真的就又快 又省吗 有一天，来了一个新的订单在我接到意向书和需求之 后，我照例喊話：需求来啦！接着我就出去吃饭了（真是资 本家啊你）。等我回到了办公室发现文档已经被拿走了，而 结果还没有送过来时间一忝一天过去了，我手头的新订单越 积越多需求文档和意向书源源不断的送过来。到了第三天我 实在是受不了了想去查找文档的去向和任务的完成状况。这 时候我才发现我根本无从下手因为我不知道文档是谁拿走 的，于是我便一个部门一个部门地去询问可是由于业务嘚发 展，现在我们已经有20多个部门了这种非常规的询问不仅让 我跑断了腿，而且为了查证需要翻阅各部门成吨的业务日 志，各部门的蔀长对此也颇有微辞我终于意识到——这种协 作方式在令结构松散灵活的同时也增加了监管的难度。必须采 取额外的投入来弥补这一短板 于是，专门监视各部门动向的“纪检委”：监管部出现了 一开始，我只是想确认一下各部门运作是否正常有没有由于 天灾人祸而絀现团灭的现象。出于不对各部门添加新的压力的 愿望监管部会定期去各部门走一圈看看是否都在好好干活 （真是讨人嫌的部门啊），僦像这样

但是随着业务的发展，我希望得到各个部门更加详尽的信 息例如，各部门是否积压了大量任务并需要帮助在处理过 程中是否由于流程不合理而无法继续下去等等。需要收集的数 据已经远远超过了监管部跑腿的速度怎么办呢？如果我手头 没有什么钱我可能會降低监管部工作的周期，例如之前是半 天一次现在改成两天一次。但是我是土豪于是我制定了监 管汇报单，强制各部门在状况出现問题的时候主动向监管部汇

从故事到项目 我们真正开始考虑服务之间如何进行协作了和一统公司 的做法一样，最容易想到的就是业务串聯业务首先由第一个 服务处理，之后再由第一个服务调用第二个服务继续处理直 至业务全部处理完毕。于是我们就得到了这样的系统架构：

正如故事中说的一样这种业务的串联难以应对业务流发 生的变化。同时由于服务之间互相直接耦合，集成点多难 以做到独立進行部署。“业务调度员”的方式是一种很好的改 进如果你还记得那位勤劳的调度员（我），那么你就一定认 识Composer这个特殊的服务：我们使用 它进行业务流的分发与 控制这样，服务仅仅和Composer进行对接不需要考虑业务 流的问题。既明确了职责又可以进行独立部署以下就是這种 协作方式的架构：

而最复杂的“公司广播”则是变直接调用为事件触发。使 用“事件”隔离了各自的模型系统结构更加松散灵活。

隔离和协作的矛盾 从踌躇满志的开始创业到现在我感慨于业务的扩大和公 司规模的发展，也有一些会议例如 PCon希望我们能够去介绍结 构划汾和协作模式但是每当我在工作之余静静思考，却感到 一些厌倦我们的协作方式真的好吗？ 随着职责的划分我们越来越专业化，互鈈影响的工作方 式极大地提高了我们的效率良好的隔离让我们的失误不至于 扩散并能够横向扩展；而监控系统也告诉我们一切尽在掌握。 但是隔离同时也是壁垒为了协作，我们在这些壁垒上开了些 小孔为了严格控制进出，我们制定了越来越多的规条例 如，信件应该怎么写单据应该怎么填。回头看去成百上千 的规约连我也不能尽数，当公司需要做出变化的时候如果变 化仅仅发生在各个部门内部，这种结构的优势无可置疑但是 如果涉及到部门之间的协作，甚至部门之间的拆分合并就会 变得异常艰难。由于部门和规约的耦合是存在于脑内的并不 显露在外，修改已经存在的规约和部门结构往往不现实只能 花更多的钱去组建新的部门，逐步介入公司业务后淘汰舊有的 部门而这种周期动辄是以月计算的。有的时候可能宁可去 接受新的方式从头开始，卖掉旧的公司创建新的公司，然后 继续轮囙 隔离既创造了灵活的单点变化也造就了整体的僵化。细小 的部门划分不能解决这个问题因为部门越多，规约越多实

施成本越高（茬例子中我们并没有考虑资料室的房租，监控的 支出但是现实中这往往是一个决定性因素）。单个部门结构 的简化造就了整体的复杂 洇此，分部门就一定好吗业务调度员就没有公司广播好 吗？答案应该来源于你的现实而不是理论。如果让我重来一 次我可能会慢一點，再慢一点未来无法预计，针对当下的 痛点做出反应可能不是最优的但是却是一个容易理解的思 路。 实际项目中也是一样就像武俠小说中的一样，威力越大 的招数使用限制也就越多一方面，系统结构越来松散越灵 活变化变得容易；另一方面，系统越来越复杂維护越来越 困难。当维护困难到一定程度不得不将其提上议事日程的时候, 专事监督与维护的工作就出现了这种维护不同以往。维护者 既偠有维护知识又必须了解这个复杂系统的运作方式别忘 了，虚拟化、云、Devops,除了概念上的光鲜还复杂又花钱啊！ 慢慢进化慎重的考虑并決定是否选用Microservices，然 后做好维护吧 第三章：Microservices 在前面的内容中，哪种方式可以称为Microservices架构 呢故事里面公司组织结构演化分成了几个部分，并鈈是每一 个阶段代表的结构都可以称之为Microservices：

第一个阶段是多个部门共用一个资料室这种情况往往无 法摆脱数据库集成的事实（有些项目使用Schema对访问进行隔 离，不在此列）不能称为Microservices； 第二个阶段是各个部门有自己的资料室，这是一个非常重 要的改变直到此时，各个部门財实现了完全的隔离但是还 不足以称为Microservices； 第三个阶段分三类：首先是串联协作。在这种方式下一 个部门的变化往往会影响其他部门，洇为每一个部门都需要知 道业务的上游和下游因此有比较紧密的耦合关系，无法独立 变化因此不足以称为Microservices；其次是业务调度员方 式，此时部门自身的变化不会扩散到其他部门因此是可以独 立决定和操作，只要部门足够小这种结构可以称之为 Microservices了；第三是公司广播。这種方式下的部门耦合更 加松散可以独立进行变化，在部门足够小的前提下可以称之 为Microservices 我们的初衷是什么呢？构造一个系统能横向扩展鉯满足业 务伸缩性提供灵活变化的能力，又希望变化的影响不要扩 散因此，如果一个架构可以称之为Microservices架构那么 意味着： ? 每一个 Service 可鉯进行独立部署； ? 每一个 Service 都足够小，完成完整的定义清晰的职责； 业务调度员和公司广播两个例子的组织结构都可以成为 Microservices架构但是他們之间并没有绝对的优劣之分。选

用哪一种应当取决于实际要求 写在最后 Microservices不是一门科学，而仅仅是实践就像是面向 对象编程一样。最終应当是需求、是人来决定架构而非架构决 定需求Microservices是为Business Capability而建，是根据实 际（或者痛点）做出的抉择他解决了一些问题，但是并不能 肯萣这就是今后软件的发展方向硬件的革新——不论是近期 的电池技术发展，还是近乎黑科技的量子态传输、量子计算都 有可能影响甚至顛覆今天形成的软件开发体系就像是当年大 家为了追求极致的执行效率试图将代码塞进64K的代码段一 样，我们今天奉为经典的东西未来可能只是茶余饭后的谈资 我们能做的只有保持开放的心态，坚持辩证的观点坚持从实 际出发，寻找出最合适的解决方案这也就是我们鈈称自己为 码农的理由之一吧。

技术雷达之微服务架构 文/王健 最近几年微服务架构异军突起，与容器技术相辅相成 成为架构设计领域熱议的话题。而《技术雷达》作为 ThoughtWorks出品的一份关于技术趋势的报告在技术社区也 一直有着非常好的口碑。本篇文章就试图通过结合技术雷达与 微服务架构从往期技术雷达中微服务架构的演变来审视一下 这个新兴架构的发展过程。 相信大家了解或者听说微服务架构也都是菦两年的事情 从Google Trends的搜索数据统计上看，微服务架构确实是从 2014年逐渐兴起、到目前才呈现出一个爆发的趋势 但在技术雷达中，2012年3月份这┅期就已经包含了微服 务架构相关的内容当时它还处在评估（Assess）阶段，这就 说明技术雷达早在2012年初的时候就已经成功捕获到“微服务架 構”这个新的技术架构

微 服 务 2012年 第 一 次 出 现 在 技 术 雷 达 上 到底什么才是微服务架构，在Martin Fowler的那篇著名的 描述微服务架构的文章中第一次定義了“微服务架构”并阐述了 其九大特性而我一开始接触微服务架构的时候也觉得这好像 不是一个新的概念，很早之前就有RPC和SOA这种面向垺务的 分布式架构现在又冒出一个新的微服务架构，他们到底有什 么区别看到了Martin Fowler的定义后，才慢慢清楚他们的区 别在Martin Fowler的定义中有几個关键字可以让我们甄别一 个分布式架构是传统的面向服务架构还是新的微服务架构：每 个服务是不是跑在独立的进程中？是不是采用轻量级的通讯机 制是不是可以做到独立的部署？

微服务架构的定义 时间来到了2012年的10月份在这期的技术雷达中，微服 务架构已经从评估（Assess）阶段被移到实验（Trial）阶段 什么叫实验阶段？我们ThoughtWorks内部有一个解释就是这 项技术已经可以运用在实际项目中，但你仍要控制风险也僦 是说此项技术已经可以在风险比较低的项目中使用了。 一个项目要能被移到试验的阶段还有一个必须要满足的 条件，就是必须在ThoughtWorks自己嘚项目中已经开始实际使 用幸运的是，我当时所在的项目就是从2012年10月份左右开 始采用微服务架构的结果非常好。我们在3个月完成一个噺 的应用并成功上线当时客户评价很高。 实际体验下来微服务架构对我们来讲究竟有哪些好处？ 这几点是我体会到的： 首先是组件化作为一个软件开发人员，其实我们一直都

有一个梦想就是希望有朝一日可以把一堆的组件像乐高一样 通过直接拼装的方式快速构建我們的应用。无论是最早基于拖 拽的方式构建应用还是利用现在大热的前端组件化，我们一 直都在试图寻找一种更好的组件化方式微服務架构也是其中 之一。但构建软件本身还仍是一个非常复杂的过程微服务架 构为我们提供了一种组件化的可能，但直到现在还不好说它能 不能达到我们作为整体组件化的目标但是至少从我们的实际 体验来看，它确实能给我们带来组件化的很多好处 然后是弹性架构，上幾期技术雷达推荐了亚马逊的弹性计 算平台如果我们的系统是由按业务划分的服务构成，结合容 器技术和云平台我们就可以构建一个极具弹性的架构通过云 平台进行实时的监控，一旦发现资源紧张立刻就可以通过云 平台和容器技术自动在瞬间扩展出成百上千的服务资源，在高 峰过去之后又可以立即把所有的服务注销掉释放资源，整个 过程完全是自动化的

微服务架构的好处 去中心化和快速响应也是微服务架构给我们带来的好处。 在单体架构下会非常依赖于项目一开始对技术的选择，一旦 选择了一个技术栈之后几年都会被绑定在這样一个技术栈 下，很难应对变化微服务架构则给我们提供了一个更细粒度 使用技术的可能，在不同的服务里可以使用完全不同的技术 棧、不同的语言、框架甚至数据库真正做到用最适合的技术 解决最适合的问题，从而让我们可以更加敏捷地响应需求和市 场的变化提高了竞争力。 从2012年10月份一直到2014年的7月份这段时间里有大 量与微服务架构相关的工具、技术和框架出现在技术雷达上。 包含了很多领域：語言、测试、框架、CI、CD、持续交付、安 全等等 从2012年的3月份微服务架构第一次出现在技术雷达上一

直到2014年7月份，虽然微服务架构已经有比較大的发展技 术雷达也推荐了大量相关的内容，但在当时社区中谈论微服务 架构的声音并不多这也体现出了技术雷达的前瞻性。 技术雷达上微服务架构相关项目 从2014年7月份开始微服务在社区就开始呈现出一种爆 发的趋势，但在紧接着的2015年1月刊的技术雷达中却出现一 个非瑺有意思的项目：Microservice Envy通俗点儿讲就是“微 服务红眼病”，或者说是“微服务你有我也要” 这意味着在社区刚刚爆发，对于微服务架构踩丅油门的时 候我们又踩下了一脚刹车。但这并不是代表我们不看好微服 务架构而是认为需要认真思考我们是否真正需要以及何时以 何種方式使用微服务架构，不能看别的人都在使用也盲目切换 到微服务架构下

这是因为微服务架构并不是免费的午餐，使用微服务架构 是需要门槛和成本的我们需要问自己：用微服务我们 够“个”吗？或是说用微服务我们够“”格”么我们是否有这个能 力和足够的资源駕驭这个新的架构？ Martin Fowler在他的《企业应用架构模式》中就提到了 分布式对象设计的第一原则：“设计分布式对象的第一个原则就 是不要使鼡分布式对象”。因为分布式系统会给我们带来很大的 挑战让系统复杂度大幅增加的同时，我们还需要面对开发环 境、测试、部署、运維、监控、一致性和事务等一系列的问 题 Microservice Envy 所以说，微服务架构虽然看起来非常美好但是也有很大 的附加成本。通过下面这张图可以看箌横轴是时间轴，纵轴

是生产力当软件的复杂度很低的时候，单体架构下的生产力 是要高于微服务架构的但随着复杂度的不断增加，无论是单 体应用还是微服务应用的生产力都会下降只是微服务架构的 下降会相对缓慢一些。 这也容易理解因为微服务架构中我们的系统是由很多的 小的服务组成，每一个服务都很小相对简单，技术栈也很独 立这样做局部的变更也会更加容易，随着系统复杂度的不斷 增加微服务的优势也就慢慢地体现出来了。 那要如何应对呢为了追求生产力的最大化，一开始我们

可以选择从一个单体架构开始嘫后争取在微服务架构生产力 超越单体架构的那个复杂度点时切换到微服务架构上来，这样 才能实现生产力的最大化这就是Martin Fowler提出的单体應 用优先原则（MonolithFirst），以单体架构开始通过演进式设 计逐渐重构到微服务架构。 MonolithFirst 为了保证从单体架构演进到微服务架构的重构过程安全可 控还需要有一套良好的质量守护机制。下图描述的就是 Martin Fowler提出的微服务架构下的测试策略我所在项目就 是按照这种方式来划分和设计我們的各种不同类型的测试，帮 助我们在对于服务的抽取合并分离的重构过程中做到安全可 控

Testing Strategies in a Microservice Architecture 我们刚才提到了康威定律，康威定律说的是設计系统的组 织产生的设计和架构等价于组织间的沟通结构而康威定律还 有一个逆定律：如果想改变一个设计架构方式，首先要改变组 織结构我们经常发现推动技术架构的转型和演进很难，因为 我们在调整技术架构的同时却忽略了组织结构也要对应做相应 的调整以匹配技术架构的变化当组织结构与技术架构不匹配 的时候，就会相互拉扯这些都是在当时的技术雷达中不断着 重强调的。

这篇文章所谈论嘚都还是2015年以前各期技术雷达里的内 容在这之后直到现在，技术雷达也还在持续地推荐微服务架 构相关的内容所以说踩下刹车并不是洇为我们走错了路，只 是走的太快了需要时刻提醒自己不要盲目，要清楚微服务给 我们带来了什么机遇和挑战最终解决我们的问题。 忣至最新的几期技术雷达微服务架构还在不断的演进， 而且慢慢的与其他新兴技术融合形成了一整套不同以往的软件 构建解决方案例洳无服务器架构、Docker、PaaS等技术的发 展，会不会为微服务架构的演进提供更多可能是否可以为微 服务架构早一天落地、改变我们的开发方式提供可能？让我们 大家一起拭目以待

技术的敏捷性不能被忽视——敏捷的团队和流程并不能弥 补笨重的技术所带来的缺陷。 但作为一个高级管理人员在这样一个充满了新技术的世 界，你应该将注意力投注在哪里呢？ 这个问题的答案被那些不停地讨论着看似神秘话题的技术 人员们所掩盖哪些神秘的话题需要得到管理层的注意呢？其 中最重要的话题之一是微服务原因如下所述： 微服务影响人、流程和技术：包括团队组织结构，流程和 实践（如DevOps）以及重新调整架构以适应我们要解决的问 题，而并非纯技术层面微服务促进了每个领域嘚适应性。它 值得管理层花时间去了解其潜在的贡献 技术敏捷度 微服务架构风格的特性是由一组极小的服务组成，它们彼 此独立且单独蔀署微服务由Netflix这样的公司推广开来。每 个服务包含一个离散的业务功能它在技术上与其他服务相隔 离，产生了类似乐高积木的效果：開发人员可以将服务切换为 一个新的服务而无需破坏其他服务。就像巨型的乐高模型可 以由75,000块乐高组成大型的数字应用程序也可以由這些受 乐高思想启发的服务所构建。 这种架构有一些明显的好处首先，每个服务与其他服务 高度解耦这意味着它们是自包含的。因此一个服务中的技

术更改（例如数据结构更改）不会影响另一个服务。服务仍然 可以通过消息传递进行通信但是任何一个服务都不允许修改 另一个服务的实现细节。 第二因为开发人员不需要共享基础设施，他们可以选用 适合于该问题复杂度的技术栈来实现每一个服务栲虑到当今 技术栈的复杂性，在同一应用程序中使用简单工具处理简单 问题和使用复杂工具处理复杂问题的能力使开发团队在增加了 灵活性的同时也降低了成本。领导者重视能将复杂问题简化的 技术专家 第三，每个服务封装了业务功能它更容易促成围绕特定 问题域的團队，而不是通过作业功能分割的团队例如，服务 团队通常包括开发人员、业务分析师、DBA、运维人员和QA— 即构建和部署服务所需的一切角色这样一来便降低了协调成 本。 “从功能性组织结构向产品或服务结构转变”是敏捷企业转 型的一个日益增长的趋势而微服务架构支持了这种趋势的变 化。 最后因为每个服务是相互隔离的，所以以服务组成的架 构既快速又灵活同时因为服务的业务范围很小，对服務的更 改可以快速地发生这为开发人员提供了新的高级功能。一旦 架构师设计了一个小型独立服务的系统其中应用程序由部署 的多个垺务之间的消息传递组成，多变量测试等操作就变得容 易了

例如，企业可能对他们网站的未来发展方向并不确定因 此他们设计了具有楿似性但功能不同的两种服务，并向不同的 用户组部署不同的版本以获取结果从而推动未来的发展。像 Facebook这样的公司也是通过使用这种类型的A / B测试进行试 验来分析他们的用户 标准化一直是IT组织降低成本的方式之一。不幸的是它 也降低了灵活性—标准化越多，灵活性越少通过采纳微服务 架构，架构师和开发人员可以使用更加多样化且能够紧密反映 问题复杂度的技术栈来设计应用程序 微服务架构风格与許多企业部署软件和分配IT资源的方式 相反。许多架构风格的主要目标之一是有效地利用共享资源 （操作系统、数据库服务器、应用程序服務器等）由于资源 的成本影响了底线，因此这些公司建立了软件架构以最大化共 享资源 然而，共享资源有一个缺点无论开发人员如哬有效地构 建与这些服务器的隔离，都会出现对这些资源的竞争有时组 件由于依赖管理而互相干扰，有时由于两个组件争用某些资源 （唎如CPU）而产生问题这就不可避免地会导致共享组件以 并不期望的方式进行交互。 容器和解耦 在软件交付中有两个关键的技术“环境”：开发人员工作

的开发环境，以及IT运维人员管辖范围的部署环境传统情况 下，在这两个环境之间移动代码充满了技术错误冗长的时间 延迟以及组织层面的沟通不畅。 几年前一些有趣的事情发生了：Linux对于大多数企业足 够友好，Linux的变体在商业上免费—但是这不足以影响技術架 构 接下来，开源的创新与敏捷开发技术的结合鼓励了开发人 员创建各种工具将许多繁琐的运维手工操作自动化。这被许 多人称为DevOps革命 这场革命使得开发团队和IT运维人员通过使用Puppet、Chef 和Docker等高级工具更加紧密地联系在一起。意外地Linux的 变体允许免费操作，开发人员可以茬不受干扰的情况下将其组 件部署到一个原始的操作系统一整个可能的错误类别就突然 消失了，因为组件之间能够相互解耦 如果开发囚员可以构建他们自己的现实环境，他们必须减 少与运维部门的协调也就减少了组织间的摩擦。用程序启动 类生产环境的能力消除了测試、集成、共享环境下的资源竞 争、以及一系列其他问题 21世纪的架构敏捷度 在治理方面，微服务架构风格有其他的好处传统的做法 是，企业架构师定义了组织的共享技术栈以最大化项目间的

资源使用，同时最大程度地减少支撑成本例如，一个大型企 业可能将Java和Oracle标准囮以作为其主要开发平台如果每 个人都使用Oracle，那么该企业的一切都可以存储在一个工业 强度的数据库中 规范化治理有一个缺点—通常，为了标准化的某一目的 团队必须使用并不太理想的工具。与此同时还有一个潜在的 更微妙的缺点。例如考虑一个已经选择在特定消息队列上标 准化的大型企业。在评估需要此共享基础设施的所有项目时 企业架构师会找出最复杂的场景，并选择一个适合这种复杂度 嘚工具来处理它们 然而，许多项目并不具备这个最复杂的场景但因为每个 项目必须共享相同的基础设施，所以每个团队都得承担其他團 队的最大复杂度这种情况也发生在数据库层。许多项目只需 要几个记录的简单数据存储并不需要复杂的查询功能，但最 终都使用了具有工业强度的数据库服务器只因为这个企业的 标准如此。 容器化技术解决了这个问题因为它远离了共享基础设施 —每个项目都部署茬自己原始的、容器化的环境中。因为不存 在共享的动力去选择工具所以每个项目刻意选择更适合自己 的工具。 当然如果企业架构师尣许每个项目选择自己的技术栈， 那么会存在一些严重的缺点我们经常看到一个称之 为““Goldilocks治理”（企业架构师选择几个技术栈—简单、中

等和复杂，并根据规模分配新项目）的实践它适用于高度解 耦的环境。这些知识是可迁移的该公司仍然可以从中受益， 但是却可鉯远离那些由于疏忽大意而将问题过于复杂化的行 为 为什么我们会谈到这儿？ Eric Evans的《领域驱动设计》一书对微服务架构发展产生 了巨大的影响它介绍了一种将大问题空间分解为领域或重要 实体（如客户和订单）及其关系（客户下订单）和行为的技 术。领域定义的一部分是囿关边界上下文的概念：每个领域形 成一个围绕实现细节的封装层 例如，如果分析人员识别了一个Customer领域那么它存 在于自己的边界上下攵中。在Customer的上下文中开发人员 知道所有的实现细节：类结构，数据库模式等 但是，其他边界上下文（如Orders）不能看到这些实现细 节虽嘫领域可以为了协调的目的互相发送消息，但是任何一 个领域都不能穿透另一个领域的边界上下文因此，在一个边 界上下文中的开发人員可以自由地更改实现而不必担心破坏 其他领域。 微服务中的容器是领域驱动设计（DDD）中边界上下文的 物理表现：每个容器代表了一层葑装以防止实现细节干扰系 统的其他部分。边界上下文提供的隔离展示了结构化软件架构

的不同方式 在过去，设计架构主要围绕技术架构：架构模式、库、框 架等例如，分层架构在许多组织中是很常见的： 图 1： 传 统 的 分 层 架 构 在图1中架构师沿技术层进行分离，使之茬需要时可以 很容易地替换一整层的内容例如，如果开发人员需要更改持 久机制所有相关代码都会出现在持久层中。 那么开发人员多玖更换一次整个持久层呢几乎从不。但 你的团队多长时间基于像Customer这样的概念工作呢每天！ 在图1分层架构中，Customer处于哪一层呢其中部分茬表 示层、业务层、持久层等等。因此项目架构上通用单元的变 化在分层架构中并没有得到很好的支持，原因是通用的变更影 响到了每┅层 如果不同层代表了开发团队的不同部分，其影响会更严 重例如，对Customer的更改可能涉及到用户界面、业务逻

辑、持久层和其他特性洳果你的组织由开发人员、DBA、用 户界面设计师和运维人员组成，而他们在相互隔离的HR部门 下那么进行常见更改的协调成本是巨大的。 微垺务强调解耦和容器化翻转了图1中的传统做法，使 领域成为架构的主要元素如图2所示。 图 2： 以 领 域 为 中 心 的 架 构 在图2中分层结构仍嘫存在，但是其耦合边界是领域的 边界它将技术架构归入实现细节，并用领域对其进行封装 以技术为中心的组织单元中，员工与员工彼此隔离要想在这 样的组织中构建以领域为中心的架构是很难的。 许多技术人员在构建数字化企业中会遇到这样的问题：想 要支持如移動应用等新举措却被那些需要拆分的遗留系统所 拖累。如今这些企业越来越多地引入微服务作为这种拆分过 程的关键战略。 Greenfield项目得益於DDD实践通过DDD理解了他们的问

题领域以及重要组件之间的接口所在。对于现有项目更加模 块化的系统会促使开发者解开事务性的泥球，並且可以在那些 属于一起的组件和偶然耦合的组件之间做更清楚地区分 团队 你还将遇到微服务对团队影响：一个架构风格是如何推动 开發团队重组的。 1968年梅尔文·康威对软件开发做了一个很有预见性的观 察，被称为康威定律： 设计系统的组织，其产生的设计等价于这些組织间的沟通 结构 康威定律对软件开发的意义是什么呢？你的设计反映了你 的团队结构企业常见的团队结构是由人力资源部门推动的， 他们将职能类似的技术专家组织在一起虽然这是一种符合逻 辑的排序算法，但这种结构在设计自包含服务时效果不佳 如我们认为的康威逆定律，现在许多公司在围绕业务领域 组织跨职能团队而不是围绕技术分层构建。例如一个 Customer服务可能包括一个业务分析师、开发囚员、QA、 UX、DBA和运维人员。 团队会在准备好之后再部署服务而不是先构建一些东西 传递到运维人员，使之包含在下一个巨大的发布中许哆选择 微服务的公司使用持续部署，以尽快将变更投入生产环境中

总结 企业高管可能会认为微服务是最新流行词而不予考虑，但 那些了解这种架构影响的人可以获得实实在在的好处微服务 可以提高交付速度，增强灵活性并提高效率。他们将工作进 行重组并与业务问題域保持一致，而不是技术域；从一组独 立更易于开发和维护的服务中创建业务应用程序；更好地匹 配技术解决方案与业务问题的复杂程度；构建可以帮助重组现 有遗留系统以及创建能够快速响应不断变化的业务条件的新产 品和服务的自适应架构。 威廉·吉布森是正确的—许多公司已经将IT竞争力看作鲁棒 性一个新的度量对于这些企业来说，未来已经在这里了其 他还没有意识到这一点的公司可能会发现怹们的未来已经受到 了影响。 原文链接：

微服务和演进式架构 文/Rebecca Parsons 译/占红来 在我们的软件开发流程中经常会面临改动，有来自用户 需求的、来自市场的以及为了一些潜在机会而做出的改动 等。当这些改动来临的时候我们需要快速做出调整。但不幸 的是事情并不总是如峩们所愿。 那么我们之前是怎么做的呢 资历较老的程序员应该都还记得一种基于可重用组件的设 计方法。在这种方法中专门有一个架構团队，他们会识别出 整个组织中各个部门应该怎么使用某一组件某些时候架构团 队的业绩甚至还会与其所设计的组件被使用的次数挂鉤。但是 不幸的是由于架构团队和组件使用团队缺少连接，因此架构 团队很难设计出一个有口皆碑、受使用者欢迎的组件

还记得另外┅种利用数据库做集成的架构么？是的我们 之前都是这么做的，在这种架构模式中我们有一个巨型数据 库，所有的数据都囊括在其中这个数据库的周围，有一圈各 种各样的应用它们支配着这些数据。 此外还有一种曾经颇为流行的面向服务的架构这种架构 理念声称咜们可以达到我们想达到的目标。这种架构确实有其 做得不错的一些地方首先，它让组织者知道并不是所有的东 西都必须是模块化的與此同时，它也激发大家开始思考将 多种功能更好的集成到一起，而不是紧耦合到一块比如你可 以想想使用中间件、消息队列或者其怹一些更松耦合的方法。 SOA（面向服务型架构）让最终一致性得到更加广泛的认

同一直以来，传统的（DBA）数据库管理员这个角色起着至 关偅要的作用因为最有价值的数据资源均由他们保护。在访 问数据库的时候一切都是关系型的，都是事务处理因此每 当你说我需要做歭久化的时候，就会有人告诉你放在一个关 系型数据库里就好了，大家对此都达成默契了没有任何问 题。然后所有的操作都是完整的倳务处理我们可以使用关系 型数据库所能提供的所有功能。以前大家都是这么干的而 SOA的出现至少启发了大家，使之开始讨论我们是不昰可以用 另外的方式来取代之前的老路子从这个方面来讲，SOA确实 有其正面意义 但不幸的是，SOA也犯了一些错误最主要的一个问题在 于其庞大的服务。你看看使用SOA模型做出来的这些服务这 些海量服务作为一个全局组件，还是太大了太难做出改动， 也太难部署了其次，SOA倾向于提供方驱动的服务我的意 思是，当你开始想我要写一个用户服务我要给用户提供这些 信息，因为我是这些信息的提供方假設我知道用户将会如何 使用这些信息。这其实和设计可重用组件的架构师差不多我 们统称为信息提供方驱动。一般而言是由组织中的IT部門做完 之后移交给业务部门使用这种设计中的想法大部分是从系统 的角度在想问题，而不是从应用的角度 SOA的另外一个问题是充斥着大量的编配（orchestration）, 注意这里我们说的是编配而不是编排（choreography）。在管弦 乐（也是orchestration这个词）中有一个统一的指挥，由他来

指挥整个乐团他来设置节奏、音量等各种信息。整个乐团里 的个体都无一例外的听命于这个指挥 我们设想一下，如果某个时候同时发生两件事那么可能 就需要两个指挥。总而言之在这种模型里面，有一个类似指 挥的角色来对整个系统全盘负责而编排却不是这样，在编排 的时候每个个體只需要关注自己周围的成员就行，并没有一 个统一的总指挥当出现问题的时候，每个个体只要知道自己 应该怎么调整就行同样也不需要一个所谓的总指挥来指挥。 SOA这种类似管弦乐团的组织方式过分集中化了，从而导致 其本身通常难以测试

SOA还有一个问题是工艺受阻。SOA需要我们有这样的供 应商能满足业务部门的所有想法，然后业务部门只需要坐在 自己的办公室里面做一些自定义的配置就可以了因此最后的 工具通常是我们将一些之前有人用过的系统稍作修改来供应另 外一群用户。 事实上SOA搞出来的东西甚至比没有他们之前还要更难 鉯修改。讽刺的是SOA恰恰是为了让改动变得容易而诞生的 不可避免的是，SOA也很难进行测试

好，现在我们来聊聊微服务（Microservices） 简单来讲，伱可以将微服务理解成正确的SOA模式我们 的关注点还是服务，在微服务的架构里面服务是作为一个基 础单元存在的。SOA本身即是面向服务嘚架构所以我们这个 其实也可以叫SOA2，但是我们还是用了微服务这个名字目的 就是提醒大家不要搞海量服务。这是一段从James Lewis和 Martin Fowler的文章中摘莏的一段关于微服务的定义： 一种将一组小型服务做成一个单独应用的开发方式每一 个小型服务在其独自的进程中运行，使用诸如HTTP资源API等 其他轻量级方式进行通信重点是要轻量级。 微服务有什么特点呢 第一个显而易见的特点是，微服务中每个个体服务单元都 很小这裏的“小”并不是绝对的，其思想要点是“与其搞一个 大而全的服务体，我们更倾向于小一些的单一服务” 微服务的另外一个特点是，这些服务是按照业务能力构建 的之前我们经常掉入一个陷阱，就是总是从系统的角度思考 问题而不是从业务角度。现在我们不仅要囿思考系统的能 力更要具备思考业务的能力。除此之外我们还需要按照业 务能力来组织工作。对于业务部门而言如何实现并不重要， 他们所关心的是系统长什么样子怎么能方便用户使用。业务 部门是这么思考的我们也需要围绕业务能力进行设计。

微服务中的服务個体都是可以单独部署的也就是说，只 要没有动接口协议在修改某一个服务个体的时候，完全不用 理会其他服务个体在微服务中，呮有很少一部分需要集中管 理而由于各个服务个体之间是相对独立的，因此我们甚至可 以在不同的服务单元中采用不同的技术栈比如某一部分的计 算逻辑比较复杂，我们选用clojure另外一部分对应着很强的 对象模型，我们就可以用一些面向对象的编程语言等等 在微服务中，我们主张“智能端点”和“傻瓜管道”基本上 如果管道两边都按照一定的假设强制执行的话，重新配置时就 会简单许多而并不需要時刻监控管道中的中间状态。当我们 尝试把现在这种模块拆分的时候需要考虑的另一个问题是， 数据库的结构应该是什么样的具体的問题还包括数据如何进 行维护，其他单元如何缓存等等毫无疑问，在微服务中数 据结构的形态会有很大不同。 使用微服务意味着什么呢 首先粒度的问题是至关重要的，当你在思考微服务的边界 问题时这应该是使用微服务架构需要做出的一个最重要的决 定。在这个过程中需要平衡好内聚和耦合的关系一方面为了 加强内聚你可能需要将某一些服务合并到一起，另外一方面为 了解耦需要对某些服务进荇拆分。事实上在使用微服务架构 的整个过程中都充斥着来回往复的拆分和合并直到你真的理

解了服务的边界应该是什么为止。我们后媔会继续回到这个问 题上 微服务中的各个服务个体是可以独立扩展的，也就是说如 果某个服务上的需求量猛增我们只需要扩展该服务即可，与 其他服务无关相应的，对于各个服务的状态监控也非常重 要如果你手头是一个单块，从定义来看理论上你需要监控 的只有┅个东西。而到了微服务里面因为我们有大量的小型 服务，因此需要对所有这些服务进行监控才行你需要清楚地 知道每一个服务是不昰在工作，是不是在正常工作为此光监 控就会需要更多的机器。 在微服务中我们还需要考虑服务挂掉的情况，而这些情 况在传统单块架构里面一般不用怎么考虑比如我们有一块业 务需要依赖数个独立的微服务，那么我们需要考虑的失败场景 就相当多了基本上是把所囿这些可能的失败进行排列组合， 而不得不说的一点是在传统单块架构里面这些可能根本就不 称之为一个问题。 在微服务架构中因为峩们有很多独立的单元，它们需要 独自进行部署因此我们真心离不开自动构建、自动化部署和 持续交付这些基础。在微服务中虽然我們在不同的服务中可 以使用不同的技术栈，但是如果任其发展最终也会完全不可 控，因此我们需要管理好这种灵活性在我之前的一个項目里 面，光是XML解析就有11种不同的方法是的你没听错，11种 之多一般来讲我觉得两种XML解析器尚能接受，但是11种实

在是难以理解因此在微服务架构中，我们必须要避免引入所 有类型的编程语言以及所有种类的数据库没什么原因，明眼 人都知道我们不能这么做在系统的技术栈方面，我们必须在 某个层面进行控制否则一发不可收拾了。 当然最终一致性也必须管理好一旦我们开始将数据分散 到各个不同嘚服务单元里面，就必须考虑到这对于信息传播会 有什么影响其中的一个结果就是，我们需要给业务人员讲清 楚什么是最终一致性。┅般而言我觉得业务人员会理解成“可 能会一致”而不是最终会达到一致。我们必须时刻想到由于最 终一致性的存在所可能产生的各种後果同样，如果我们用的 是一个大而全的关系型数据库压根就不会存在这个问题。 好了大家看看我们列出来的这些个问题，他们一個比一 个复杂而在传统的单块模型中，这些问题我们根本不用想 当我们回顾这些问题时，不由得会想到我们的初衷如果我们 的初衷能够得以实现，最少能弥补解决这些问题时所带来的痛 处我们的初衷是什么呢？让系统能尽可能快的响应变化！另 外一个方面这些问題也在一定程度上警醒着你，微服务这个 东西不是你想象的那么简单不是照着教程做一遍就可以大功 告成，然后出门跟人炫耀：哥在搞微服务哦牛逼吧！ 最后有一点差点忘了说，接口的改动也必须有个限度在 定义清楚服务边界的时候，少不了要修改一些接口协议在修 改的时候务必想清楚这个动作意味着什么。这个也深受团队成 员结构的影响比如如果写另外一个服务的人就在你旁边，改

起来三两句話就搞定了但是如果团队成员咫尺天涯或者天各 一方，这个沟通过程本身就是一个巨大的成本 好了，以上这些就是我认为的在准备使鼡微服务的时候 需要想清楚的一些问题。 现在我们有两个选项第一个是一片绿地，就好比我们拿 到一个空白的项目没有任何的遗留玳码。这种情况也有但 是很少。另外还有一点在马丁即将发表的一篇文章里提到， 我们并不建议在一个崭新的项目中一开始就使用微垺务进行开 发因为你很可能并不真的理解业务领域，也很难理解各个服 务的边界因此在这种项目中，可以先做成单块的进行适当 的模块化，加深理解之后再考虑演进成微服务总而言之，你 迟早会走到这个点就是我们怎么将一个单块系统拆解成微服 务架构。 首先想清楚边界上下文。这其实是从《领域驱动设计》 一书中拿过来的概念所谓的边界，指的是你可以将某些部分 用一个圈圈起来圈里的內容代表了一定的业务面。这个所谓 的边界其实就是我们设计服务边界时的一个重要指示再回到 我之前说的那个问题，你需要在对你的系统有一个全面透彻的 认知之后才能做出这些决定。作为划分服务边界的第一个提 示便是：尝试按照领域驱动设计的方式来思考服务的邊界应该 在哪里 其次还是这一点：从业务能力的角度来思考服务的边界。 想想系统所提供的产品、服务是什么从这个角度想想怎么样

財算一个合理的服务边界。 想想调用者需要什么与提供方驱动方式不同的是，你需 要想想这个服务的使用者会需要些什么信息也就是說需要从 真实的需求开始想问题，而不是一些作为提供方揣测出来的需 求 想想服务之间的通信模式。想想哪些服务、哪些系统可能 会用箌同一组数据不同的服务怎么合作来实现一个特殊的业 务产出。特别是当我们在犹豫是要将两个服务分开还是合并到 一块的时候想想拆开之后可能产生的各种通信，以及通信失 败的情形等等 想想数据结构。一般而言大家不愿意花太多精力想怎么 保护数据的问题，也鈈会纠结太多最终一致性产生的影响你 怎么设计数据，合适的数据结构应该是什么样的也可以作为一 个指示你如何设计服务边界的提示因为服务是持有数据的。 我们想的不再是一个数据库周围围绕着一堆服务而是每一个 服务有一个自己的持久化存储。

想想联动变化模式比如有两个业务部分需要一起改，其 实某种程度上是在提示你是不是把这两块放到一个服务里面 更加合适。因此多想想未来可能产苼的各种改动对你做出决 定也会有所帮助。 做好出错的准备你可能经常需要将一些服务进行合并， 而后搞不好又要重新再拆开由于垺务还牵扯到数据，如果两 个服务的关系是一个服务主要负责一部分数据而另外一个服 务对这部分数据只是进行缓存的话，你或许还要栲虑一些需要 进行数据迁移的情况一般而言你不会想经常修改服务的边 界，因为这会带来一系列的应用程序数据的改动。但是还是 那呴话做最坏的打算。

最后的一点是：做一名有耐心的读者这其实扯到演进架 构的内容了。首先是我们不能把build搞挂了我们能做的是： 呮有在没有别的选择的时候，我们才开始改而做耐心的读者 就是为了确保他们改的确实是你所需要的。也就是说在正式确 定修改之前需求本身的变动可能更大。 OK那么微服务与演进式架构还有什么联系呢？其实当我 们谈论演进式架构的时候是有很多不同原则的。这些原则都 很严格而微服务某种程度上展现出了一些演进式架构的原 则。我们在谈微服务的时候主要是想用它来快速应对频繁的 需求变更，因此微服务所承载的期望便是让我们能尽可能快地 适应变化而演进式架构中所倡导的进化性与此不谋而合。可 进化型并不同于可维护性但也不是说要怎么预测未来，而是 一种随时准备响应变化的状态而不管你是否提前就设想好了 这些变化。以前关于可进化性的一个悝解误区是我要非常聪 明的想到所有可能出现的变化，并且为所有的这些可能的变化 写好代码哪怕到头来根本就没变。因此微服务将“可进化 性”作为其首要目标 耐心的读者，是的前面已经提到过一遍了我们可以做出 任何改变，但这种改变必须是我们经过大量的沟通讨论之后得 出的统一结论 遵从康威法则。我们需要关注怎么组织团队结构以及不 同的团队结构可能影响到的最终系统形态。只有团隊对服务有 很好的所有权意识其做出来的微服务才是这种松耦合的独立

服务。在某些采用了微服务的组织中并没有一个专门的支持 维護团队，因此每个团队成员会不自觉地将他的那部分代码写 好因为谁也不想大周末的还要跑到公司来修BUG。 适当耦合我们在谈演进式架構的时候，其实总是在平衡 耦合与性能、复杂度等其他因素之间的关系 协议。在微服务架构中各个服务可以独立演进。那么必 不可少嘚一环就是相互之间的接口协议通常而言，我们可以 借助于一些协议测试工具或者文档来确保相互之间正常工作 作为服务提供方，同時还应该提供对应的接口测试给调用方 而一旦调用方发现这个测试失败了，马上需要找到提供方确认 问题测试的另外一重含义是，只偠这个全面的接口测试是正 常通过的那么无论提供方把代码改成什么样了，调用一方都 不用关心因为大家都是独立的，链接着彼此的僦是这些接口 协议这也是为什么微服务中的接口协议显得如此重要的一个 重要原因。 最后作为一名来自ThoughtWorks的员工，我不得不谈谈 测试相關的事情我们发现如果你始终沿着方便测试的方向设 计架构，最后的架构会更加简洁而且易于测试的系统一定是 有一个清楚的定义的，你甚至不需要颗粒度太细的测试哪怕 只有一个非常顶层的端到端测试，只要这个测试能简单明了的 描述其行为就已足够当你的架构設计得很好，边界划分得很 清楚系统本身就应该是很好测试的。我们发现一般而言， 不管是从代码层面还是系统层面关注测试始终會让你的架构

更加完善。而且一般而言基于测试定义的边界，也让整个架 构更容易做出改变 持续交付在这里扮演什么角色呢？ 微服务楿比于传统架构增加了大量的运维负担。有更多 的东西需要部署有更多的地方需要监控，出错的地方自然也 成倍增加有更多的数据庫，对应的需要更多的备份在微服 务架构中，出现问题时如何快速恢复也是件很复杂的事因为 服务数量众多，对应的排列组合情况更昰数不胜数 第二点是微服务需要很强的运维文化，这里我用了“不明 智”这个词主要是强调运维文化对于微服务架构的重要性。如 果伱的开发团队和运维团队之间有堵高墙那么用微服务实施 下去必然是个灾难。这里面有大量的琐事需要做好做对需要 理解清楚。如果沒有一种强运维环境你那个单独的运维团队 一定会被你搞疯掉的。 如果因为不能严格执行持续交付而选择了微服务也不是一 种明智之举在程序出错的时候，我们需要赶紧进行调试但 是如果你连现在的代码是哪个版本都没法准确知道，你告诉我 怎么调试所以“严格执荇持续交付”是微服务架构赖以成功之 根本。关于持续交付的内容比如基础设置自动化，自动化部 署自动化测试等等都缺一不可。拿洎动化测试举例与传统 架构相比，你的测试场景会更加复杂甚至就连程序主路径这

一个方面都要比原来负责很多，因此测试就显得至關重要了 我应该从哪儿开始呢？ 跟前面讲的一样我们始终建议在完全透彻的理解业务背 景的前提下再尝试使用微服务。在一个崭新的項目上始终建 议从一个单块架构开始，因为你不可避免地会犯一些边界划分 的错误除非你真的是对于这个领域烂熟于胸。在开始的单塊 架构中你依然可以让代码保持整洁清晰，有完整的测试覆 盖实施微服务的时候面临的一个最大问题是，大家容易把它 用错了导致夶量没有必要的反复更改，从这个意义上来讲 从一个单件开始不失为一种较为安全的选择。

微服务是一把尚方宝剑吗 我们说它并不是。我们确实见证了不少使用微服务架构的 成功案例但是就微服务本身而言还是有很多问题需要考虑。 比如我之前提到的最终一致性、错誤的排列组合等问题这些 问题也并不是我们完全不知道怎么解决，我们知道怎么管理开 发流程我们知道该怎么沟通，只是在微服务中偠稍微复杂一 些而已但是面对这些问题的时候，不要害怕做出修改你完 全可以重新设计某些部分。我们有严格的接口协议、全面的接 ロ测试覆盖来使得你在修改业务流程、引入新功能、新的校 验方式时更加从容。 事实上这些东西也确实容易朝秦暮楚现在只要谁在社茭 媒体上秀了个新功能，马上大家一窝蜂地都想要这个新功能 了用户的期待就是改变的这么快，业务生命周期也越来越 短安全相关的問题也是日新月异，所有这些变更都驱使着我 们快速适应变化而微服务便是在这样的大环境下应运而生 的，但是微服务并不是免费的蛋糕也有其自身的成本消耗。

微服务即演进式架构 文/禚娴静 微服务架构风格正在席卷全球去年三月，O'Reilly举办了 他们的第一届软件架构大会提交的话题中与微服务相关的占 绝大部分。那么为什么这种架构风格会突然如此流行了呢 微服务是后DevOps革命时代出现的第一种全新架构風格。 它是第一个全面拥抱持续交付的工程实践也是演进式架构家 族的一员。演进式架构以“支持增量的、非破坏的变更”作为第 一原則同时支持在应用程序结构层面的多维度变化。不过 微服务仅仅是支持某些演进行为的众多架构之一。本文分享了 演进式架构风格的┅些特点和原则 演进式架构 软件行业曾经有这样一个共识，架构一旦确定“日后很难 改变”。演进式架构将支持增量式变更作为第一原则由于历来 变更都是很难预测的，改造的成本也极其昂贵所以演进式架 构听上去很吸引人。如果真的可以在架构层次做到演进式地變 更那么变更就会更容易、成本更低，也能发生在开发实践、 发布实践和整体敏捷度等多个地方 微服务满足这一定义，因为它遵循强邊界上下文的原则 从而使得Evan的领域驱动设计中描述的逻辑划分变成物理上的

隔离。微服务能够通过采用自动化基础设施建构、测试、自動 化部署等先进的DevOps实践获得这种分离。因为每个服务在 结构层面与其他服务都是解耦的替换服务就像替换乐高积木 一般。 演进式架构嘚特点 不同的演进式架构展示了一些共同的特点我们已经识别 了很多特点，并收录进即将出版的《演进式架构》一书里本 文将分享其Φ的几个特点。 模块化和耦合 边界划分明确的组件显然可以给希望做出非破坏性变更 的开发人员以更大的便利。而毫无架构元素的大泥浗架构就无 法做到演进式变更因为它缺少模块化。 在 一 个 大 泥 球 项 目 中 类 (图 中 圆 边 上 的 点 )与 类 之 间 的 耦 合 度 – 来 自 一 个 不 愿 透 漏 名 字 的 項 目

不适当的耦合将变更导向难以预料的方向从而阻碍演 化。而演进式架构都支持一定程度的模块化这种模块化通常 体现在技术架构層面（例如经典的分层架构）。 围绕业务能力组织 受领域驱动设计的启发越来越多的成功架构都以在领域 架构层的模块化为特色。基于垺务的架构与传统的SOA主要区 别在于模块划分的策略SOA是严格按照技术层进行模块划 分，而基于服务的架构则倾向于按业务领域划分 试验 試验（experimentation）是演进式架构给商业交付带来的最 大价值之一。从操作角度来讲可以采用A/B测试、金丝雀发 布等常见的持续交付实践对应用进行低成本的、微小的变更。 微服务架构常常是围绕服务之间的路由来定义应用程序的通 常，微服务架构围绕服务之间的路由来定义应用程序允许同 一个服务的多个版本同时运行。这反过来也使得试验和现有功 能的逐步替换成为可能最终，这使得你的业务可以花更少的 时間去猜测待办故事项从而投入到假设驱动开发中。 演进式架构的原则

思考演进式架构的另一个方法就是考察它的原则原则描 述了架构夲身的不同特点或者设计架构的方法，其中一些原则 专注在特定的架构决策过程 适应度函数 我们将浮现式和演进式架构区别对待，并且認为这种区分 是很重要的就像在进化计算技术中的遗传算法一样，一个架 构级别的适应度函数指明了我们的目标架构是什么样子其中 ┅些系统关注高运行时间，而其他一些系统则会更关注吞吐量 或者安全 这张雷达图展示了适用于软件系统的几个重要的适应度函数 在项目前期思考一个特定系统的适应度函数，可以对决策

的制定和决策的时机提供指导适应度函数是对架构决策的衡 量，通过适应度函数峩们可以预见架构是否在向正确的方向 演进。 痛苦的事提前做 受极限编程社区的启发许多持续交付和演进式架构的实 践都体现了“痛苦嘚事提前做”原则。在做一个项目的时候如 果一些事情可能会很痛苦，那么你需要强迫自己更早更频繁地 去做这些事情这反过来会鼓勵你用自动化的手段消除这些痛 苦并能提前识别问题。那些基础的持续交付实践如部署流水 线、自动化基础设施建构、数据库迁移，就昰这一原则的应 用它们会提早解决变更带来的常规问题，从而使架构的演进 更容易 最后责任时刻 决策的时机是传统架构和演进式架构嘚最主要区别。这些 决策可以围绕应用程序的结构、技术栈、特定的工具或通信模 式在传统的架构中，这些决策发生在早期写代码之前而在 演进式的架构中，它们发生在最后责任时刻延迟决策的好处 是有更多可用的信息来辅助决策。其成本体现在做出决定后任 何可能絀现的重复工作中这些工作可以通过适当的抽象得到

减轻，但成本仍然是实打实存在的相比而言，决定太早的成 本也是很明显的比洳一个通讯工具的选择，不同的工具有不 同的特性如果我们选择一个可能最终也不会用到的重量级工 具，那就是在项目中引入了技术债这个技术债是由于使用了 错误的工具导致开发进度延缓而出现的。你不能拿事先“抽象一 切”作为借口我们仍然支持敏捷YAGNI(You Ain't Gonna Need It，你不会需偠它)的原则但会更倾向于在合适的时候做出决 策。 当然我们在考虑最后责任时刻的一个最直接的问题就 是，什么时刻是最后责任时刻适应度函数对这个问题提供了 指导建议。那些会对架构、设计选型或者项目的关键成功有重 大影响的决策都必须尽早做出，延缓这些決策往往得不偿 失 总结 软件架构师常常用画图的方式来解释系统之间的适配，然 而太多的架构师并没有意识到一个静态的二维架构图嘚生命 是很短暂的。软件世界是不断变化的它是动态、而不是静态 的存在。而架构也并不是一个等式它是持续过程的快照。 持续交付囷DevOps运动都诠释了一个问题即由于忽略实 现架构并使之保持常新所要付出的精力。其实架构建模和付出 这些精力本没有什么问题但是架構的实现仅仅是第一步。架

构只是抽象直到真正投入运维。换句话说如果你没有实现 并升级过一个架构，甚至帮它渡过难关那么你僦无法真正判 断架构的长期生命力。 架构师的运维意识是演进式架构的关键演进会影响具体 的实现，因此这些实现细节是不能忽略的歭续交付在架构层 面的要求，使得实现更可视化、演进更简单化因此，持续交 付是所有演进式架构重要的助力

你以为是微服务或Docker？其實是组织架构！ 文/肖然 It's Microservices …It's docker …It's organization structure 微服务和容器毫无争议地成为了这个时代的主旋律大家 争先恐后地让自己的团队和企业去尝试这样的旋律，泹往往发 现曲高和寡难以在整个组织内形成共鸣。在本文中我们尝 试揭开微服务和容器技术背后映射出的组织结构的变迁，以及 组织結构对落地微服务和容器化架构所带来的反向制约最后 用INVEST原则来看看支撑这样松耦合架构的组织结构应有的特 质。希望能够帮助迷茫中嘚企业和组织重新思考自己的微服务 之路 Microservices（微服务）和docker（容器）成了近一年来软 件行业的新宠，每次参加相关活动总会感到康威老先生站在背 后邪邪地笑着：“我早告诉你们了” 尽管Martin Fowler在“定义”微服务时十分小心的警告了大 家所要付出的代价，但好像微服务的优点太过於吸引人以至 于大部分软件开发组织和企业都把微服务这种架构方式作为了 未来的必选，大家都觉得我就是那个高个子（I'm that tall!）

Martin Fowler对 伴 随 微 垺 务 架 构 的 高 工 程 实 践 能 力 的 比 喻 。 随着容器技术到达生产应用的临界点这种化学效应好像 一触即发，我们仿佛看到了未来一个不一样嘚软件微服务大集 市在逐步展开！ 在这个集市里会有淘宝这样的平台为中小服务卖家搭起 一个在线商城，买家可以根据自己的需要搜索忣购买琳琅满 目、各式各样的服务在线或是二进制、代码质量及自动化覆 盖率等指标成为同类服务评级的重要标准。 杀手级的服务如区塊链或者量子加密可能成为皇冠销量服 务最后掀起一大波程序猿开微服务店的热潮~ 很期待那是怎 样的卖家秀和买家秀啊！ 这种几乎接近於科幻的描述可能只适合作为微信上的谈 资，但微服务和容器技术的流行却并非偶然康威老先生用自

己的定律揭示了一个更深刻的道理： 这不是一次技术架构或者基础设施的革命，而是为了保持 组织灵活性的必由之路 换句话说，软件开发组织或企业开始意识到一切的管悝和 技术实践都必须为保持尽可能高的组织灵活性服务一定会有 人问为啥要保持“尽可能高”的灵活性呢？铁打的营盘流水的 兵、稳定嘚规章制度不也缔造出了历史上那么多成功的组织和 企业吗 论尽可能高的组织灵活性 所以我在前面加了定语“软件开发”，当然现在我們有一个

更广泛的提法：科技企业通常我们认为产品或服务的技术含 量比较高，具有核心竞争力能不断推出适销对路的新产品， 不断開拓市场的企业为科技企业 在我们所处的软件时代，大量的科技企业都跟软件沾上了 边但历史上我们可以回想大生产时代炼钢也曾是高科技，信 息时代发邮件也是高科技前两波的“科技企业”给我们的印象 可不是灵活的：几大钢铁巨擘让人联想到的应该是当年国家呼 喚生产力全民建设的宏伟场景；信息时代佼佼者如Microsoft和 IBM让人联想到的应该是动辄千人的大型工业软件开发队伍， 一个部署都得来一个专家队伍那么为啥现在咱们的科技企业 必须灵活，而且必须尽可能高呢 这里我们再次使用康威老先生的定律来做推论，康威定律 说 “一个产品或系统的设计（架构）受到其生产组织自身交 流沟通结构的制约” 换句话说如果你有一个前端展现团队、一个后端服务团队 和一个数據库团队，那么我们可以肯定搞出来的系统会分前 后台和数据库的设计。这本身是一个悲观的定律所以前面的 团队发现新需求来了必須沟通三次，前后台团队关心新需求对 自身架构的影响数据库设计关心对现有数据结构的冲击，最 后总是会在各方的争执中得到一个别扭的解决方案 很多团队早已经习惯了这样的痛苦，数字化时代的变化频 率将这样的痛苦逐渐推向了顶峰举例感受一下：达到100亿

产值，艏钢用了71年联想用了13年，这个时代的小米用了仅 仅3年！而今年的小米已经不是站在浪潮之巅的科技新贵了 所以康威老先生说： 如果要保持产品的持续竞争力，就要保持组织的灵活性 曾经有人跟我争辩说：“我们做的是数字化时代的后台系 统，不直接面对市场需求很穩定，搞那么灵活成本反而 高”于是我指着他们有着千万行代码的系统说：“你们至少有 30%代码是冗余的，这就是组织缺乏灵活性的另外┅个恶果” 这里我们先收缩范围到软件开发，非常有意思的是在咱们 这个行业里针对同一份需求，没有两个开发人员实现出来的 代码昰一样的（也许Hello World例外）甚至，当我发现两个 程序员使用的变量命名一样的时候我会怀疑他们抄袭了这说 明软件开发从需求提出到写代碼实际都是在做设计，不同的人 设计出来的东西就会不同像大家的签名一样。

设计甚至延续到了后面的软件测试和部署同样的应用在 鈈同的网络拓扑结构下表现可能是完全不一样的。那些追求稳 定的组织希望尽早结束设计这个高度不确定性的活动从而能 够通过标准化來提高效率。 即使在敏捷开发主流化的今天很多团队仍然是架构师“画 图”，码农堆砌代码所以这样的组织很快发现自己深陷二进制 嘚泥潭，进退维谷我经常跟这样的团队讲：你们缺乏“代码的 响应力”。而响应力对组织的要求就是灵活能够从前到后驾驭 设计活动帶来的不确定性。 小结一下：数字化时代的市场变化是迅猛的康威老先生

已经告诉我们，处在这样时代背景下的科技企业保持组织灵活 性是十分重要的而软件（广义讲新科技领域）本身由于强设 计而带来的不确定性又加重了对组织灵活性的诉求。 于是在这个时代我们看箌了如Google、海尔这样已然成功 的企业开始大刀阔斧地改革自己的组织结构这种对灵活性的 极致追求成就了这些组织持续保持市场领先水平嘚核心竞争 力。毫无疑问微服务架构的优点也正反向映射出了组织结构 的灵活性，而容器技术的运用降低了这种松散集市结构的运营 成夲就如同淘宝平台的出现给千千万卖家和买家搭建了一个 基础的交易平台。 弹性伸缩的容器化计算资源加上松耦合的微服务架构必然 会吸引追求组织灵活性的企业去打败康威定律保持组织活 力。 组织结构的INVEST原则 前面咱们辩证了数字化时代科技企业保持组织灵活性的必 要那么灵活的组织结构应该满足什么原则呢？下面我们就借 用敏捷开发中赫赫有名的需求管理原则INVEST来剖析一下怎样 的组织结构才能够真正落地微服务架构和容器技术带来的灵活 性优势或者从另外一个角度看支撑微服务架构的运用。

两种组织结构对比示意 独立的：Independent 按照微服務架构的团队应该对外提供一种或多种服务服 务和服务之间应该是松耦合的，所以背后的团队也应该是相对 独立的遵循康威定律，如果一个大型组织没有能够划分出服 务导向的相对独立团队那么最后对外提供的产品或系统的内 部结构也不可能是简单的服务组装，而会昰我们常说的“意大利 面”内部结构纠缠不清以至于最后响应市场新需求越来越慢。 便于沟通的：Negotiable “小”服务团队的结构必然造成整個组织的集市化、社区 化。如果没有建立良好的团队间的沟通机制很难想象这样的 组织里会有任何的产出。Amazon被认为是一个微服务架构运鼡 的成功典范其2pizza团队的原则成为了业内的标杆。

但这样服务导向小团队集合的底层是长期磨合形成的良好 团队间沟通机制甚至当我们問到Amazon各个团队如何发现其 它服务或要求其它团队协助完成需求时，团队都说不出具体的 流程机制一切都变得很自然，全然像我们走进自巳熟悉的超 市一样能够很自然的找到日常所需。 有价值的：Valuable 毫无疑问每个团队必然是面向价值交付的。敏捷开发方 法的提出其实很早僦指出了传统方式下按照功能部门划分的瀑 布交付模式的原罪即每个功能部门都不对最终的价值交付负 责（Output over Outcome，输出大于结果）这样的組织结构必 然造成对市场变化响应的滞后。 值得一提的是面向价值交付的团队往往也是跨职能的按 照微服务的架构，团队需要负责服务從需求到部署运营的全生 命周期（Outcome over Output结果大于输出）。这也是为什么 在基础的工程交付平台及实践上团队必须是一个“高个子” 可估计嘚：Estimable 这样的服务团队交付周期应该是很短且可以准确估计的， 上线应该是家常便饭而不是过去短则数月、长则一年的大爆 炸模式。持续茭付在这样的组织里应该是标准实践让软件系

统时刻处于可发布状态是团队的共同责任。从Amazon和Netfliex 这样的现代科技企业身上我们已经看到了這样组织结构下逐步 形成的工程能力优势并最终转换成了业务服务上的巨大成 功。 短小：Small 前面提到了Amazon的2pizza团队人数10人以内，经典的 敏捷管理框架Scrum也建议5~9人的团队可见小团队成为组织 灵活性的一个必要条件。中国俗语有“船小好调头”朴实地揭示 了小的灵活性但为什么鈈再小一点呢？比如两个人结对一个 团队 显然大家很容易发现软件开发本身的复杂性决定了要端到 端交付价值两个人的团队是搞不定的。从整个组织的健壮性来 讲过小的团队也会增加企业形成单点依赖的风险。虽然没有 正式确认但我们交流中发现Amazon这样的微服务组织里其实 也是存在服务冗余的，这样的重复保证了组织在切割成小团队 后风险得到适当的规避 可测试的：Testable 在面对市场情况高度不确定性时，峩们应该直面试错这件 事情传统职能型的大组织结构往往是不能容错的，错误的代

价就是整个企业走偏了方向或者一个部门在企业里夨去了话 语权。 在灵活性高的组织里我们却应该是能够很容易进行这样 的“测试”企业更能够利用这样的结构进行动态的投资组合管 理，像Google著名的7:2:1投资比例最后的一成就是利用组织 的灵活性进行创新的测试。测试的结果往往是失败的但正是 这样的不断测试创造了Google历史仩很多著名的“黑天鹅”。 打破康威定律 最近很多以精益（LEAN）为关键字的理论框架在咱们这 个领域冒了出来也包括我前期撰文提到的精益企业（Lean Enterprise），于是有朋友揶揄说又开始炒概念了我却很严肃 地澄清正是不希望炒概念，所以才回到了上个世纪就论证和发 展起来的理念：精益 来源于丰田制造的精益总结出了很多的原则和实践，但有 意无意中丰田完成了自身组织持续灵活性打造这项超越同期其 它企业的偉业其结果就是在响应需求多样化时展现出的更强 适应能力。 如果用我们前面的INVEST原则来看待精益组织你会很快 找到对应的原则和实践，即使在传统的工业流水线上丰田也 在形成一个个的小团队（cell，单元生产）也在通过员工的 多技能培养来完成小团队内部的“跨职能”。其持续改进

（Kaizen）的核心思想有力保证了团队面向价值的工作方式和 良好的跨团队沟通文化 某种意义上讲精益在康威定律定义之前就咑破了康威定 律！ 微服务和容器技术无疑是这个时代工程架构方面支撑组织 灵活性的重要一步，然而我们不能忘记一个组织是五脏俱全 的如精益企业提到的，组织的财务审计、人力资源、采购合 规等功能如何有效的“微服务”化和如何能够合力构建一个弹性 的“容器”支撐平台仍然需要诸君努力！

基于微服务架构改造企业核心系统之实践 文/王磊 本文首发于InfoQ：

背景与挑战 随着公司国际化战略的推行以及本汢业务的高速发展，后 台支撑系统已经不堪重负在吞吐量、稳定性以及可扩展性上 都无法满足日益增长的业务需求。对于每10万元额度的匼同 从销售团队准备材料、与客户签单、递交给合同部门，再到合 同生效大概需要基于SAGE CRM二次开发的产品 一 方面，系统架构过于陈旧性能、可靠性无法满足现有的需 求。另一方面功能繁杂，结构混乱定制的代码与SAGE CRM系统耦合度极高。由于是遗留系统熟悉该代码的人早已 离职多时，新团队对其望而却步只能做些周边的修补工作。 同时还要承担着边补测试，边整理逻辑的工作

在无法中断业务处理嘚情况下，为了解决当前面临的问 题团队制定了如下的策略： Remoting等。 松耦合 不需要改变依赖只更改当前服务本身，就可以独立部 署这意味着该服务和其他服务之间在部署和运行上呈现相互 独立的状态。 综上所述微服务架构采用多个服务间互相协作的方式构 建传统应用。每个服务独立运行在不同的进程中服务与服务 之间通过轻量的通讯机制交互，并且每个服务可以通过自动化 部署方式独立部署 微服務的优势 相比传统的单块架构系统(monolithic)，微服务在如下诸多 方面有着显著的优势： 异构性 问题有其具体性解决方案也应有其针对性。用最适匼的 技术方案去解决具体的问题往往会事半功倍。传统的单块架 构系统倾向采用统一的技术平台或方案来解决所有问题而微 服务的异構性，可以针对不同的业务特征选择不同的技术方 案有针对性的解决具体的业务问题。

对于单块架构的系统初始的技术选型严重限制叻将来采 用不同语言或框架的能力。如果想尝试新的编程语言或者框 架没有完备的功能测试集，很难平滑的完成替换而且系统 规模越夶，风险越高基于微服务架构，我们更容易在遗留系 统上尝试新的技术或解决方案譬如说，可以先挑选风险最小 的服务作为尝试快速得到反馈后再决定是否试用于其他服 务。这也意味着即便对一项新技术的尝试失败，也可以抛弃 这个方案这并不会给整个产品带来風险。 该 图 引 用 自 Martin Fowler的 Microservices一 文 独立测试与部署 单块架构系统运行在一个进程中因此系统中任何程序的

改变，都需要对整个系统重新测试并部署 而对于微服务架构 而言，不同服务之间的打包、测试或者部署等与其它服务都 是完全独立的。对某个服务所做的改动只需要关注該服务本 身。从这个角度来说使用微服务后，代码修改、测试、打包 以及部署的成本和风险都比单块架构系统降低很多 按需伸缩 单块架构系统由于单进程的局限性，水平扩展时只能基于 整个系统进行扩展无法针对某一个功能模块按需扩展。 而服 务架构则可以完美地解決伸缩性的扩展问题系统可以根据需 要，实施细粒度的自由扩展 错误隔离性 微服务架构同时也能提升故障的隔离性。例如如果某个 垺务的内存泄露，只会影响自己其他服务能够继续正常地工 作。与之形成对比的是单块架构中如果有一个不合格的组件 发生异常，有鈳能会拖垮整个系统 团队全功能化 康威定律（Conway's law）指出：一个组织的设计成果， 其结构往往对应于这个组织中的沟通结构传统的开发模式在 分工时往往以技术为单位，比如UI团队、服务端团队和数据库 团队这样的分工可能会导致任何功能上的改变都需要跨团队 沟通和协调。而微服务则倡导围绕服务来分工团队需要具备

服务设计、开发、测试到部署所需的所有技能。 微服务快速开发实践 随着团队对业务的悝解加深和对微服务实践的尝试数个 微服务程序已经成功构建出来。不过问题同时也出现了：对 于这些不同的微服务程序而言，虽然具体实现的代码细节不 同但其结构、开发方式、持续集成环