王健：技术雷达之微服务架构

作为一家服务于全球不同类型客户的IT专业服务公司，ThoughtWorks一直追求最卓越的技术，并用它们来解决客户实际的问题。而为了体现技术卓越，ThoughtWorks全球技术委员会（TAB）定期讨论技术战略，分析对行业产生重大影响的最新技术趋势，这便是我们看到的每年两度的《ThoughtWorks技术雷达》。 2016技术雷达峰会不仅能为您解读最新版《ThoughWorks技术雷达》四大主题之外，还希望能覆盖更多更具实践价值的专题，为您提供更多选择，也为各个优秀实践提供多一个展示和分享的平台。

● ● ●

《JavaScript技术爆炸下的项目选型何去何从》- 刘尚奇

《技术雷达之微服务架构》- 王健 今日分享！

《Cloud Enabled Stack Management》- 孙建康

《Docker打造App-Centric交付》- 钟健鑫

《技术雷达之构筑软件安全DNA 》- 韩锴

《海航集团的数字化转型》- 龙旭东，海航生态科技集团CTO

《企业内部开源及社交化编程：连接与聚合》- 林鼎军，某世界500强电信企业业务部产品SE

《Ruff，JavaScript 硬件开发新领地》- 郑晔，Ruff CTO

《实践演进式设计》- 袁英杰，ThoughtWorks首席咨询师

《传统企业的微服务架构转型》- 杨波，丝芙兰Sephora首席架构师

《通过CI/CD来保障数字化转型》- 刘宇峰，ThoughtWorks首席咨询师

● ● ●

我们都知道做前端不容易，我们常说，前端的技术架构工具甚至是按周为单位迭代进化的，相信大家都可以体会到这种如坐针毡的感觉。再来看看后端，后端好一点，至少死的没有那么快……在后端架构领域微服务架构是最近一两年比较火的架构，今天我们就通过技术雷达的视角来看一下微服务架构的整个发展过程。

其实技术雷达本身有很多种玩法，我们看技术雷达往往都是关注于当前最新的技术趋势，因为技术雷达本身就是对于当前技术趋势的一个“快照”：我们现在关注哪些技术，我们认为哪些是我们现在的热点和主题。而我在准备这个分享的时候是换一个角度看的，我把从2011年到现在所有的技术雷达都翻出来摆在桌面上，在里面寻找所有跟微服务相关的内容，按照这个新的以时间发展的维度来审视一下微服务架构的发展历程。

相信在场的大多数人都已经听说或了解了微服务架构，这个方向现在确实比较火，刚刚结束的QCon都成立了一个主题专门讲微服务架构。但相信大家了解微服务或者听说微服务架构都也是近两年的事情，我特地上谷歌搜索了一下微服务的搜索趋势，从搜索结果上看确实微服务架构也是从2014年才逐渐兴起到目前呈现出一个爆发的趋势。但在技术雷达中，早在2012年的3月份就已经包含了微服务架构相关的内容。

在2012年3月份技术雷达上第一次出现微服务架构，在当时其所在的区域是评估阶段，这说明我们在2012年三月份的时候就已经捕获到微服务架构这个新的技术架构。到底什么是微服务架构，在马丁福勒的那篇微服务架构的文章中第一次定义了微服务架构并阐述了其九大特性，他同时提到在社区其实大家热议这种新的架构已经很长时间了，但一直都没有一个清晰的定义。

我一开始接触微服务架构的时候也觉得这好像应该不是一个新的概念，很早之前就有RPC和SOA这种面向服务的分布式架构，又冒出一个新的微服务架构，他们到底有什么区别？这里面有几个关键字可以让我们甄别你现在是传统的面向服务架构还是新的微服务架构：每个服务是不是跑在独立的进程中；是不是采用轻量级的通讯机制；是不是可以做到独立的部署。大家可以用这几点来衡量我们的服务架构。刚刚讲到Docker，Docker和微服务架构结合起来以后是什么样的场景，为我们提供了很大的想象空间，甚至可能颠覆整个软件开发测试运维甚至发布的方式。

