转载

【大咖连载】微服务架构的本质

作者| 王磊马博文张琦

本文节选自《微服务架构与实践（第二版）》

【大咖连载】微服务架构的本质

“小、独、轻、松”帮助我们理解了服务在设计、运行和部署时，同以前我们熟知的单体应用的差别。但从落地的角度而言，是不是理解了如上的概念就足够了？

笔者在过去几年探索微服务的过程中，发现如果只是依托于如上的概念来理解并落地微服务，是不够的。因为它无法促使我们从更大规模、更长远的角度去思考，如何有效地、系统化地构建未来五年，甚至是十年以上，具有竞争力的服务化架构系统。

对于一些大型组织（尤其是传统行业），拥有成百上千的微服务后，会面临哪些挑战？是个体能力的提升，组织的差异化发展，还是流程的动态演进？
我们常说，天下大势，分久必合，合久必分，经历了松散的、细粒度的微服务架构演进，未来是否还需要标准化和统一化？
如果标准化，是否从某种程度上违背了微服务的初衷？微服务概念的诞生，不是为了提升应对复杂系统，基于分而治之的思想并去中心化的演进吗？
作为服务化团队的成员，在框架、工具百花齐放、层出不穷的今天，如果更换另一个团队，如何降低上手成本？当服务数量激增后，需要专业的 QA/Ops/SRE ，是否能找到足够多的这样资深的专业人员？
任何时候，资源都不是免费的。当有成千上万的服务时，资源如何分配？哪个服务的优先级更高？哪个团队应该更优先获得更优质的资源（包括但不限于优秀的工程师、费用、软件、硬件等）。
在过去几年中，微服务架构经历了快速的发展，在帮助很多组织解决了系统的伸缩性、灵活性，以及快速响应的问题后，下一个阶段的挑战在哪里？它是当前的架构权宜之计，还是一劳永逸？

对于如上的开放性问题，很难有完美的答案。笔者也希望实施微服务的读者，可以积极地思考这些问题。

结合笔者的经验，如果能从更深层次、系统化的角度理解和思考微服务，将能有效地帮助我们应对如上所述的挑战，持续地演进架构，并做到事半功倍。

而所谓的深层次、系统化的部分，笔者将其归纳为如下三点：以缩短交付周期为核心、基于 DevOps 、演进式架构，并将其作为本书中微服务架构的本质。

【大咖连载】微服务架构的本质

以缩短交付周期为核心

2010 年， Jez Humble 在其《持续交付》一书中曾明确提到，未来的软件交付一定会满足如下特征：

更快的上线（ Faster time to market ）
更低的发布风险（ Lower risk release ）
更高的质量（ Higher quality ）
更低的成本（ Lower costs ）
更好的产品（ Better products ）

为了实现这个目标，在《持续交付》中， Jez 定义了一个相对成熟的流程，包括了需求分析、开发、测试、部署以及上线后获取用户反馈和监控运维的机制。同时，在落地的过程中，他也提出了持续交付落地过程中涉及的七个维度：

持续集成 / 部署
内建质量
环境管理
数据管理
松耦合架构
组织协同
反馈验证

在过去的数年间，大部分组织都在围绕着持续交付，构建如何快速应对市场变化的响应能力。而在落地的过程中，这些组织也在如上的多个维度上投入并产生了不错的效果。譬如：

在持续集成 / 部署方面，将代码检查、构建、测试、部署等都围绕流水线构建。
在内建质量方面，基于测试金字塔，构建分层测试的策略，将质量内建在开发过程中。
在环境管理方面，定义不同的环境，如开发、测试、类生产以及生产环境，以便快速获取不同角色对软件特性的反馈。
在数据管理方面，采用 Flyway 、 Liqubase 等工具版本化管理 Schema 以及数据。
在组织协同方面，培养全功能团队以及相应的敏捷实践。
在反馈验证方面，构建多种途径的数据监控、收集与反馈机制。

基于这些方面的改进，交付周期得到了大幅的缩短，质量也得到了显著提升。随着如上这些维度的实践逐渐成熟，它们对缩短交付周期、提升交付质量的贡献与改进空间越来越小，即投入产出比越来越小。那如何继续有效地缩短交付周期，提升交付效率呢？

如果认真思考，你会发现虽然持续交付中定义了松耦合架构这个维度，但在过去的多年间，整个 IT 业界在架构方面并没有显著的变化。组件化、 SOA 、分层架构，几乎还是原来的方式。一个主要原因是，在持续交付的初期，架构不是主要矛盾，持续集成 / 部署、自动化测试、环境管理等带来的价值会很明显。而另外一个主要原因是，架构解耦导致的影响较大和成本太高。

