2017-04 ThoughtWorks洞见 - 微服务文集

2020-03-23 250浏览

1.
2.
3.微服务文集 ThoughtWorks洞见
4.目录 [介绍篇] 微服务概述我向HRMM介绍Microservices 技术雷达之微服务架构给CxO的微服务指南 [进一步解读] 微服务和演进式架构微服务即演进式架构你以为是微服务或Docker？其实是组织架构！ [实践篇] 基于微服务架构，改造企业核心系统之实践微服务——大企业是如何在实践微服务中成长的微服务的团队应对之道服务拆分和架构演进
5.
6.[介绍篇]
7.微服务概述文/姚琪琳 “微服务”这个术语在过去几年如雨后春笋般涌现，它是一种构建可独立部署服务套件的软件设计方式。虽然这样的架构风格没有明确的定义，但它们在组织方式、业务能力、自动化部署、智能化终端以及对语言与数据的去中心化等方面具备共同的特征。以下内容摘自Martin Fowler的网站。
8.“微服务”，又一个出现在拥挤的软件架构街道的新名词。虽然我们的第一反应是不屑一顾，但它的确是一个出镜率越来越高的软件设计风格。在过去的几年中，我们已经看到很多的项目使用了微服务，目前来看效果不错，我们很多同事已经将它作为构建企业应用的默认方式。但很遗憾，并没有很多资料解释微服务是什么以及如何实现微服务。简而言之，微服务是一种将单个应用以许多微小服务所组成的服务套件的形式来构建软件的方法，每个微服务拥有自己的轻量级数据处理模块以及通信机制（通常是HTTP API的形式）。微服务围绕业务能力和各自独立的自动化部署机制构建而来。由于微服务需要极少的集中管理，因此各个服务可以使用不同的编程语言以及存储技术。为了解释微服务的设计风格，我们先来把它和单块架构风格做一个比较。单块架构的应用只有一个单元。企业应用常常包含三个主要部分：客户端用户界面（包括运行在用户计算机浏览器中的HTML页面和JavaScript）、数据库（包括保存在常见关系型数据库中的各种表）和服务器端应用程序。服务器端应用程序处理HTTP请求，执行业务逻辑，在数据库中检索和更新数据并选择和渲染HTML视图发送到浏览器。此服务器端应用程序是一个完整的、单一的逻辑可执行单元。任何对系统的更改都需要构建和部署完整的服务器端应用程序的新版本。这样的单块服务器是构建系统最自然的方式。所有处理请求的业务逻辑都在同一个进程中，它允许你使用编程语言的特
9.性来将整个应用划分为类、函数及命名空间。利用某些方法，你可以在笔记本电脑中运行和测试应用程序，并使用部署流水线确保新的更改通过了测试，并部署到了生产环境中。最后你可以通过增加运行实例并进行负载均衡，对应用进行横向扩展。单块应用是可行的，但越来越多的人在使用的过程中受挫，尤其是随着越来越多的应用被部署到云中。整个系统的更新周期是被绑在一起的——对应用的一小部分进行了更改，就需要整个系统重新构建和部署。随着时间的推移它往往很难保持一个良好的模块化结构，继而难以保证新的更改只影响其所在的模块。需要对应用进行扩展时，只能将整个应用一起进行扩展，而不是扩展应用中的某个部分，这也消耗了更多的资源。
10.这些挫折导致了微服务的架构方式：以服务套件的形式构建软件。微服务是独立部署和可扩展的，每个服务都有明确的模块边界，甚至允许不同的服务使用不同的编程语言，它们甚至可以由不同的团队管理。我们不认为微服务架构是什么创新，它的历史可以追溯到 Unix年代的设计思想。但还没有足够多的人考虑过采用微服务架构，如果他们使用微服务，很多软件开发过程会变得更好。了解更多信息：詹姆斯和马丁的文章接着罗列了九个微服务的特点来定义什么是微服务架构，并探讨了其与面向服务的架构（SOA）的关系，最后论述了这种风格是否是企业软件的未来。请到这里继续阅读：
11.http://martinfowler.com/articles/microservices.html。 James Lewis是ThoughtWorks资深咨询师，也是技术顾问委员会的成员。James的兴趣点在于整合企业级系统时采用小型的相互协作的服务构建应用。他已经成功地构建了许多采用微服务的系统，并且在最近的几年里一直是社区的活跃分子。 Martin Fowler是一位作家，演讲家和大名鼎鼎的软件开发者。如何组件化软件系统的问题一直困扰着他，一些模棱两可的答案并没有让他满意。他希望微服务不要辜负倡导者们所提出的承诺。
12.我向HRMM介绍Microservices 文/刘夏一天我司招才猫姐(HR大人)对我说，“你给我解释一下 Microservicess是什么吧？”故成此文。一切都是从一个创业公司开始的。第一章：从集中到分权最近的创业潮非常火爆，我禁不住诱惑也掺和进去创建了一家公司。为了实现我的伟大抱负，我取“千秋万代，一统江湖”之意，给公司定下了一个非常响亮的名字——一统。故事虽说叫做一统，但凡事都要从头开始，公司成立之初有五个成员：罗密欧、朱丽叶、维克多、布拉伯还有老大——我。我们五个人都是工程师出身，自身具备非常优秀的学习能力，各个都是从业务到代码的好手，五个人一起做策划、搞市场、写程序、做运维、面对客户；可谓你中有我，我中有你，努力拼搏，好不热闹。为了吉利，我们找了一个车库作为机房和资料室，上至合同，下至代码，全都放在里面。这就是一统最初的样子。
13.虽然创业艰难，大部分公司都在前两年倒下了，但是我大一统不但没有倒掉，还意外地实现了增长：客户量从当初的一家猛增到一百家。这样一来，即使我们的团队再出色也应付不了这么多的客户。挣钱还是要命呢？命得要，钱也得挣！怎么办呢？招人吧！我们绞尽脑汁搜罗（挖角）市场上的人才，组成了巨型一统团队。我们认为团队中的所有成员都应该跟初创时期的五个人一样，能攻能守，内外兼修，但是……我们发现这是不可能的，有些人擅长写代码而非面对客户，有些人善于做市场但是不喜欢做财务。后来出现了更加让人挠头的事情，有一个财务流程，问了五六个人竟然没有一个人能够完整地串起来。于是，我一个一个地问，
14.最后才把整个流程从这些碎片知识里面串联起来。这种团队的服务质量可想而知，不久就接到了数十件客户投诉。竞争对手趁机抢占市场，一个欣欣向荣的公司瞬间就摇摇欲坠了。为了留住客户，我们必须在扩张的同时保证服务质量。我发现目前最重要的问题就是职责不清晰，大家不知道自己应该干什么、也不清楚该怎么干，于是我抽调了各个业务部分的精干力量，总结流程，形成了客户\市场、财务\合同、技术运维、管理团队四个独立的业务部分。采取内部招聘的方式将人力分配到了这四个部门中。我期望将大家从纷繁的知识体系中解脱出来，每个人不需要了解那么多的知识，集中力量关注自己的问题以提升效率和服务质量。
15.在此次结构调整之后，大家的工作效率明显提升了。抱怨知识结构太复杂、无法短期适应工作的声音消失了。一个月之后，我们做了一个抽样调查，发现大家对自己的工作范围和内容都了如指掌。一些客户又重新和我们签订了合同。正当我沾沾自喜的时候，发生了一个重大事件。由于我们的资料室是对全公司开放的，任何成员都可以查看或修订其中的信息。客户及市场部的一个员工平时非常好学，对财务方面的知识掌握的非常系统。有一天，公司急需草拟一份财务清单，但是这个任务非常耗时，财务部门的同事当时正在进行月末审核，无暇抽身。这位热心的同学就凭借自己出色的能力从资料室取来相应的材料完成了清单。三天后，财务部的罗密欧准备细化这个清单。但是清单的内容让他着实吃了一惊——清
16.单上的填写内容和他们部门内约定格格不入。罗密欧只得自己重新完成了清单。一来一去让他的工作耽搁了一天，罗密欧向我抱怨道。无独有偶，其他部门也发生了同样的事情。这让我意识到只是把人员的职责进行划分并不能彻底解决问题。我们不能再继续混用一个资料室了，因为这样人人都可以任意修改各种资料，安全性不好不说还会造成填写格式混乱。于是我把财务部的资料放在了另一个独立的屋子里，并给罗密欧单独配了钥匙。这样，任何想填写财务清单的人只能找财务部的人所要单据，而当单据缴回的时候也必须经过财务部的审核。鉴于财务部每个月底都会很忙，在那时我会临时抽调人手去帮忙。我希望对其他部门做相应的整改，但这种动作幅度毕竟很大，因此，一段时间内还会有多个部门共用资料室。经过一个月的努力，我们最终还是淘汰了公用资料室。为每一个部门都配备了独立资料室。虽然需要缴纳更多的房租，但是各部门再也没有犯之前的错误。
17.从故事到项目大多数项目也会像我们的创业公司一样，一开始大家一起干活，每一个人都是冲锋陷阵多面手。大家一起组成了应用程序的全部，而我们的车库就是数据库。这种组织结构代表了典型的 monolithic application。这种系统的逻辑架构是类似这样的。在项目的早期，业务简单、吞吐不大，这种结构清晰、易于理解的架构非常实用。但是随着业务的增大，混在一起的代码不易理解。而最容易想到的解决办法就进行职责的划分。一统公司一开始在维持车库结构的情况下仅仅从人员上做了拆分，这种情形在实际项目中也存在。系统进入了多个服务共享一个数据库的阶段，集成点在数据库上。
18.这种划分职责但又维持数据库集成的方式只应当作为过渡阶段存在。程序永远都是逻辑+数据，而数据的混杂谈不上职责的独立。长期维持这种数据集成的状态容易出现业务下行，数据表达不一致等问题。从逻辑+数据的整体划分边界（称为模块，或者服务）势在必行。而在边界划定之后，就需要考虑独立的服务之间如何进行协作了。第二章：协作现在我们的资料室都独立了，再也没有办法像以前一样有需要就去公共资料室里取资料了。那么我们应该如何进行协作呢？故事一个非常自然的想法是把各部门用业务流程穿起来。例如，在洽谈一个订单时，先由客户及市场部进行调查和谈判，
19.然后由技术部制定解决方案，管理部审批之后由财务合同部拟定合同，最终递交管理部签署。这种协作方式我们不妨叫他串联协作。为了将这一方案执行下去，我们对各个部门的人员进行了培训。例如，对于技术部。在洽谈一个订单时，技术部需要给出解决方案，完成之后需要将方案递交管理部审批。类似的业务有很多，每一个业务各个部门任务都不同，而下游接收的部门也不一样。但是我的同事们还是克服了困难，让它们烂熟于胸。业务变化是最平常的，一变就是一大把。现在对于洽谈订单的业务，我们需要在给出技术方案之后先让财务部进行预算审核，再将其递交给管理部。这需要重新培训三个部门的人，洗脑一样的把他们之前的流程抹掉。一个业务变化还好，但是
20.二三十个业务同时发生变化就让大家抓狂了。甚至有人说这和之前一大坨人一起做所有事情没有什么本质上的差别。看来这种业务串联的方式是行不通了。所谓我不入地狱谁入地狱，这种情况下我挺身而出，入住市场部——因为这个部门是直接为客户服务的。我对所有的流程了如指掌，当业务来的时候，由我去对业务进行协调。例如，当一个洽谈订单的业务到来时，我会先将它交给客户市场部进行谈判；结束后市场部将需求和意向书交给我，我再把需求交给技术部去制定解决方案；方案制定完毕之后技术部会把方案返回给我，我再把结果交给财务部审核……如此进行。这样，每一个部门都不需要由于业务变化重新接受培训了，也不用记住他们的下游应该是谁。大家觉得，职责明确多了，工作轻松多了。
21.这种协作方式我们不妨称之为“业务调度员”式的协作。现在我俨然成为了流程的中心，其他业务部门不需要关注业务流程的变化。这给我们增加了很多灵活性，因为我一个人的变化速度要比一群人的变化速度快得多（你是独裁者吗）。但是我的大脑总是有限的，一年之后，经历了三四轮业务变化，我已经无法准确回忆起某些业务细节。我不得不通过频繁的查询业务笔记来确定我的下一步操作；此外，不停地往各部门送信也令我不堪重负。
22.这时候，我希望其他人能够为我分担。我决定化被动为主动，不由我主动联络各个部门，而由各个部门主动接受任务。我在公司安装了一个大喇叭，话筒就在我的办公室里。当一个订单洽谈业务到来的时候我就朝着喇叭嚎：新订单来啦！客户和市场部专门关注新订单，因为按照流程，订单到来之后市场部要尽快投入谈判。于是他们会主动开始行动。当市场部工作完毕之后，他们会将谈判的结果、需求以及意向书拿到我的办公室里。我会再嚎：需求来啦。此时，技术部会从我这里拿走这些资料并开始工作。如此往复，直到项目完成。这种协作方式令我不必再操心信息在各部门之间的流转。各部门知道他们应该何时介入，我只需要对着大喇叭喊，自然会有相关的部门将活干完。这样，我作为业务的中转中心，工
23.作量不会随着业务的增长显著的增大（只要喊话就行了，至多就是增加喊话种类），而各部门也不用关心自己的下游到底是谁，只需要关心我喊的话就行了。这种协作方式不妨称之为“公司广播”。看起来这是一种非常方便的形式。但是这真的就又快又省吗？有一天，来了一个新的订单。在我接到意向书和需求之后，我照例喊话：需求来啦！接着，我就出去吃饭了（真是资本家啊你）。等我回到了办公室，发现文档已经被拿走了，而结果还没有送过来。时间一天一天过去了，我手头的新订单越积越多，需求文档和意向书源源不断的送过来。到了第三天我实在是受不了了，想去查找文档的去向和任务的完成状况。这时候我才发现我根本无从下手，因为我不知道文档是谁拿走的，于是我便一个部门一个部门地去询问。可是由于业务的发展，现在我们已经有20多个部门了，这种非常规的询问不仅让我跑断了腿，而且为了查证，需要翻阅各部门成吨的业务日志，各部门的部长对此也颇有微辞。我终于意识到——这种协作方式在令结构松散灵活的同时也增加了监管的难度。必须采取额外的投入来弥补这一短板。于是，专门监视各部门动向的“纪检委”：监管部出现了。一开始，我只是想确认一下各部门运作是否正常，有没有由于天灾人祸而出现团灭的现象。出于不对各部门添加新的压力的愿望，监管部会定期去各部门走一圈看看是否都在好好干活（真是讨人嫌的部门啊），就像这样。
24.但是随着业务的发展，我希望得到各个部门更加详尽的信息，例如，各部门是否积压了大量任务并需要帮助，在处理过程中是否由于流程不合理而无法继续下去等等。需要收集的数据已经远远超过了监管部跑腿的速度。怎么办呢？如果我手头没有什么钱，我可能会降低监管部工作的周期，例如之前是半天一次，现在改成两天一次。但是我是土豪，于是我制定了监管汇报单，强制各部门在状况出现问题的时候主动向监管部汇报，就像这样。
25.从故事到项目我们真正开始考虑服务之间如何进行协作了。和一统公司的做法一样，最容易想到的就是业务串联。业务首先由第一个服务处理，之后再由第一个服务调用第二个服务继续处理，直至业务全部处理完毕。于是我们就得到了这样的系统架构：
26.正如故事中说的一样，这种业务的串联难以应对业务流发生的变化。同时，由于服务之间互相直接耦合，集成点多，难以做到独立进行部署。“业务调度员”的方式是一种很好的改进。如果你还记得那位勤劳的调度员（我），那么你就一定认识Composer这个特殊的服务：我们使用它进行业务流的分发与控制。这样，服务仅仅和Composer进行对接，不需要考虑业务流的问题。既明确了职责又可以进行独立部署。以下就是这种协作方式的架构：
27.而最复杂的“公司广播”则是变直接调用为事件触发。使用“事件”隔离了各自的模型。系统结构更加松散灵活。
28.隔离和协作的矛盾从踌躇满志的开始创业到现在，我感慨于业务的扩大和公司规模的发展，也有一些会议例如 PCon希望我们能够去介绍结构划分和协作模式。但是每当我在工作之余静静思考，却感到一些厌倦。我们的协作方式真的好吗？随着职责的划分，我们越来越专业化，互不影响的工作方式极大地提高了我们的效率，良好的隔离让我们的失误不至于扩散并能够横向扩展；而监控系统也告诉我们一切尽在掌握。但是隔离同时也是壁垒。为了协作，我们在这些壁垒上开了些小孔，为了严格控制进出，我们制定了越来越多的规条，例如，信件应该怎么写，单据应该怎么填。回头看去，成百上千的规约连我也不能尽数，当公司需要做出变化的时候，如果变化仅仅发生在各个部门内部，这种结构的优势无可置疑。但是如果涉及到部门之间的协作，甚至部门之间的拆分合并，就会变得异常艰难。由于部门和规约的耦合是存在于脑内的，并不显露在外，修改已经存在的规约和部门结构往往不现实，只能花更多的钱去组建新的部门，逐步介入公司业务后淘汰旧有的部门。而这种周期动辄是以月计算的。有的时候，可能宁可去接受新的方式从头开始，卖掉旧的公司，创建新的公司，然后继续轮回。隔离既创造了灵活的单点变化也造就了整体的僵化。细小的部门划分不能解决这个问题，因为部门越多，规约越多，实
29.施成本越高（在例子中我们并没有考虑资料室的房租，监控的支出，但是现实中这往往是一个决定性因素）。单个部门结构的简化造就了整体的复杂。因此，分部门就一定好吗？业务调度员就没有公司广播好吗？答案应该来源于你的现实，而不是理论。如果让我重来一次，我可能会慢一点，再慢一点。未来无法预计，针对当下的痛点做出反应可能不是最优的，但是却是一个容易理解的思路。实际项目中也是一样。就像武侠小说中的一样，威力越大的招数使用限制也就越多。一方面，系统结构越来松散越灵活，变化变得容易；另一方面，系统越来越复杂，维护越来越困难。当维护困难到一定程度不得不将其提上议事日程的时候, 专事监督与维护的工作就出现了，这种维护不同以往。维护者既要有维护知识又必须了解这个复杂系统的运作方式。别忘了，虚拟化、云、Devops,除了概念上的光鲜还复杂又花钱啊！慢慢进化，慎重的考虑并决定是否选用Microservices，然后做好维护吧。第三章：Microservices 在前面的内容中，哪种方式可以称为Microservices架构呢？故事里面公司组织结构演化分成了几个部分，并不是每一个阶段代表的结构都可以称之为Microservices：
30.第一个阶段是多个部门共用一个资料室，这种情况往往无法摆脱数据库集成的事实（有些项目使用Schema对访问进行隔离，不在此列），不能称为Microservices；第二个阶段是各个部门有自己的资料室，这是一个非常重要的改变，直到此时，各个部门才实现了完全的隔离，但是还不足以称为Microservices；第三个阶段分三类：首先是串联协作。在这种方式下，一个部门的变化往往会影响其他部门，因为每一个部门都需要知道业务的上游和下游，因此有比较紧密的耦合关系，无法独立变化。因此不足以称为Microservices；其次是业务调度员方式，此时部门自身的变化不会扩散到其他部门，因此是可以独立决定和操作，只要部门足够小，这种结构可以称之为 Microservices了；第三是公司广播。这种方式下的部门耦合更加松散，可以独立进行变化，在部门足够小的前提下可以称之为Microservices。我们的初衷是什么呢？构造一个系统能横向扩展以满足业务伸缩性，提供灵活变化的能力，又希望变化的影响不要扩散。因此，如果一个架构可以称之为Microservices架构，那么意味着： • 每一个 Service 可以进行独立部署； • 每一个 Service 都足够小，完成完整的定义清晰的职责；业务调度员和公司广播两个例子的组织结构都可以成为 Microservices架构。但是他们之间并没有绝对的优劣之分。选
31.用哪一种应当取决于实际要求。写在最后 Microservices不是一门科学，而仅仅是实践。就像是面向对象编程一样。最终应当是需求、是人来决定架构而非架构决定需求。Microservices是为Business Capability而建，是根据实际（或者痛点）做出的抉择。他解决了一些问题，但是并不能肯定这就是今后软件的发展方向。硬件的革新——不论是近期的电池技术发展，还是近乎黑科技的量子态传输、量子计算都有可能影响甚至颠覆今天形成的软件开发体系。就像是当年大家为了追求极致的执行效率试图将代码塞进64K的代码段一样，我们今天奉为经典的东西未来可能只是茶余饭后的谈资。我们能做的只有保持开放的心态，坚持辩证的观点，坚持从实际出发，寻找出最合适的解决方案。这也就是我们不称自己为码农的理由之一吧。
32.技术雷达之微服务架构文/王健最近几年，微服务架构异军突起，与容器技术相辅相成，成为架构设计领域热议的话题。而《技术雷达》作为 ThoughtWorks出品的一份关于技术趋势的报告，在技术社区也一直有着非常好的口碑。本篇文章就试图通过结合技术雷达与微服务架构，从往期技术雷达中微服务架构的演变来审视一下这个新兴架构的发展过程。相信大家了解或者听说微服务架构也都是近两年的事情，从Google Trends的搜索数据统计上看，微服务架构确实是从 2014年逐渐兴起、到目前才呈现出一个爆发的趋势。但在技术雷达中，2012年3月份这一期就已经包含了微服务架构相关的内容，当时它还处在评估（Assess）阶段，这就说明技术雷达早在2012年初的时候就已经成功捕获到“微服务架构”这个新的技术架构。
33.微服务 2012年第一次出现在技术雷达上到底什么才是微服务架构，在Martin Fowler的那篇著名的描述微服务架构的文章中第一次定义了“微服务架构”并阐述了其九大特性。而我一开始接触微服务架构的时候也觉得这好像不是一个新的概念，很早之前就有RPC和SOA这种面向服务的分布式架构，现在又冒出一个新的微服务架构，他们到底有什么区别？看到了Martin Fowler的定义后，才慢慢清楚他们的区别，在Martin Fowler的定义中有几个关键字可以让我们甄别一个分布式架构是传统的面向服务架构还是新的微服务架构：每个服务是不是跑在独立的进程中？是不是采用轻量级的通讯机制？是不是可以做到独立的部署？
34.微服务架构的定义时间来到了2012年的10月份，在这期的技术雷达中，微服务架构已经从评估（Assess）阶段被移到实验（Trial）阶段。什么叫实验阶段？我们ThoughtWorks内部有一个解释，就是这项技术已经可以运用在实际项目中，但你仍要控制风险，也就是说此项技术已经可以在风险比较低的项目中使用了。一个项目要能被移到试验的阶段，还有一个必须要满足的条件，就是必须在ThoughtWorks自己的项目中已经开始实际使用。幸运的是，我当时所在的项目就是从2012年10月份左右开始采用微服务架构的，结果非常好。我们在3个月完成一个新的应用并成功上线，当时客户评价很高。实际体验下来，微服务架构对我们来讲究竟有哪些好处？这几点是我体会到的：首先是组件化，作为一个软件开发人员，其实我们一直都
35.有一个梦想，就是希望有朝一日可以把一堆的组件像乐高一样通过直接拼装的方式快速构建我们的应用。无论是最早基于拖拽的方式构建应用，还是利用现在大热的前端组件化，我们一直都在试图寻找一种更好的组件化方式，微服务架构也是其中之一。但构建软件本身还仍是一个非常复杂的过程，微服务架构为我们提供了一种组件化的可能，但直到现在还不好说它能不能达到我们作为整体组件化的目标，但是至少从我们的实际体验来看，它确实能给我们带来组件化的很多好处。然后是弹性架构，上几期技术雷达推荐了亚马逊的弹性计算平台，如果我们的系统是由按业务划分的服务构成，结合容器技术和云平台我们就可以构建一个极具弹性的架构。通过云平台进行实时的监控，一旦发现资源紧张，立刻就可以通过云平台和容器技术自动在瞬间扩展出成百上千的服务资源，在高峰过去之后又可以立即把所有的服务注销掉，释放资源，整个过程完全是自动化的。
36.微服务架构的好处去中心化和快速响应也是微服务架构给我们带来的好处。在单体架构下，会非常依赖于项目一开始对技术的选择，一旦选择了一个技术栈，之后几年都会被绑定在这样一个技术栈下，很难应对变化。微服务架构则给我们提供了一个更细粒度使用技术的可能，在不同的服务里可以使用完全不同的技术栈、不同的语言、框架甚至数据库，真正做到用最适合的技术解决最适合的问题，从而让我们可以更加敏捷地响应需求和市场的变化，提高了竞争力。从2012年10月份一直到2014年的7月份，这段时间里有大量与微服务架构相关的工具、技术和框架出现在技术雷达上。包含了很多领域：语言、测试、框架、CI、CD、持续交付、安全等等。从2012年的3月份微服务架构第一次出现在技术雷达上一
37.直到2014年7月份，虽然微服务架构已经有比较大的发展，技术雷达也推荐了大量相关的内容，但在当时社区中谈论微服务架构的声音并不多，这也体现出了技术雷达的前瞻性。技术雷达上微服务架构相关项目从2014年7月份开始，微服务在社区就开始呈现出一种爆发的趋势，但在紧接着的2015年1月刊的技术雷达中却出现一个非常有意思的项目：Microservice Envy。通俗点儿讲就是“微服务红眼病”，或者说是“微服务你有我也要”。这意味着在社区刚刚爆发，对于微服务架构踩下油门的时候，我们又踩下了一脚刹车。但这并不是代表我们不看好微服务架构，而是认为需要认真思考我们是否真正需要以及何时以何种方式使用微服务架构，不能看别的人都在使用也盲目切换到微服务架构下。
38.这是因为微服务架构并不是免费的午餐，使用微服务架构是需要门槛和成本的。我们需要问自己：用微服务我们够“个”吗？或是说用微服务我们够“”格”么？我们是否有这个能力和足够的资源驾驭这个新的架构？ Martin Fowler在他的《企业应用架构模式》中，就提到了分布式对象设计的第一原则：“设计分布式对象的第一个原则就是不要使用分布式对象”。因为分布式系统会给我们带来很大的挑战，让系统复杂度大幅增加的同时，我们还需要面对开发环境、测试、部署、运维、监控、一致性和事务等一系列的问题。 Microservice Envy 所以说，微服务架构虽然看起来非常美好，但是也有很大的附加成本。通过下面这张图可以看到，横轴是时间轴，纵轴
39.是生产力。当软件的复杂度很低的时候，单体架构下的生产力是要高于微服务架构的，但随着复杂度的不断增加，无论是单体应用还是微服务应用的生产力都会下降，只是微服务架构的下降会相对缓慢一些。这也容易理解，因为微服务架构中我们的系统是由很多的小的服务组成，每一个服务都很小，相对简单，技术栈也很独立。这样做局部的变更也会更加容易，随着系统复杂度的不断增加，微服务的优势也就慢慢地体现出来了。那要如何应对呢？为了追求生产力的最大化，一开始我们
40.可以选择从一个单体架构开始，然后争取在微服务架构生产力超越单体架构的那个复杂度点时切换到微服务架构上来，这样才能实现生产力的最大化。这就是Martin Fowler提出的单体应用优先原则（MonolithFirst），以单体架构开始，通过演进式设计逐渐重构到微服务架构。 MonolithFirst 为了保证从单体架构演进到微服务架构的重构过程安全可控，还需要有一套良好的质量守护机制。下图描述的就是 Martin Fowler提出的微服务架构下的测试策略，我所在项目就是按照这种方式来划分和设计我们的各种不同类型的测试，帮助我们在对于服务的抽取合并分离的重构过程中做到安全可控。
41.Testing Strategies in a Microservice Architecture 我们刚才提到了康威定律，康威定律说的是设计系统的组织产生的设计和架构等价于组织间的沟通结构。而康威定律还有一个逆定律：如果想改变一个设计架构方式，首先要改变组织结构。我们经常发现推动技术架构的转型和演进很难，因为我们在调整技术架构的同时却忽略了组织结构也要对应做相应的调整以匹配技术架构的变化，当组织结构与技术架构不匹配的时候，就会相互拉扯，这些都是在当时的技术雷达中不断着重强调的。
42.这篇文章所谈论的都还是2015年以前各期技术雷达里的内容。在这之后直到现在，技术雷达也还在持续地推荐微服务架构相关的内容。所以说踩下刹车并不是因为我们走错了路，只是走的太快了，需要时刻提醒自己不要盲目，要清楚微服务给我们带来了什么机遇和挑战，最终解决我们的问题。及至最新的几期技术雷达，微服务架构还在不断的演进，而且慢慢的与其他新兴技术融合形成了一整套不同以往的软件构建解决方案。例如无服务器架构、Docker、PaaS等技术的发展，会不会为微服务架构的演进提供更多可能？是否可以为微服务架构早一天落地、改变我们的开发方式提供可能？让我们大家一起拭目以待。
43.给CxO的微服务指南文/Jim Highsmith & Neal Ford 译者/禚娴静这是技术雷达系列文章的第四篇。在这一系列的文章中，技术雷达的作者们向企业领导者分享了他们对于那些推动业务差异化的技术问题和解决方案的洞见和经验。ThoughtWorks技术雷达由ThoughtWorks全球技术专家咨询委员会创建，它包含了对软件开发和业务战略有显著影响的技术趋势组合，2016年是技术雷达发布的第七年。未来已经在这里，它只是分布不均。 ——威廉·吉布森数字时代就在我们身边。将软件开发视为高成本开销而不是竞争力的企业将会举步维艰。为了参与并在这个数字世界中繁荣兴旺，企业必须学会适应我们这个时代的不确定性—更快地将新产品推向市场，快速而有效地改进当前的产品，并为客户提供有意义的数字体验。为了实现这些目标，企业需要将敏捷性/适应性集成到三个领域：人、流程和技术。人们需要适应试验和改变。以“迭代”的形式推进这一过程，并加强学习。技术，包括技术架构，需要支持快速地交付产品与服务。
44.技术的敏捷性不能被忽视——敏捷的团队和流程并不能弥补笨重的技术所带来的缺陷。但作为一个高级管理人员，在这样一个充满了新技术的世界，你应该将注意力投注在哪里呢？？这个问题的答案被那些不停地讨论着看似神秘话题的技术人员们所掩盖。哪些神秘的话题需要得到管理层的注意呢？其中最重要的话题之一是微服务。原因如下所述：微服务影响人、流程和技术：包括团队组织结构，流程和实践（如DevOps），以及重新调整架构以适应我们要解决的问题，而并非纯技术层面。微服务促进了每个领域的适应性。它值得管理层花时间去了解其潜在的贡献。技术敏捷度微服务架构风格的特性是由一组极小的服务组成，它们彼此独立且单独部署。微服务由Netflix这样的公司推广开来。每个服务包含一个离散的业务功能，它在技术上与其他服务相隔离，产生了类似乐高积木的效果：开发人员可以将服务切换为一个新的服务，而无需破坏其他服务。就像巨型的乐高模型可以由75,000块乐高组成，大型的数字应用程序也可以由这些受乐高思想启发的服务所构建。这种架构有一些明显的好处。首先，每个服务与其他服务高度解耦，这意味着它们是自包含的。因此，一个服务中的技
45.术更改（例如数据结构更改）不会影响另一个服务。服务仍然可以通过消息传递进行通信，但是任何一个服务都不允许修改另一个服务的实现细节。第二，因为开发人员不需要共享基础设施，他们可以选用适合于该问题复杂度的技术栈来实现每一个服务。考虑到当今技术栈的复杂性，在同一应用程序中，使用简单工具处理简单问题和使用复杂工具处理复杂问题的能力使开发团队在增加了灵活性的同时也降低了成本。领导者重视能将复杂问题简化的技术专家。第三，每个服务封装了业务功能，它更容易促成围绕特定问题域的团队，而不是通过作业功能分割的团队。例如，服务团队通常包括开发人员、业务分析师、DBA、运维人员和QA— 即构建和部署服务所需的一切角色。这样一来便降低了协调成本。 “从功能性组织结构向产品或服务结构转变”是敏捷企业转型的一个日益增长的趋势。而微服务架构支持了这种趋势的变化。最后，因为每个服务是相互隔离的，所以以服务组成的架构既快速又灵活。同时因为服务的业务范围很小，对服务的更改可以快速地发生，这为开发人员提供了新的高级功能。一旦架构师设计了一个小型独立服务的系统，其中应用程序由部署的多个服务之间的消息传递组成，多变量测试等操作就变得容易了。
46.例如，企业可能对他们网站的未来发展方向并不确定。因此他们设计了具有相似性但功能不同的两种服务，并向不同的用户组部署不同的版本，以获取结果从而推动未来的发展。像 Facebook这样的公司也是通过使用这种类型的A / B测试进行试验来分析他们的用户。标准化一直是IT组织降低成本的方式之一。不幸的是，它也降低了灵活性—标准化越多，灵活性越少。通过采纳微服务架构，架构师和开发人员可以使用更加多样化且能够紧密反映问题复杂度的技术栈来设计应用程序。微服务架构风格与许多企业部署软件和分配IT资源的方式相反。许多架构风格的主要目标之一是有效地利用共享资源（操作系统、数据库服务器、应用程序服务器等）。由于资源的成本影响了底线，因此这些公司建立了软件架构以最大化共享资源。然而，共享资源有一个缺点。无论开发人员如何有效地构建与这些服务器的隔离，都会出现对这些资源的竞争。有时组件由于依赖管理而互相干扰，有时由于两个组件争用某些资源（例如CPU）而产生问题。这就不可避免地会导致共享组件以并不期望的方式进行交互。容器和解耦在软件交付中，有两个关键的技术“环境”：开发人员工作
47.的开发环境，以及IT运维人员管辖范围的部署环境。传统情况下，在这两个环境之间移动代码充满了技术错误，冗长的时间延迟以及组织层面的沟通不畅。几年前，一些有趣的事情发生了：Linux对于大多数企业足够友好，Linux的变体在商业上免费—但是这不足以影响技术架构。接下来，开源的创新与敏捷开发技术的结合鼓励了开发人员创建各种工具，将许多繁琐的运维手工操作自动化。这被许多人称为DevOps革命。这场革命使得开发团队和IT运维人员通过使用Puppet、Chef 和Docker等高级工具更加紧密地联系在一起。意外地，Linux的变体允许免费操作，开发人员可以在不受干扰的情况下将其组件部署到一个原始的操作系统。一整个可能的错误类别就突然消失了，因为组件之间能够相互解耦。如果开发人员可以构建他们自己的现实环境，他们必须减少与运维部门的协调，也就减少了组织间的摩擦。用程序启动类生产环境的能力消除了测试、集成、共享环境下的资源竞争、以及一系列其他问题。 21世纪的架构敏捷度在治理方面，微服务架构风格有其他的好处。传统的做法是，企业架构师定义了组织的共享技术栈，以最大化项目间的
48.资源使用，同时最大程度地减少支撑成本。例如，一个大型企业可能将Java和Oracle标准化以作为其主要开发平台。如果每个人都使用Oracle，那么该企业的一切都可以存储在一个工业强度的数据库中。规范化治理有一个缺点—通常，为了标准化的某一目的，团队必须使用并不太理想的工具。与此同时，还有一个潜在的更微妙的缺点。例如，考虑一个已经选择在特定消息队列上标准化的大型企业。在评估需要此共享基础设施的所有项目时，企业架构师会找出最复杂的场景，并选择一个适合这种复杂度的工具来处理它们。然而，许多项目并不具备这个最复杂的场景。但因为每个项目必须共享相同的基础设施，所以每个团队都得承担其他团队的最大复杂度。这种情况也发生在数据库层。许多项目只需要几个记录的简单数据存储，并不需要复杂的查询功能，但最终都使用了具有工业强度的数据库服务器，只因为这个企业的标准如此。容器化技术解决了这个问题，因为它远离了共享基础设施 —每个项目都部署在自己原始的、容器化的环境中。因为不存在共享的动力去选择工具，所以每个项目刻意选择更适合自己的工具。当然，如果企业架构师允许每个项目选择自己的技术栈，那么会存在一些严重的缺点。我们经常看到一个称之为““Goldilocks治理”（企业架构师选择几个技术栈—简单、中
49.等和复杂，并根据规模分配新项目）的实践，它适用于高度解耦的环境。这些知识是可迁移的，该公司仍然可以从中受益，但是却可以远离那些由于疏忽大意而将问题过于复杂化的行为。为什么我们会谈到这儿？ Eric Evans的《领域驱动设计》一书对微服务架构发展产生了巨大的影响。它介绍了一种将大问题空间分解为领域或重要实体（如客户和订单）及其关系（客户下订单）和行为的技术。领域定义的一部分是有关边界上下文的概念：每个领域形成一个围绕实现细节的封装层。例如，如果分析人员识别了一个Customer领域，那么它存在于自己的边界上下文中。在Customer的上下文中，开发人员知道所有的实现细节：类结构，数据库模式等。但是，其他边界上下文（如Orders）不能看到这些实现细节。虽然领域可以为了协调的目的互相发送消息，但是任何一个领域都不能穿透另一个领域的边界上下文。因此，在一个边界上下文中的开发人员可以自由地更改实现，而不必担心破坏其他领域。微服务中的容器是领域驱动设计（DDD）中边界上下文的物理表现：每个容器代表了一层封装，以防止实现细节干扰系统的其他部分。边界上下文提供的隔离展示了结构化软件架构
50.的不同方式。在过去，设计架构主要围绕技术架构：架构模式、库、框架等。例如，分层架构在许多组织中是很常见的：图 1：传统的分层架构在图1中，架构师沿技术层进行分离，使之在需要时可以很容易地替换一整层的内容。例如，如果开发人员需要更改持久机制，所有相关代码都会出现在持久层中。那么开发人员多久更换一次整个持久层呢？几乎从不。但你的团队多长时间基于像Customer这样的概念工作呢？每天！在图1分层架构中，Customer处于哪一层呢？其中部分在表示层、业务层、持久层等等。因此，项目架构上通用单元的变化在分层架构中并没有得到很好的支持，原因是通用的变更影响到了每一层。如果不同层代表了开发团队的不同部分，其影响会更严重。例如，对Customer的更改可能涉及到用户界面、业务逻
51.辑、持久层和其他特性。如果你的组织由开发人员、DBA、用户界面设计师和运维人员组成，而他们在相互隔离的HR部门下，那么进行常见更改的协调成本是巨大的。微服务强调解耦和容器化，翻转了图1中的传统做法，使领域成为架构的主要元素，如图2所示。图 2：以领域为中心的架构在图2中，分层结构仍然存在，但是其耦合边界是领域的边界，它将技术架构归入实现细节，并用领域对其进行封装。以技术为中心的组织单元中，员工与员工彼此隔离，要想在这样的组织中构建以领域为中心的架构是很难的。许多技术人员在构建数字化企业中会遇到这样的问题：想要支持如移动应用等新举措，却被那些需要拆分的遗留系统所拖累。如今，这些企业越来越多地引入微服务作为这种拆分过程的关键战略。 Greenfield项目得益于DDD实践。通过DDD理解了他们的问
52.题领域以及重要组件之间的接口所在。对于现有项目，更加模块化的系统会促使开发者解开事务性的泥球，并且可以在那些属于一起的组件和偶然耦合的组件之间做更清楚地区分。团队你还将遇到微服务对团队影响：一个架构风格是如何推动开发团队重组的。 1968年，梅尔文·康威对软件开发做了一个很有预见性的观察，被称为康威定律：设计系统的组织，其产生的设计等价于这些组织间的沟通结构。康威定律对软件开发的意义是什么呢？你的设计反映了你的团队结构。企业常见的团队结构是由人力资源部门推动的，他们将职能类似的技术专家组织在一起。虽然这是一种符合逻辑的排序算法，但这种结构在设计自包含服务时效果不佳。如我们认为的康威逆定律，现在许多公司在围绕业务领域组织跨职能团队，而不是围绕技术分层构建。例如，一个 Customer服务可能包括一个业务分析师、开发人员、QA、 UX、DBA和运维人员。团队会在准备好之后再部署服务，而不是先构建一些东西传递到运维人员，使之包含在下一个巨大的发布中。许多选择微服务的公司使用持续部署，以尽快将变更投入生产环境中。
53.总结企业高管可能会认为微服务是最新流行词而不予考虑，但那些了解这种架构影响的人可以获得实实在在的好处。微服务可以提高交付速度，增强灵活性，并提高效率。他们将工作进行重组，并与业务问题域保持一致，而不是技术域；从一组独立，更易于开发和维护的服务中创建业务应用程序；更好地匹配技术解决方案与业务问题的复杂程度；构建可以帮助重组现有遗留系统以及创建能够快速响应不断变化的业务条件的新产品和服务的自适应架构。威廉·吉布森是正确的—许多公司已经将IT竞争力看作鲁棒性一个新的度量。对于这些企业来说，未来已经在这里了。其他还没有意识到这一点的公司可能会发现他们的未来已经受到了影响。原文链接：https://www.thoughtworks.com/cn/insights/blog/cxo-guidemicroservices
54.
55.[进一步解读]
56.微服务和演进式架构文/Rebecca Parsons 译/占红来在我们的软件开发流程中，经常会面临改动，有来自用户需求的、来自市场的，以及为了一些潜在机会而做出的改动等。当这些改动来临的时候，我们需要快速做出调整。但不幸的是，事情并不总是如我们所愿。那么我们之前是怎么做的呢？资历较老的程序员应该都还记得一种基于可重用组件的设计方法。在这种方法中，专门有一个架构团队，他们会识别出整个组织中各个部门应该怎么使用某一组件。某些时候架构团队的业绩甚至还会与其所设计的组件被使用的次数挂钩。但是不幸的是，由于架构团队和组件使用团队缺少连接，因此架构团队很难设计出一个有口皆碑、受使用者欢迎的组件。
57.还记得另外一种利用数据库做集成的架构么？是的，我们之前都是这么做的，在这种架构模式中，我们有一个巨型数据库，所有的数据都囊括在其中。这个数据库的周围，有一圈各种各样的应用，它们支配着这些数据。此外还有一种曾经颇为流行的面向服务的架构，这种架构理念声称它们可以达到我们想达到的目标。这种架构确实有其做得不错的一些地方。首先，它让组织者知道并不是所有的东西都必须是模块化的。与此同时，它也激发大家开始思考，将多种功能更好的集成到一起，而不是紧耦合到一块，比如你可以想想使用中间件、消息队列或者其他一些更松耦合的方法。 SOA（面向服务型架构）让最终一致性得到更加广泛的认
58.同。一直以来，传统的（DBA）数据库管理员这个角色起着至关重要的作用，因为最有价值的数据资源均由他们保护。在访问数据库的时候，一切都是关系型的，都是事务处理。因此每当你说我需要做持久化的时候，就会有人告诉你，放在一个关系型数据库里就好了，大家对此都达成默契了，没有任何问题。然后所有的操作都是完整的事务处理，我们可以使用关系型数据库所能提供的所有功能。以前大家都是这么干的。而 SOA的出现至少启发了大家，使之开始讨论我们是不是可以用另外的方式来取代之前的老路子，从这个方面来讲，SOA确实有其正面意义。但不幸的是，SOA也犯了一些错误。最主要的一个问题在于其庞大的服务。你看看使用SOA模型做出来的这些服务，这些海量服务作为一个全局组件，还是太大了，太难做出改动，也太难部署了。其次，SOA倾向于提供方驱动的服务。我的意思是，当你开始想我要写一个用户服务，我要给用户提供这些信息，因为我是这些信息的提供方。假设我知道用户将会如何使用这些信息。这其实和设计可重用组件的架构师差不多，我们统称为信息提供方驱动。一般而言是由组织中的IT部门做完之后移交给业务部门使用，这种设计中的想法大部分是从系统的角度在想问题，而不是从应用的角度。 SOA的另外一个问题是充斥着大量的编配（orchestration）, 注意这里我们说的是编配而不是编排（choreography）。在管弦乐（也是orchestration这个词）中，有一个统一的指挥，由他来
59.指挥整个乐团，他来设置节奏、音量等各种信息。整个乐团里的个体都无一例外的听命于这个指挥。我们设想一下，如果某个时候同时发生两件事，那么可能就需要两个指挥。总而言之，在这种模型里面，有一个类似指挥的角色来对整个系统全盘负责。而编排却不是这样，在编排的时候，每个个体只需要关注自己周围的成员就行，并没有一个统一的总指挥。当出现问题的时候，每个个体只要知道自己应该怎么调整就行，同样也不需要一个所谓的总指挥来指挥。 SOA这种类似管弦乐团的组织方式，过分集中化了，从而导致其本身通常难以测试。
60.SOA还有一个问题是工艺受阻。SOA需要我们有这样的供应商，能满足业务部门的所有想法，然后业务部门只需要坐在自己的办公室里面做一些自定义的配置就可以了。因此最后的工具通常是我们将一些之前有人用过的系统稍作修改来供应另外一群用户。事实上，SOA搞出来的东西甚至比没有他们之前还要更难以修改。讽刺的是SOA恰恰是为了让改动变得容易而诞生的。不可避免的是，SOA也很难进行测试。
61.好，现在我们来聊聊微服务（Microservices）。简单来讲，你可以将微服务理解成正确的SOA模式。我们的关注点还是服务，在微服务的架构里面，服务是作为一个基础单元存在的。SOA本身即是面向服务的架构，所以我们这个其实也可以叫SOA2，但是我们还是用了微服务这个名字，目的就是提醒大家不要搞海量服务。这是一段从James Lewis和 Martin Fowler的文章中摘抄的一段关于微服务的定义：一种将一组小型服务做成一个单独应用的开发方式，每一个小型服务在其独自的进程中运行，使用诸如HTTP资源API等其他轻量级方式进行通信。重点是要轻量级。微服务有什么特点呢？第一个显而易见的特点是，微服务中每个个体服务单元都很小。这里的“小”并不是绝对的，其思想要点是，“与其搞一个大而全的服务体，我们更倾向于小一些的单一服务。” 微服务的另外一个特点是，这些服务是按照业务能力构建的。之前我们经常掉入一个陷阱，就是总是从系统的角度思考问题，而不是从业务角度。现在我们不仅要有思考系统的能力，更要具备思考业务的能力。除此之外，我们还需要按照业务能力来组织工作。对于业务部门而言，如何实现并不重要，他们所关心的是系统长什么样子，怎么能方便用户使用。业务部门是这么思考的，我们也需要围绕业务能力进行设计。
62.微服务中的服务个体都是可以单独部署的。也就是说，只要没有动接口协议，在修改某一个服务个体的时候，完全不用理会其他服务个体。在微服务中，只有很少一部分需要集中管理，而由于各个服务个体之间是相对独立的，因此我们甚至可以在不同的服务单元中采用不同的技术栈。比如某一部分的计算逻辑比较复杂，我们选用clojure。另外一部分对应着很强的对象模型，我们就可以用一些面向对象的编程语言等等。在微服务中，我们主张“智能端点”和“傻瓜管道”。基本上如果管道两边都按照一定的假设强制执行的话，重新配置时就会简单许多，而并不需要时刻监控管道中的中间状态。当我们尝试把现在这种模块拆分的时候，需要考虑的另一个问题是，数据库的结构应该是什么样的？具体的问题还包括数据如何进行维护，其他单元如何缓存等等。毫无疑问，在微服务中，数据结构的形态会有很大不同。使用微服务意味着什么呢？首先粒度的问题是至关重要的，当你在思考微服务的边界问题时，这应该是使用微服务架构需要做出的一个最重要的决定。在这个过程中需要平衡好内聚和耦合的关系，一方面为了加强内聚你可能需要将某一些服务合并到一起，另外一方面为了解耦，需要对某些服务进行拆分。事实上在使用微服务架构的整个过程中都充斥着来回往复的拆分和合并，直到你真的理
63.解了服务的边界应该是什么为止。我们后面会继续回到这个问题上。微服务中的各个服务个体是可以独立扩展的，也就是说如果某个服务上的需求量猛增，我们只需要扩展该服务即可，与其他服务无关。相应的，对于各个服务的状态监控也非常重要。如果你手头是一个单块，从定义来看，理论上你需要监控的只有一个东西。而到了微服务里面，因为我们有大量的小型服务，因此需要对所有这些服务进行监控才行，你需要清楚地知道每一个服务是不是在工作，是不是在正常工作，为此光监控就会需要更多的机器。在微服务中，我们还需要考虑服务挂掉的情况，而这些情况在传统单块架构里面一般不用怎么考虑。比如我们有一块业务需要依赖数个独立的微服务，那么我们需要考虑的失败场景就相当多了，基本上是把所有这些可能的失败进行排列组合，而不得不说的一点是，在传统单块架构里面这些可能根本就不称之为一个问题。在微服务架构中，因为我们有很多独立的单元，它们需要独自进行部署，因此我们真心离不开自动构建、自动化部署和持续交付这些基础。在微服务中，虽然我们在不同的服务中可以使用不同的技术栈，但是如果任其发展，最终也会完全不可控，因此我们需要管理好这种灵活性。在我之前的一个项目里面，光是XML解析就有11种不同的方法，是的你没听错，11种之多。一般来讲我觉得两种XML解析器尚能接受，但是11种实
64.在是难以理解。因此在微服务架构中，我们必须要避免引入所有类型的编程语言以及所有种类的数据库，没什么原因，明眼人都知道我们不能这么做。在系统的技术栈方面，我们必须在某个层面进行控制，否则一发不可收拾了。当然最终一致性也必须管理好。一旦我们开始将数据分散到各个不同的服务单元里面，就必须考虑到这对于信息传播会有什么影响。其中的一个结果就是，我们需要给业务人员讲清楚，什么是最终一致性。一般而言我觉得业务人员会理解成“可能会一致”，而不是最终会达到一致。我们必须时刻想到由于最终一致性的存在所可能产生的各种后果。同样，如果我们用的是一个大而全的关系型数据库，压根就不会存在这个问题。好了，大家看看我们列出来的这些个问题，他们一个比一个复杂，而在传统的单块模型中，这些问题我们根本不用想。当我们回顾这些问题时，不由得会想到我们的初衷，如果我们的初衷能够得以实现，最少能弥补解决这些问题时所带来的痛处。我们的初衷是什么呢？让系统能尽可能快的响应变化！另外一个方面，这些问题也在一定程度上警醒着你，微服务这个东西不是你想象的那么简单，不是照着教程做一遍就可以大功告成，然后出门跟人炫耀：哥在搞微服务哦，牛逼吧！最后有一点差点忘了说，接口的改动也必须有个限度。在定义清楚服务边界的时候，少不了要修改一些接口协议，在修改的时候务必想清楚这个动作意味着什么。这个也深受团队成员结构的影响，比如如果写另外一个服务的人就在你旁边，改
65.起来三两句话就搞定了，但是如果团队成员咫尺天涯或者天各一方，这个沟通过程本身就是一个巨大的成本。好了，以上这些就是我认为的在准备使用微服务的时候，需要想清楚的一些问题。现在我们有两个选项。第一个是一片绿地，就好比我们拿到一个空白的项目，没有任何的遗留代码。这种情况也有，但是很少。另外还有一点，在马丁即将发表的一篇文章里提到，我们并不建议在一个崭新的项目中一开始就使用微服务进行开发。因为你很可能并不真的理解业务领域，也很难理解各个服务的边界。因此在这种项目中，可以先做成单块的，进行适当的模块化，加深理解之后再考虑演进成微服务。总而言之，你迟早会走到这个点，就是我们怎么将一个单块系统拆解成微服务架构。首先，想清楚边界上下文。这其实是从《领域驱动设计》一书中拿过来的概念。所谓的边界，指的是你可以将某些部分用一个圈圈起来，圈里的内容代表了一定的业务面。这个所谓的边界其实就是我们设计服务边界时的一个重要指示。再回到我之前说的那个问题，你需要在对你的系统有一个全面透彻的认知之后，才能做出这些决定。作为划分服务边界的第一个提示便是：尝试按照领域驱动设计的方式来思考服务的边界应该在哪里。其次还是这一点：从业务能力的角度来思考服务的边界。想想系统所提供的产品、服务是什么，从这个角度想想怎么样
66.才算一个合理的服务边界。想想调用者需要什么。与提供方驱动方式不同的是，你需要想想这个服务的使用者会需要些什么信息。也就是说需要从真实的需求开始想问题，而不是一些作为提供方揣测出来的需求。想想服务之间的通信模式。想想哪些服务、哪些系统可能会用到同一组数据，不同的服务怎么合作来实现一个特殊的业务产出。特别是当我们在犹豫是要将两个服务分开还是合并到一块的时候，想想拆开之后可能产生的各种通信，以及通信失败的情形等等。想想数据结构。一般而言，大家不愿意花太多精力想怎么保护数据的问题，也不会纠结太多最终一致性产生的影响。你怎么设计数据，合适的数据结构应该是什么样的也可以作为一个指示你如何设计服务边界的提示。因为服务是持有数据的。我们想的不再是一个数据库周围围绕着一堆服务，而是每一个服务有一个自己的持久化存储。
67.想想联动变化模式。比如有两个业务部分需要一起改，其实某种程度上是在提示你，是不是把这两块放到一个服务里面更加合适。因此多想想未来可能产生的各种改动，对你做出决定也会有所帮助。做好出错的准备，你可能经常需要将一些服务进行合并，而后搞不好又要重新再拆开。由于服务还牵扯到数据，如果两个服务的关系是一个服务主要负责一部分数据，而另外一个服务对这部分数据只是进行缓存的话，你或许还要考虑一些需要进行数据迁移的情况。一般而言你不会想经常修改服务的边界，因为这会带来一系列的应用程序，数据的改动。但是还是那句话，做最坏的打算。
68.最后的一点是：做一名有耐心的读者。这其实扯到演进架构的内容了。首先是我们不能把build搞挂了。我们能做的是：只有在没有别的选择的时候，我们才开始改。而做耐心的读者就是为了确保他们改的确实是你所需要的。也就是说在正式确定修改之前，需求本身的变动可能更大。 OK，那么微服务与演进式架构还有什么联系呢？其实当我们谈论演进式架构的时候，是有很多不同原则的。这些原则都很严格，而微服务某种程度上展现出了一些演进式架构的原则。我们在谈微服务的时候，主要是想用它来快速应对频繁的需求变更，因此微服务所承载的期望便是让我们能尽可能快地适应变化。而演进式架构中所倡导的进化性与此不谋而合。可进化型并不同于可维护性，但也不是说要怎么预测未来，而是一种随时准备响应变化的状态，而不管你是否提前就设想好了这些变化。以前关于可进化性的一个理解误区是，我要非常聪明的想到所有可能出现的变化，并且为所有的这些可能的变化写好代码，哪怕到头来根本就没变。因此微服务将“可进化性”作为其首要目标。耐心的读者，是的前面已经提到过一遍了。我们可以做出任何改变，但这种改变必须是我们经过大量的沟通讨论之后得出的统一结论。遵从康威法则。我们需要关注怎么组织团队结构，以及不同的团队结构可能影响到的最终系统形态。只有团队对服务有很好的所有权意识，其做出来的微服务才是这种松耦合的独立
69.服务。在某些采用了微服务的组织中，并没有一个专门的支持维护团队，因此每个团队成员会不自觉地将他的那部分代码写好，因为谁也不想大周末的还要跑到公司来修BUG。适当耦合。我们在谈演进式架构的时候，其实总是在平衡耦合与性能、复杂度等其他因素之间的关系。协议。在微服务架构中，各个服务可以独立演进。那么必不可少的一环就是相互之间的接口协议。通常而言，我们可以借助于一些协议测试工具或者文档来确保相互之间正常工作。作为服务提供方，同时还应该提供对应的接口测试给调用方，而一旦调用方发现这个测试失败了，马上需要找到提供方确认问题。测试的另外一重含义是，只要这个全面的接口测试是正常通过的，那么无论提供方把代码改成什么样了，调用一方都不用关心，因为大家都是独立的，链接着彼此的就是这些接口协议，这也是为什么微服务中的接口协议显得如此重要的一个重要原因。最后，作为一名来自ThoughtWorks的员工，我不得不谈谈测试相关的事情。我们发现如果你始终沿着方便测试的方向设计架构，最后的架构会更加简洁。而且易于测试的系统一定是有一个清楚的定义的，你甚至不需要颗粒度太细的测试，哪怕只有一个非常顶层的端到端测试，只要这个测试能简单明了的描述其行为就已足够。当你的架构设计得很好，边界划分得很清楚，系统本身就应该是很好测试的。我们发现，一般而言，不管是从代码层面还是系统层面，关注测试始终会让你的架构
70.更加完善。而且一般而言，基于测试定义的边界，也让整个架构更容易做出改变。持续交付在这里扮演什么角色呢？微服务相比于传统架构，增加了大量的运维负担。有更多的东西需要部署，有更多的地方需要监控，出错的地方自然也成倍增加，有更多的数据库，对应的需要更多的备份。在微服务架构中，出现问题时如何快速恢复也是件很复杂的事，因为服务数量众多，对应的排列组合情况更是数不胜数。第二点是微服务需要很强的运维文化，这里我用了“不明智”这个词，主要是强调运维文化对于微服务架构的重要性。如果你的开发团队和运维团队之间有堵高墙，那么用微服务实施下去必然是个灾难。这里面有大量的琐事需要做好做对，需要理解清楚。如果没有一种强运维环境，你那个单独的运维团队一定会被你搞疯掉的。如果因为不能严格执行持续交付而选择了微服务也不是一种明智之举。在程序出错的时候，我们需要赶紧进行调试，但是如果你连现在的代码是哪个版本都没法准确知道，你告诉我怎么调试？所以“严格执行持续交付”是微服务架构赖以成功之根本。关于持续交付的内容，比如基础设置自动化，自动化部署，自动化测试等等都缺一不可。拿自动化测试举例，与传统架构相比，你的测试场景会更加复杂，甚至就连程序主路径这
71.一个方面都要比原来负责很多，因此测试就显得至关重要了。我应该从哪儿开始呢？跟前面讲的一样，我们始终建议在完全透彻的理解业务背景的前提下再尝试使用微服务。在一个崭新的项目上，始终建议从一个单块架构开始，因为你不可避免地会犯一些边界划分的错误，除非你真的是对于这个领域烂熟于胸。在开始的单块架构中，你依然可以让代码保持整洁清晰，有完整的测试覆盖。实施微服务的时候面临的一个最大问题是，大家容易把它用错了，导致大量没有必要的反复更改，从这个意义上来讲，从一个单件开始不失为一种较为安全的选择。
72.微服务是一把尚方宝剑吗？我们说它并不是。我们确实见证了不少使用微服务架构的成功案例，但是就微服务本身而言还是有很多问题需要考虑。比如我之前提到的最终一致性、错误的排列组合等问题。这些问题也并不是我们完全不知道怎么解决，我们知道怎么管理开发流程，我们知道该怎么沟通，只是在微服务中要稍微复杂一些而已。但是面对这些问题的时候，不要害怕做出修改。你完全可以重新设计某些部分。我们有严格的接口协议、全面的接口测试覆盖，来使得你在修改业务流程、引入新功能、新的校验方式时更加从容。事实上这些东西也确实容易朝秦暮楚，现在只要谁在社交媒体上秀了个新功能，马上大家一窝蜂地都想要这个新功能了。用户的期待就是改变的这么快，业务生命周期也越来越短，安全相关的问题也是日新月异，所有这些变更都驱使着我们快速适应变化，而微服务便是在这样的大环境下应运而生的，但是微服务并不是免费的蛋糕，也有其自身的成本消耗。
73.微服务即演进式架构文/禚娴静微服务架构风格正在席卷全球。去年三月，O'Reilly举办了他们的第一届软件架构大会，提交的话题中与微服务相关的占绝大部分。那么为什么这种架构风格会突然如此流行了呢？微服务是后DevOps革命时代出现的第一种全新架构风格。它是第一个全面拥抱持续交付的工程实践，也是演进式架构家族的一员。演进式架构以“支持增量的、非破坏的变更”作为第一原则，同时支持在应用程序结构层面的多维度变化。不过，微服务仅仅是支持某些演进行为的众多架构之一。本文分享了演进式架构风格的一些特点和原则。演进式架构软件行业曾经有这样一个共识，架构一旦确定，“日后很难改变”。演进式架构将支持增量式变更作为第一原则。由于历来变更都是很难预测的，改造的成本也极其昂贵，所以演进式架构听上去很吸引人。如果真的可以在架构层次做到演进式地变更，那么变更就会更容易、成本更低，也能发生在开发实践、发布实践和整体敏捷度等多个地方。微服务满足这一定义，因为它遵循强边界上下文的原则，从而使得Evan的领域驱动设计中描述的逻辑划分变成物理上的
74.隔离。微服务能够通过采用自动化基础设施建构、测试、自动化部署等先进的DevOps实践，获得这种分离。因为每个服务在结构层面与其他服务都是解耦的，替换服务就像替换乐高积木一般。演进式架构的特点不同的演进式架构展示了一些共同的特点，我们已经识别了很多特点，并收录进即将出版的《演进式架构》一书里。本文将分享其中的几个特点。模块化和耦合边界划分明确的组件，显然可以给希望做出非破坏性变更的开发人员以更大的便利。而毫无架构元素的大泥球架构就无法做到演进式变更，因为它缺少模块化。在一个大泥球项目中类 (图中圆边上的点 )与类之间的耦合度 – 来自一个不愿透漏名字的项目
75.不适当的耦合将变更导向难以预料的方向，从而阻碍演化。而演进式架构都支持一定程度的模块化，这种模块化通常体现在技术架构层面（例如经典的分层架构）。围绕业务能力组织受领域驱动设计的启发，越来越多的成功架构都以在领域架构层的模块化为特色。基于服务的架构与传统的SOA主要区别在于模块划分的策略，SOA是严格按照技术层进行模块划分，而基于服务的架构则倾向于按业务领域划分。试验试验（experimentation）是演进式架构给商业交付带来的最大价值之一。从操作角度来讲，可以采用A/B测试、金丝雀发布等常见的持续交付实践对应用进行低成本的、微小的变更。微服务架构常常是围绕服务之间的路由来定义应用程序的。通常，微服务架构围绕服务之间的路由来定义应用程序，允许同一个服务的多个版本同时运行。这反过来也使得试验和现有功能的逐步替换成为可能。最终，这使得你的业务可以花更少的时间去猜测待办故事项，从而投入到假设驱动开发中。演进式架构的原则
76.思考演进式架构的另一个方法就是考察它的原则。原则描述了架构本身的不同特点或者设计架构的方法，其中一些原则专注在特定的架构决策过程。适应度函数我们将浮现式和演进式架构区别对待，并且认为这种区分是很重要的。就像在进化计算技术中的遗传算法一样，一个架构级别的适应度函数指明了我们的目标架构是什么样子，其中一些系统关注高运行时间，而其他一些系统则会更关注吞吐量或者安全。这张雷达图展示了适用于软件系统的几个重要的适应度函数在项目前期思考一个特定系统的适应度函数，可以对决策
77.的制定和决策的时机提供指导。适应度函数是对架构决策的衡量，通过适应度函数，我们可以预见架构是否在向正确的方向演进。痛苦的事提前做受极限编程社区的启发，许多持续交付和演进式架构的实践都体现了“痛苦的事提前做”原则。在做一个项目的时候，如果一些事情可能会很痛苦，那么你需要强迫自己更早更频繁地去做这些事情。这反过来会鼓励你用自动化的手段消除这些痛苦并能提前识别问题。那些基础的持续交付实践，如部署流水线、自动化基础设施建构、数据库迁移，就是这一原则的应用，它们会提早解决变更带来的常规问题，从而使架构的演进更容易。最后责任时刻决策的时机是传统架构和演进式架构的最主要区别。这些决策可以围绕应用程序的结构、技术栈、特定的工具或通信模式。在传统的架构中，这些决策发生在早期写代码之前。而在演进式的架构中，它们发生在最后责任时刻。延迟决策的好处是有更多可用的信息来辅助决策。其成本体现在做出决定后任何可能出现的重复工作中，这些工作可以通过适当的抽象得到
78.减轻，但成本仍然是实打实存在的。相比而言，决定太早的成本也是很明显的。比如一个通讯工具的选择，不同的工具有不同的特性。如果我们选择一个可能最终也不会用到的重量级工具，那就是在项目中引入了技术债。这个技术债是由于使用了错误的工具导致开发进度延缓而出现的。你不能拿事先“抽象一切”作为借口。我们仍然支持敏捷YAGNI(You Ain't Gonna Need It，你不会需要它)的原则，但会更倾向于在合适的时候做出决策。当然，我们在考虑最后责任时刻的一个最直接的问题就是，什么时刻是最后责任时刻。适应度函数对这个问题提供了指导建议。那些会对架构、设计选型或者项目的关键成功有重大影响的决策，都必须尽早做出，延缓这些决策往往得不偿失。总结软件架构师常常用画图的方式来解释系统之间的适配，然而太多的架构师并没有意识到，一个静态的二维架构图的生命是很短暂的。软件世界是不断变化的，它是动态、而不是静态的存在。而架构也并不是一个等式，它是持续过程的快照。持续交付和DevOps运动都诠释了一个问题，即由于忽略实现架构并使之保持常新所要付出的精力。其实架构建模和付出这些精力本没有什么问题，但是架构的实现仅仅是第一步。架
79.构只是抽象，直到真正投入运维。换句话说，如果你没有实现并升级过一个架构，甚至帮它渡过难关，那么你就无法真正判断架构的长期生命力。架构师的运维意识是演进式架构的关键。演进会影响具体的实现，因此这些实现细节是不能忽略的。持续交付在架构层面的要求，使得实现更可视化、演进更简单化。因此，持续交付是所有演进式架构重要的助力。
80.你以为是微服务或Docker？其实是组织架构！文/肖然 It's Microservices …It's docker …It's organization structure 微服务和容器毫无争议地成为了这个时代的主旋律，大家争先恐后地让自己的团队和企业去尝试这样的旋律，但往往发现曲高和寡，难以在整个组织内形成共鸣。在本文中，我们尝试揭开微服务和容器技术背后映射出的组织结构的变迁，以及组织结构对落地微服务和容器化架构所带来的反向制约，最后用INVEST原则来看看支撑这样松耦合架构的组织结构应有的特质。希望能够帮助迷茫中的企业和组织重新思考自己的微服务之路。 Microservices（微服务）和docker（容器）成了近一年来软件行业的新宠，每次参加相关活动总会感到康威老先生站在背后邪邪地笑着：“我早告诉你们了”。尽管Martin Fowler在“定义”微服务时十分小心的警告了大家所要付出的代价，但好像微服务的优点太过于吸引人，以至于大部分软件开发组织和企业都把微服务这种架构方式作为了未来的必选，大家都觉得我就是那个高个子（I'm that tall!）。
81.Martin Fowler对伴随微服务架构的高工程实践能力的比喻。随着容器技术到达生产应用的临界点，这种化学效应好像一触即发，我们仿佛看到了未来一个不一样的软件微服务大集市在逐步展开！在这个集市里会有淘宝这样的平台，为中小服务卖家搭起一个在线商城，买家可以根据自己的需要搜索及购买琳琅满目、各式各样的服务，在线或是二进制、代码质量及自动化覆盖率等指标成为同类服务评级的重要标准。杀手级的服务如区块链或者量子加密可能成为皇冠销量服务。最后掀起一大波程序猿开微服务店的热潮~ 很期待那是怎样的卖家秀和买家秀啊！这种几乎接近于科幻的描述可能只适合作为微信上的谈资，但微服务和容器技术的流行却并非偶然。康威老先生用自
82.己的定律揭示了一个更深刻的道理：这不是一次技术架构或者基础设施的革命，而是为了保持组织灵活性的必由之路。换句话说，软件开发组织或企业开始意识到一切的管理和技术实践都必须为保持尽可能高的组织灵活性服务。一定会有人问为啥要保持“尽可能高”的灵活性呢？铁打的营盘流水的兵、稳定的规章制度不也缔造出了历史上那么多成功的组织和企业吗？论尽可能高的组织灵活性所以我在前面加了定语“软件开发”，当然现在我们有一个
83.更广泛的提法：科技企业。通常我们认为产品或服务的技术含量比较高，具有核心竞争力，能不断推出适销对路的新产品，不断开拓市场的企业为科技企业。在我们所处的软件时代，大量的科技企业都跟软件沾上了边。但历史上我们可以回想大生产时代炼钢也曾是高科技，信息时代发邮件也是高科技。前两波的“科技企业”给我们的印象可不是灵活的：几大钢铁巨擘让人联想到的应该是当年国家呼唤生产力全民建设的宏伟场景；信息时代佼佼者如Microsoft和 IBM让人联想到的应该是动辄千人的大型工业软件开发队伍，一个部署都得来一个专家队伍。那么为啥现在咱们的科技企业必须灵活，而且必须尽可能高呢？这里我们再次使用康威老先生的定律来做推论，康威定律说 “一个产品或系统的设计（架构）受到其生产组织自身交流沟通结构的制约”。换句话说如果你有一个前端展现团队、一个后端服务团队和一个数据库团队，那么我们可以肯定，搞出来的系统会分前后台和数据库的设计。这本身是一个悲观的定律，所以前面的团队发现新需求来了必须沟通三次，前后台团队关心新需求对自身架构的影响，数据库设计关心对现有数据结构的冲击，最后总是会在各方的争执中得到一个别扭的解决方案。很多团队早已经习惯了这样的痛苦，数字化时代的变化频率将这样的痛苦逐渐推向了顶峰。举例感受一下：达到100亿
84.产值，首钢用了71年，联想用了13年，这个时代的小米用了仅仅3年！而今年的小米已经不是站在浪潮之巅的科技新贵了。所以康威老先生说：如果要保持产品的持续竞争力，就要保持组织的灵活性。曾经有人跟我争辩说：“我们做的是数字化时代的后台系统，不直接面对市场，需求很稳定，搞那么灵活成本反而高。”于是我指着他们有着千万行代码的系统说：“你们至少有 30%代码是冗余的，这就是组织缺乏灵活性的另外一个恶果。” 这里我们先收缩范围到软件开发，非常有意思的是在咱们这个行业里，针对同一份需求，没有两个开发人员实现出来的代码是一样的（也许Hello World例外）。甚至，当我发现两个程序员使用的变量命名一样的时候我会怀疑他们抄袭了。这说明软件开发从需求提出到写代码实际都是在做设计，不同的人设计出来的东西就会不同，像大家的签名一样。
85.设计甚至延续到了后面的软件测试和部署，同样的应用在不同的网络拓扑结构下表现可能是完全不一样的。那些追求稳定的组织希望尽早结束设计这个高度不确定性的活动，从而能够通过标准化来提高效率。即使在敏捷开发主流化的今天，很多团队仍然是架构师“画图”，码农堆砌代码。所以这样的组织很快发现自己深陷二进制的泥潭，进退维谷。我经常跟这样的团队讲：你们缺乏“代码的响应力”。而响应力对组织的要求就是灵活，能够从前到后驾驭设计活动带来的不确定性。小结一下：数字化时代的市场变化是迅猛的，康威老先生
86.已经告诉我们，处在这样时代背景下的科技企业保持组织灵活性是十分重要的。而软件（广义讲新科技领域）本身由于强设计而带来的不确定性又加重了对组织灵活性的诉求。于是在这个时代我们看到了如Google、海尔这样已然成功的企业开始大刀阔斧地改革自己的组织结构，这种对灵活性的极致追求成就了这些组织持续保持市场领先水平的核心竞争力。毫无疑问，微服务架构的优点也正反向映射出了组织结构的灵活性，而容器技术的运用降低了这种松散集市结构的运营成本，就如同淘宝平台的出现给千千万卖家和买家搭建了一个基础的交易平台。弹性伸缩的容器化计算资源加上松耦合的微服务架构必然会吸引追求组织灵活性的企业去打败康威定律，保持组织活力。组织结构的INVEST原则前面咱们辩证了数字化时代科技企业保持组织灵活性的必要，那么灵活的组织结构应该满足什么原则呢？下面我们就借用敏捷开发中赫赫有名的需求管理原则INVEST来剖析一下怎样的组织结构才能够真正落地微服务架构和容器技术带来的灵活性优势，或者从另外一个角度看支撑微服务架构的运用。
87.两种组织结构对比示意独立的：Independent 按照微服务架构的团队应该对外提供一种或多种服务，服务和服务之间应该是松耦合的，所以背后的团队也应该是相对独立的。遵循康威定律，如果一个大型组织没有能够划分出服务导向的相对独立团队，那么最后对外提供的产品或系统的内部结构也不可能是简单的服务组装，而会是我们常说的“意大利面”，内部结构纠缠不清以至于最后响应市场新需求越来越慢。便于沟通的：Negotiable。 “小”服务团队的结构必然造成整个组织的集市化、社区化。如果没有建立良好的团队间的沟通机制，很难想象这样的组织里会有任何的产出。Amazon被认为是一个微服务架构运用的成功典范，其2pizza团队的原则成为了业内的标杆。
88.但这样服务导向小团队集合的底层是长期磨合形成的良好团队间沟通机制，甚至当我们问到Amazon各个团队如何发现其它服务或要求其它团队协助完成需求时，团队都说不出具体的流程机制，一切都变得很自然，全然像我们走进自己熟悉的超市一样，能够很自然的找到日常所需。有价值的：Valuable 毫无疑问，每个团队必然是面向价值交付的。敏捷开发方法的提出其实很早就指出了传统方式下按照功能部门划分的瀑布交付模式的原罪，即每个功能部门都不对最终的价值交付负责（Output over Outcome，输出大于结果）。这样的组织结构必然造成对市场变化响应的滞后。值得一提的是面向价值交付的团队往往也是跨职能的，按照微服务的架构，团队需要负责服务从需求到部署运营的全生命周期（Outcome over Output，结果大于输出）。这也是为什么在基础的工程交付平台及实践上团队必须是一个“高个子”。可估计的：Estimable 这样的服务团队交付周期应该是很短且可以准确估计的，上线应该是家常便饭，而不是过去短则数月、长则一年的大爆炸模式。持续交付在这样的组织里应该是标准实践，让软件系
89.统时刻处于可发布状态是团队的共同责任。从Amazon和Netfliex 这样的现代科技企业身上我们已经看到了这样组织结构下逐步形成的工程能力优势，并最终转换成了业务服务上的巨大成功。短小：Small 前面提到了Amazon的2pizza团队，人数10人以内，经典的敏捷管理框架Scrum也建议5~9人的团队，可见小团队成为组织灵活性的一个必要条件。中国俗语有“船小好调头”朴实地揭示了小的灵活性，但为什么不再小一点呢？比如两个人结对一个团队。显然大家很容易发现软件开发本身的复杂性决定了要端到端交付价值两个人的团队是搞不定的。从整个组织的健壮性来讲，过小的团队也会增加企业形成单点依赖的风险。虽然没有正式确认，但我们交流中发现Amazon这样的微服务组织里其实也是存在服务冗余的，这样的重复保证了组织在切割成小团队后风险得到适当的规避。可测试的：Testable 在面对市场情况高度不确定性时，我们应该直面试错这件事情。传统职能型的大组织结构往往是不能容错的，错误的代
90.价就是整个企业走偏了方向，或者一个部门在企业里失去了话语权。在灵活性高的组织里我们却应该是能够很容易进行这样的“测试”，企业更能够利用这样的结构进行动态的投资组合管理，像Google著名的7:2:1投资比例，最后的一成就是利用组织的灵活性进行创新的测试。测试的结果往往是失败的，但正是这样的不断测试创造了Google历史上很多著名的“黑天鹅”。打破康威定律最近很多以精益（LEAN）为关键字的理论框架在咱们这个领域冒了出来，也包括我前期撰文提到的精益企业（Lean Enterprise），于是有朋友揶揄说又开始炒概念了。我却很严肃地澄清正是不希望炒概念，所以才回到了上个世纪就论证和发展起来的理念：精益。来源于丰田制造的精益总结出了很多的原则和实践，但有意无意中丰田完成了自身组织持续灵活性打造这项超越同期其它企业的伟业。其结果就是在响应需求多样化时展现出的更强适应能力。如果用我们前面的INVEST原则来看待精益组织，你会很快找到对应的原则和实践，即使在传统的工业流水线上，丰田也在形成一个个的小团队（cell，单元生产），也在通过员工的多技能培养来完成小团队内部的“跨职能”。其持续改进
91.（Kaizen）的核心思想有力保证了团队面向价值的工作方式和良好的跨团队沟通文化。某种意义上讲精益在康威定律定义之前就打破了康威定律！微服务和容器技术无疑是这个时代工程架构方面支撑组织灵活性的重要一步，然而我们不能忘记一个组织是五脏俱全的，如精益企业提到的，组织的财务审计、人力资源、采购合规等功能如何有效的“微服务”化和如何能够合力构建一个弹性的“容器”支撑平台仍然需要诸君努力！
92.
93.[实践篇]
94.基于微服务架构，改造企业核心系统之实践文/王磊本文首发于InfoQ：http://www.infoq.com/cn/articles/enterprise-core-systemstransformation-practice背景与挑战随着公司国际化战略的推行以及本土业务的高速发展，后台支撑系统已经不堪重负。在吞吐量、稳定性以及可扩展性上都无法满足日益增长的业务需求。对于每10万元额度的合同，从销售团队准备材料、与客户签单、递交给合同部门，再到合同生效大概需要3.5人天。随着业务量的快速增长，签订合同的成本急剧增加。合同管理系统是后台支撑系统中重要的一部分。当前的合同系统是5年前使用.NET基于SAGE CRM二次开发的产品。一方面，系统架构过于陈旧，性能、可靠性无法满足现有的需求。另一方面，功能繁杂，结构混乱，定制的代码与SAGE CRM系统耦合度极高。由于是遗留系统，熟悉该代码的人早已离职多时，新团队对其望而却步，只能做些周边的修补工作。同时，还要承担着边补测试，边整理逻辑的工作。
95.在无法中断业务处理的情况下，为了解决当前面临的问题，团队制定了如下的策略： 1.在现有合同管理系统的外围，构建功能服务接口，将系统核心的功能分离出来。 2.利用这些功能服务接口作为代理，解耦原合同系统与其调用者之间的依赖； 3.通过不断构建功能服务接口，逐渐将原有系统分解成多个独立的服务。 4.摒弃原有的合同管理系统，使用全新构建的(微)服务接口替代。什么是微服务多年来，我们一直在技术的浪潮中乘风破浪、扬帆奋进，寻找更好的方式构建IT系统。微服务架构通过将功能分解到多
96.个独立的服务，以实现对解决方案或者复杂系统的解耦。微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务；敏捷方法论帮助我们消除浪费，快速反馈；持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力；虚拟化和基础设施自动化( Infrastructure As Code) 则帮助我们简化环境的创建、安装；DevOps文化的流行以及特性团队的出现，使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。实际上，微服务本身并没有一个严格的定义。不过从业界的讨论来看，微服务通常有如下几个特征: 小，且专注于做一件事情每个服务都是很小的应用，至于有多小，是一个非常有趣的话题。有人喜欢100行以内，有人赞成1000行以内。数字并不是最重要的。仁者见仁，智者见智，只要团队觉得合适就好。只关注一个业务功能，这一点和我们平常谈论的面向对象原则中的”单一职责原则”类似，每个服务只做一件事情，并且把它做好。运行在独立的进程中每个服务都运行在一个独立的操作系统进程中，这意味着不同的服务能被部署到不同的主机上。轻量级的通信机制
97.服务和服务之间通过轻量级的机制实现彼此间的通信。所谓轻量级通信机制，通常指基于语言无关、平台无关的这类协议，例如XML、JSON，而不是传统我们熟知的Java RMI或者.Net Remoting等。松耦合不需要改变依赖，只更改当前服务本身，就可以独立部署。这意味着该服务和其他服务之间在部署和运行上呈现相互独立的状态。综上所述，微服务架构采用多个服务间互相协作的方式构建传统应用。每个服务独立运行在不同的进程中，服务与服务之间通过轻量的通讯机制交互，并且每个服务可以通过自动化部署方式独立部署。微服务的优势相比传统的单块架构系统(monolithic)，微服务在如下诸多方面有着显著的优势：异构性问题有其具体性，解决方案也应有其针对性。用最适合的技术方案去解决具体的问题，往往会事半功倍。传统的单块架构系统倾向采用统一的技术平台或方案来解决所有问题。而微服务的异构性，可以针对不同的业务特征选择不同的技术方案，有针对性的解决具体的业务问题。
98.对于单块架构的系统，初始的技术选型严重限制了将来采用不同语言或框架的能力。如果想尝试新的编程语言或者框架，没有完备的功能测试集，很难平滑的完成替换，而且系统规模越大，风险越高。基于微服务架构，我们更容易在遗留系统上尝试新的技术或解决方案。譬如说，可以先挑选风险最小的服务作为尝试，快速得到反馈后再决定是否试用于其他服务。这也意味着，即便对一项新技术的尝试失败，也可以抛弃这个方案，这并不会给整个产品带来风险。该图引用自 Martin Fowler的 Microservices一文独立测试与部署单块架构系统运行在一个进程中，因此系统中任何程序的
99.改变，都需要对整个系统重新测试并部署。而对于微服务架构而言，不同服务之间的打包、测试或者部署等，与其它服务都是完全独立的。对某个服务所做的改动，只需要关注该服务本身。从这个角度来说，使用微服务后，代码修改、测试、打包以及部署的成本和风险都比单块架构系统降低很多。按需伸缩单块架构系统由于单进程的局限性，水平扩展时只能基于整个系统进行扩展，无法针对某一个功能模块按需扩展。而服务架构则可以完美地解决伸缩性的扩展问题。系统可以根据需要，实施细粒度的自由扩展。错误隔离性微服务架构同时也能提升故障的隔离性。例如，如果某个服务的内存泄露，只会影响自己，其他服务能够继续正常地工作。与之形成对比的是，单块架构中如果有一个不合格的组件发生异常，有可能会拖垮整个系统。团队全功能化康威定律（Conway's law）指出：一个组织的设计成果，其结构往往对应于这个组织中的沟通结构。传统的开发模式在分工时往往以技术为单位，比如UI团队、服务端团队和数据库团队，这样的分工可能会导致任何功能上的改变都需要跨团队沟通和协调。而微服务则倡导围绕服务来分工，团队需要具备
100.服务设计、开发、测试到部署所需的所有技能。微服务快速开发实践随着团队对业务的理解加深和对微服务实践的尝试，数个微服务程序已经成功构建出来。不过，问题同时也出现了：对于这些不同的微服务程序而言，虽然具体实现的代码细节不同，但其结构、开发方式、持续集成环境、测试策略、部署机制以及监控和告警等，都有着类似的实现方式。那么如何满足 DRY原则并消除浪费呢？带着这个问题，经过团队的努力， Stencil诞生了。 Stencil是一个帮助快速构建Ruby微服务应用的开发框架，主要包括四部分：Stencil模板、代码生成工具，持续集成模板以及一键部署工具。
101.Stencil模板 Stencil模板是一个独立的Ruby代码工程库，主要包括代码模板以及一组配置文件模板。代码模板使用Webmachine作为Web框架，RESTful和JSON 构建服务之间的通信方式，RSpec作为测试框架。同时，代码模板还定义了一组Rake任务，譬如运行测试，查看测试报告，将当前的微服务生成RPM包，使用Koji给RPM包打标签等。除此之外，该模板也提供了一组通用的URL，帮助使用者查看微服务的当前版本、配置信息以及检测该微服务程序是否健康运行等。
102.[ {rel:'>rel: