1.4 微服务架构的优势

微服务架构能够为我们带来许多优势，包括技术上的优势、业务结构上的优势以及组织上的优势，本节将对这些优势展开介绍。

1.4.1 技术优势

微服务架构的技术优势非常明显，我们通过一个简单示例来说明它对软件开发所带来的变化。试想在一个移动医疗系统中，用户可以通过APP进行预约挂号并形成支付订单，另外，我们也希望实现医生和科室的搜索功能从而为用户提供精准查询的用户体验，如图 1-11 所示。预约挂号和搜索对于产品的业务结构而言是非常简单和明确的功能需求，在实现上却可能有很多种不同的方法。

在图1-11中，我们发现预约挂号和搜索功能存在一定的依赖关系，因为用户可以先执行搜索操作，然后根据搜索的结果进行预约挂号。这时候，比较容易想到的实现方法是把这两个功能放在同一个模块或子系统中，要修改就一起修改。但是，一旦这种相对较弱的依赖关系在整个系统中开始滋生蔓延时，我们会发现很快就会演变成一种腐化状态。这种腐化状态通常需要使用专门的架构重构才能得到缓解（我们会在第8章中讨论这些架构重构方法），而微服务架构的引入能够避免这种现象的发生。在微服务架构中，预约挂号和搜索将成为两个独立的微服务。如果这两种服务之间需要交互，那么我们可以引入明确且轻量级的通信机制。微服务之间的边界起到一种防腐剂的作用，能够降低业务功能之间的依赖关系从而防止架构腐化。

以上的简单案例给出了微服务架构最重要的优势，我们还可以从以下几个方面再进一步展开讨论。

1.组件化方案

微服务架构提供的是一种高内聚、低耦合的组件化方案。组件所能带来的独立性与健壮性微服务都可以具备，但微服务的组件化特征更多表现在对业务的提炼和对边界的思考。使用微服务架构迫使我们使用诸如领域驱动设计的思想去进行策略设计和技术设计，从而为更好地划分业务功能、提取界限上下文和开展系统集成工作提供依据。而这些方法和依据的背后恰恰是我们在架构设计过程中经常会碰到的问题。

2.技术自由度

当系统架构转变成一系列微服务之间的通信和集成时，我们就明白具体实现技术已经不是系统设计和开发的主要约束条件。因为在微服务架构中，各个微服务之间使用的是轻量级的通信机制。所谓轻量级，就是指这些通信机制跟具体实现技术无关，不受限与某一个特定协议或交互媒介。每个微服务高度独立，可以采用适合自身开发团队和技术体系的工具和框架来实现某个微服务，从而为我们提供了宝贵的技术自由度。

3.可扩展性

在对图1-8分析时，我们实际上已经讨论了微服务架构与生俱来的可扩展性。通过服务拆分和集成，单个服务在保持通信方式不变的前提下，对其内部功能和技术的改变不会对外部依赖它的服务产生任何影响。结合可扩展性的概念，微服务架构无疑具备这方面的优势。

4.可伸缩性

可扩展性与可伸缩性是两个不同的概念，但高扩展性往往能够带来高可伸缩性，因为可以伸缩的前提是对系统有合理的拆分。当我们明确系统中的运行瓶颈，并把引起这些瓶颈的业务功能构建成独立的微服务，就可以应用服务集群等手段有效加强服务运行时的环境和状态。

5.有效应对遗留系统

微服务是可用于改造遗留系统（Legacy System）的强有力武器。面对遗留系统，一方面该系统的技术体系可能存在设计上的较大缺陷，另一方面则是因为代码量巨大且不容易修改。在代码层次与遗留系统进行直接集成是痛苦且具有挑战性的工作，但是遗留系统以提供接口的方式暴露某些功能入口仍然是一个相对容易实现的过程。一旦获取这些接口，微服务架构就能与之进行通信并完成功能整合。

6.支持持续交付

持续交付通过简单、可重复的流程来确保软件发布过程的可靠性，通常这是通过持续集成和持续交付管道得以实现。微服务作为独立的可部署单元，非常适合使用持续交付，因为每一个服务都可以在不依赖于其他服务的条件下完成发布和部署。基于微服务架构，持续交付管道可以运行得更快，从而加速问题反馈，这是持续交付的主要目标之一。而持续交付的另一个目标是降低系统风险，微服务小而独立，一旦出现问题很容易进行回滚操作。

1.4.2 业务与组织优势