随着持续交付理念被更多组织接受，环境、质量、持续集成、部署等实践的逐渐成熟，架构解耦成了继续做好持续交付所必须面对的挑战。此时，业界才开始将更多的关注点放在架构解耦上，继续缩短交付周期，提升交付质量和效率。

因此，微服务架构的本质是持续交付体系中松耦合架构的一种实现。通过微服务的独立开发、测试、部署和维护能力，缩短特性的交付周期，提升交付质量。同时降低管理、测试、部署等的难度。

【大咖连载】微服务架构的本质

基于DevOps

什么是DevOps：DevOps是指开发和运维一起参与到整个软件生命周期过程的实践——从开发、测试、部署上线到维护。

——The Agile Admin

如果我们将软件交付的过程看成是价值交付的过程，交付过程中的每个阶段，如开发、测试等，都为软件创造了价值 — —特性实现、验证等。只有在部署的过程中，没有价值产生。

在传统的 IT 组织中，运维部门和开发部门存在“部门墙”，沟通成本很高。同时，因为流程、服务相对较少的原因，运维看不到自动化的收益，往往采用手工的方式进行部署和运维。这会导致交付周期变长。此外，如图 1-12 所示，开发希望变更后更快上线，部署频率更高，而执行部署的运维出于稳定和维护成本考虑，倾向于更少的部署。在微服务架构下，如在服务数量增加的同时，还要求快速上线、流畅交付，则传统的运维方式无法满足这样的需求。

【大咖连载】微服务架构的本质

图 1-12 Dev VS Ops

2009 年， Flickr 通过加强开发和运维之间的沟通、实施自动化部署，实现了每天 10 次的生产环境部署，这在当时是令人震惊的。越来越多的类似案例，证明了通过打破开发和运维的部门墙，加强他们的协作，引入基础设施，如代码、蓝绿部署等良好的工程实践，可以大幅降低部署阶段的成本以及缩短交付周期。这也就是我们今天所提到的 DevOps ，只是现在的理论和实践要更加丰富。

DevOps 的核心在于通过加强交流、自动化等来提升部署频率，降低部署时间，让变更能更快、更安全的上线，以及降低在服务数量增加时的维护成本。它是实现持续交付的关键，也是保证微服务数量增长时也能快速上线的基础。

所以，在微服务场景下，服务数量的快速增长决定我们无法再通过传统运维的形式来保证服务安全快速上线。只有引入 DevOps 实践，解决在交付过程中浪费时间的问题，才能实现服务的快速、流畅交付。

【大咖连载】微服务架构的本质

演进式架构

在过去十年中，越来越多的组织已经尝试并认可敏捷方法论及其实践。敏捷方法论正在帮助组织以拥抱变化的心态，不断尝试，不断获取反馈，从而以高效的方式构建正确的应用系统。实际上，敏捷并不是一种静止的状态，它是组织一直在拥抱变化、尝试改变、获取反馈的演进式发展的一个动态过程。

同样，架构设计也应该是随着业务的发展而不断发展，随着需求的变化而不断变化的。

在传统的单体架构设计中，企业或者组织通常是希望通过构建一个大而全、无所不能的平台，解决所有问题。软件的交付周期长、瀑布流程根深蒂固、部署环境的变更成本高，导致这样的架构很难改变，无法适应需求的快速变化。同时，在技术发展日新月异的今天，也无法享受到新技术带来的好处和效率。

所谓演进式架构，是指在应用程序结构层面的多个维度（技术、数据、安全、领域等），将支持增量、持续的变更作为第一原则的架构。组织应该随着业务的发展，不断尝试并改进架构设计，真正做到业务驱动架构、架构服务于业务。好的架构也一定是演进出来的，而架构设计的本身也是一个持续演进的过程。

实际上，演进式架构的核心包括：

架构的动态平衡。架构始终要保持业务、技术和团队之间的动态平衡。
架构师的运维意识。架构只是抽象，是演进过程的快照，只有当架构真正上线后才能产生价值。由于软件世界在不断变化，架构师要通过运维体系、度量机制，不断地更新和演进架构。
痛苦的事情提前做。不断识别问题并用自动化的手段加以解决，比如通过持续集成、持续部署、基础设施即代码等方式减轻集成、部署的痛苦。改善这些痛苦的事情有助于架构增量变化的顺利进行。
架构的适应度（ Fitness ）。对于不同领域的产品，其架构关注的核心点不尽相同，如安全、性能、可靠性、可用性等，需要在演进的过程中识别优先级与重要性。

在微服务架构中，每个服务都是可独立交付的业务单元，具备独立的数据存储机制，技术上可以具备异构性。随着业务的快速发展和不断的变化，企业或者组织可以将不需要的服务（业务）抛弃，将有价值的服务（业务）升级，并采用合适的技术或者工具不断优化架构，保持其处于一个不断演进的状态。

【大咖连载】微服务架构的本质