我们继续来看，在2012年的10月的时候微服务架构已经从评估阶段被移到实验阶段，什么叫实验阶段？我们自己内部有一个解释，就是这项技术已经可以运用在实际项目中，当然你仍要控制风险，或是说此项技术已经可以在风险比较低的项目中使用了。一个项目要能进入实验项目，还有一个必须要满足的条件，就是在ThoughtWorks我们自己的项目中必须已经开始实际使用并检验过。幸运的是，我当时所在的项目也是在2012年10月份左右开始采用微服务架构的，结果也是非常好的。我们在3个月完成一个新的应用并成功上线，当时客户评价很高，甚至称赞我们是他见到过的最好的团队。

实际体验下来，微服务架构对我们来讲究竟有哪些好处？这四点是我总结的：

首先是组件化，大家可以想一想其实我们作为软件开发，一直有一个梦想，就是希望有朝一日可以把一堆的组件通过直接拼凑进来的方式快速构建我们的应用，无论是最早基于拖拽的方式构建应用，还是现在大热的前端组件化，我们一直都在试图寻找一种好的组件化方式，但是可以说到目前为止一直都还没有找到。因为构建软件本身还是一个复杂的过程，微服务架构提供一种组件化的可能，我们现在还不好说它能不能达到我们作为整体组件化的目标，但是至少从我们的实际体验，它确实能给我们带来组件化的很多好处。

然后是弹性架构，在上期技术雷达中推荐了亚马逊的弹性计算平台，大家可以设想一种场景：如果我们的系统是按照小的按业务划分的服务构成，通过容器这种非常灵活的基础设施和云的环境我们是可以做到一种非常弹性的架构。假如现在是双十一，系统可以自动监控到资源的使用情况，一旦发现资源紧张，可以通过云和容器自动瞬间扩展出成千上万的服务资源，在高峰过去之后又可以立即把所有的服务注销掉，释放资源。整个过程是完全是自动化的。微服务架构结合Docker和云，为我们实现这么一种弹性架构提供了可能。

去中心化和快速响应也是微服务架构给我们带来的好处，如果是一个单体架构，则会非常依赖于一开始对于技术选择，假如一开始选择了一个技术栈那么之后几年都被绑定在了这样一个技术栈下，很难应对变化。但是微服务架构给我们实现一个更细粒度使用技术的方式，在不同的服务里可以使用不同的语言、框架甚至数据库，真正可以做到用最适合的技术解决最适合的问题，有了以上这些好处就可以让我们更加快速地响应需求和市场的变化，增加了竞争力。

在2012年10月份一直到2014年的7月份，在这个时间段有大量与微服务架构相关的工具、技术和框架出现在ThoughtWorks技术雷达上。包含了很多领域，包括语言、测试，框架、CI、CD、持续交付，安全等等。因为微服务是一种架构，所以很多技术其实都会与其相关，大家现在看到的这些事我在技术雷达网站上搜索，在描述中直接提到微服务关健词的就有这么多技术。

并且在2014年7月份的技术雷达的四个主题中，除了JavaScrip，其他三个主题都和微服务相关：包括微服务和API的兴起，康威定律，再分段化以及去中心化。而我们再回顾一下这个时间轴，从2012年的3月份一直到2014年7月份，虽然微服务架构已经有比较大的发展，技术雷达上也已经推荐了大量相关的内容，但是其实在社区中知道这项技术的人还是不多，这通过搜索热度就可以提现，也体现出了技术雷达的前瞻性。

从2014年7月份开始微服务就开始呈现出一种爆发的趋势，但在紧接着的2015年1月份的技术雷达中出现一个非常有意思的项目：Microservice Envy。翻译过来通俗点儿讲就是“微服务红眼病”，或者说是“微服务你有我也要”。这意味着在社区刚刚爆发，对于微服务架构踩下油门的时候，我们已经踩下了一脚刹车，但是这并不是代表我们不看好微服务架构，而是认为我们需要进一步了解这种新的架构模式再把它引入到实际的项目中，因为采用为服务架构是需要门槛和成本的。用微服务你够“个”吗？或是说用微服务你够“”格”么？你有这个能力和足够的资源驾驭这个模式吗？对于我是在心里打了一个问号的。为什么？马丁福勒在他那本非常有名的《企业应用架构模式》中，就提到了分布式对象设计的第一原则：“设计分布式对象的第一个原则就是不要使用分布式对象”。在场的大家都是非常有经验的程序员或是架构师，肯定能体会分布式系统会给我们带来很大的挑战，例如如何快速构建开发环境，如何做自动化测试，如何设计部署流水线，如何运维监控，如何保证一致性和事务，都是我们需要考虑的问题。

