转载

技术雷达之微服务架构

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

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

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

技术雷达之微服务架构

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

我一开始接触微服务架构的时候也觉得这好像不是一个新的概念，很早之前就有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。通俗点儿讲就是“微服务红眼病”，或者说是“微服务你有我也要”。这意味着在社区刚刚爆发，对于微服务架构踩下油门的时候，我们已经踩下了一脚刹车，但是这并不是代表我们不看好微服务架构，而是认为我们需要进一步了解这种新的架构模式再把它引入到实际的项目中，因为采用微服务架构是需要门槛和成本的。

用微服务你够“个”吗？或是说用微服务你够“格”么？你有这个能力和足够的资源驾驭这个模式吗？对此我是在心里打了一个问号的。为什么？Martin Fowler在他那本非常著名的《企业应用架构模式》中，就提到了分布式对象设计的第一原则：“设计分布式对象的第一个原则就是不要使用分布式对象”。有经验的程序员或是架构师，肯定能体会到分布式系统会给我们带来很大的挑战，例如如何快速构建开发环境，如何做自动化测试，如何设计部署流水线，如何运维监控，如何保证一致性和事务，都是我们需要考虑的问题。

技术雷达之微服务架构

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

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

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

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

技术雷达之微服务架构

我们刚才提到了康威定律，康威定律说的是设计系统的组织产生的设计和架构等价于组织间的沟通结构，大家可能都在网上都看过一张图，列举了很多大型公司的组织架构，不同组织架构决定了其开发软件的方式，也一定影响了系统架构和最终软件呈现的样子，康威定律就是在说组织结构和设计结构的关系。

康威定律还有一个逆定律：如果想改变一个设计架构方式，首先要改变组织结构。刚才我提到，我们部署一个开发环境就需要一天的时间，但是按理来说微服务架构是让我们做事情更简单才对，你只需要关注你想关注的服务，为什么一个开发要了解超过20个服务的上下文？这就是组织结构和技术架构不匹配造成的。我们经常发现推动技术架构的转型和演进很难，因为我们忽略了整体组织结构的变化，所以这是康威定律对于微服务架构的意义。

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

原文 http://insights.thoughtworkers.org/tech-radar-and-microservices-architecture/

正文到此结束