康威定律（Conway’s Law）[4]指出设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。从传统的单块架构到微服务架构实际就是这一定律的一种体现。现在很多开发团队本质上都是分布式的，单块架构的开发、测试、部署协调沟通成本巨大，严重影响效率且容易产生冲突。将单块架构解耦成微服务架构，每个团队开发、测试和发布自己负责的微服务，互不干扰，系统效率得到提升。可见，组织和系统架构之间有一个映射关系：一方面，如果组织结构和文化结构不支持，通常无法成功建立有效的系统架构；另一方面，如果系统设计或者架构不支持，那么你就无法成功建立一个高效的组织。

用更通俗的说法，康威定律就是指组织形式等同系统设计，更直白地说，你想要什么样的系统，就搭建什么样的团队。如果一个组织分成前端团队、Java后台开发团队、DBA团队和运维团队，那么就形成了所谓的功能团队，各个小团队各自为政，需要强有力的组织文化和执行力才能确保各个团队之间有效协作；相反，如果你的系统是按照业务边界划分的，大家遵循同一个业务目标把大系统做成小系统、小产品，就容易形成实现微服务架构所需的自治性组织文化。

1.消除过程浪费

软件行业大多数产品开发由时间和成本决定其投入，即一定数量的开发人员通过一定时间的开发工作完成某个具体产品。显然，开发周期的缩短同样意味着开发成本的降低，因此开发成本与开发周期密切相关。产品开发周期时间与成本之间的关系如图1-12所示，可以看到开发时间和开发成本之间并不是一个简单的线性关系，随着开发时间的增长，开发成本增长的趋势越来越明显。出现这样的情况是因为软件开发过程中对范围变更的控制、计划的监控、资源的合理安排都存在风险，且风险随时间演变其发生的概率和造成的影响就越大。图1-12所示的就是技术管理面临的一个重要课题，即对于范围已经固定的产品开发任务而言，如何提高开发效率以降低开发时间和成本。

建立高效的研发过程体系可以提高开发效率，通过提高开发效率而节省下来的资源可以再投入到新产品的开发中去，从而使更多的新产品投向市场，或者减少新产品开发的总体成本。对于软件开发这个特定行业而言，减少浪费是提高开发效率的首要切入点。浪费分成纯粹的浪费和必要的浪费，其中纯粹的浪费需要消除，而必要的浪费可以进行压缩[2]。

微服务架构的技术特征决定了开发各自微服务的团队之间只需要进行较少的协调工作，这为降低研发过程浪费提供了基础。从组织管理的角度出发，自治性团队较之集中式管理模式下的团队在团队建立和发展上能够得到更好的可扩展性。集中式团队普遍受限于技术上的约束和决策，诸如可用性、性能等非功能性需求都不是由某个业务功能和系统的独立团队所负责，而是需要集中式的、系统级别的实现和管理。微服务架构可以把大型团队打散成小型团队，而小型团队比大型团队具有更低的失败可能性。从这点上，微服务架构还能够降低团队组织级别的风险。

另一方面，软件团队中时常会出现所谓的“扯皮现象”。这是一种明显的过程浪费，该现象的产生原因在于不清晰的边界。微服务架构的一大特征就是根据业务来组建团队，某个特定业务局限于某个微服务中并由独立团队负责所有相关事宜。明确的边界有助于减少团队之间的扯皮现象，从而提升开发效率。

2.快速产品开发

在互联网行业中，时机可能比任何其他因素更为重要。在一些行业中，市场机会窗只会开放很短的一段时间。在这种背景下，产品能不能成功在很大程度上取决于产品投放市场的时间。如果在同等产品规划和运营策略下，也即在相同的业务创新条件下，技术创新就会成为影响产品成功的决定性因素。技术创新能够在改善产品用户体验和缩短产品研发生命周期上提升产品成功的概率，如图1-13所示，通过缩短开发时间从而快速推出新产品能带来产品收益上的增长，而对于互联网产品而言，很多时候错过产品发布时机就意味着再也没有机会。

微服务架构从技术角度给出了缩短产品开发周期的方法，主要表现在并行的开发模式上。将业务拆分成各个微服务能够让不同的业务功能处于一种并行开发的状态，因为每个团队所负责的业务需求只影响到团队自身的微服务，所以各个团队能够独立开发，整个系统也很容易分布到各个团队中。如果涉及简单业务需求的变更或者是发布部署的要求，独立的微服务之间也不需要太多的统一协调工作。大规模的统一协调工作通常只发生在业务结构产生重大变更的场景，而这种场景对于软件开发而言显然是应该尽量避免并进行提前规划。