而我们辛辛苦苦构建出的各个服务，真的像我们想象的那样完美么，整整齐齐，只要我想，随便拿出几个服务一组合就可以实现一个新的应用？这其实也是很难做到的，服务的划分切在哪儿很重要，切歪了一点就要一直背着这个包袱，有时候还不如单体应用那么好调整，所以说理想很丰满但是现实确实很骨感。这个时候我们就会有所反思，这到底是什么问题？是我们错了还是微服务架构本身有问题？

最终我们认识到答案，微服务架构虽然看起来非常美好，但是也是有很大的附加成本的。通过这张图可以看到，这条蓝线是微服务架构，这个横轴是时间轴，纵轴是生产力，微服务架构和单体应用是有一个变化过程，在我们的项目不是那么复杂的时候传统的单体应用架构的生产力是要高于微服务的，因为如果使用微服务我们要处理分布式带来的各种各样的问题：开发复杂度，运维复杂度和架构复杂度都会随之增加。而随着系统复杂度的逐渐增加，我们会发现微服务架构和单体应用的架构的生产力都会下降，只是微服务架构的下降会相对缓慢一些，这也很容易理解，因为微服务架构为我们设定了很多的边界，在它们的约束下，不容易让我们的系统演化到一个很危险的程度，每一个服务都很小，每个服务的技术栈也很独立，这样做局部的变更也会更加容易，随着系统复杂度的增加，微服务的优势才慢慢的体现出来。

那我们怎么办？为了追求生产力的最大化，一开始我们可以选择一个单体架构，然后争取在微服务生产力超越单体应用的那个复杂度点切换到微服务架构，这个结果才是我们最想看到的。所以马丁福勒提出了一种单体应用优先原则，就是一开始推荐先采用单体架构，通过演进式设计一步一步的重构到一个好的微服务架构，这又一次验证了好的架构是进化来的不是设计来的。

但是怎么保证这个演进是安全的，用什么保证我们可以持续的不断的变化，就需要有一套良好的质量守护机制。大家现在看到的就是关于微服务架构的测试策略架构图，在我所在项目里就是根据这个方式来设计我们的测试策略，它可以帮助我们在对于服务的抽取合并分离过程中做到相对的安全可控。

我们刚才提到了康威定律，康威定律说的是设计系统的组织产生的设计和架构等价于组织间的沟通结构，大家可能都在网上都看过一张图，列举了很多大型公司的组织架构，不同组织架构决定了其开发软件的方式，也一定影响了系统架构和最终软件呈现的样子，康威定律就是在说组织结构和设计结构的关系。康威定律还有一个逆定律：如果想改变一个设计架构方式，首先要改变组织结构。刚才我提到，我们部署一个开发环境就需要一天的时间，但是按理来说微服务架构是让我们做事情更简单才对啊，你只需要关注你想关注的服务，为什么一个开发要了解超过20个服务的上下文？这就是组织结构和技术架构不匹配造成的。我们经常发现推动技术架构的转型和演进很难，因为我们忽略了整体组织结构的变化，所以这是康威定律对于微服务架构的意义。

截至目前，我们说的所有的东西都还是发生在2015年1月份以前，在这个过程中我们更加深刻的认识了微服务架构这种新的架构方式，它的优势，它的成本。经过这个阶段之后一直到2016年的5月份，在技术雷达上又出现了很多相关的内容，所以说我们踩下刹车不是因为我们走错了路，而是我们走的太快了，需要提醒自己不要盲目的使用，但同时我们也在保持对这个新的架构的持续关注和追踪。

来到最新的一期的ThoughtWorks技术雷达，我还发现一些有意思的技术，比如无服务器架构，对Docker的应用，对PaaS各种云的应有，这些技术的发展，会不会对微服务架构的演进提供更多可能？是否可以为微服务架构早一天落地，改变我们的开发方式提供可能？让我们大家一起拭目以待。