分布式架构设计一（架构演变历程）

分布式微服务架构是当下各大企业使用最为广泛的架构方式，如阿里巴巴、腾讯、京东、美团、百度等都在使用。微服务架构能够解决企业中的各种实际问题，提高系统开发效率，达到快速迭代的目的，因此备受青睐。

微服务架构是由单体架构、集群架构、SOA架构、ESB架构一步步地演变而来的，是软件行业通过多年的经验总结而得出的一种解决方案。随着互联网行业的蓬勃发展，微服务架构也逐渐走上了它的光辉时刻。

微服务架构的实现涉及众多的组件，包括注册中心、配置中心、熔断机制、负载均衡、服务网关、服务监控、链路追踪、日志收集等。每种组件都有其重要作用，它们之间相互配合，使得微服务架构系统成为一种具有高度服务自治能力的系统。

本章将详细介绍架构的演变过程和原理，以及每个微服务组件的原理和功能。

3.1 单体架构

在软件行业发展初期，一般会将所有前后端程序都放在一个包中，没有太多分层的概念，运行在一个容器中，每个系统更像是一个单机软件。这种方式足够简单，安装部署方便。但是，程序越来越臃肿，牵一发而动全身，有些超大的单体架构系统启动一次甚至需要几十分钟，单体架构其实根本谈不上是一种架构。

MVC思想引入了视图（Model）、模型（View）、控制器

（Controller）的分层理论，随着Struts、Spring MVC等框架的演变，以及前后端分离技术的不断发展，产生了一种全新的开发模式，使应用层次更加分明，降低了耦合度，提高了重用性。但随着系统的规模和复杂度不断提升，代码不断加入，单体架构的维护依然十分困难。单体架构的演变过程如图3-1所示。

图3-1 单体架构的演变过程

单体架构的优缺点如图3-2所示。

图3-2 单体架构的优缺点

1. 单体架构的优点（1）部署简单：分布式微服务架构需要部署大量的服务器节点，而单体架构只需要启动几台服务器做负载集群架构即可。单体架构适合开发传统中小型信息管理系统、工具类产品，可充分利用其开发速度快、实施简单的优势。

（2）无系统交互损耗：由于单体架构不存在服务之间的相互调用，因此不存在交互损耗，同等条件下具有更快的响应速度。

2. 单体架构的缺点

（1）形成信息孤岛：单体架构也称为烟囱架构，大多数企业的早期系统都是独立构建的，由多个厂商或团队负责开发，没有过多的长期规划，它们之前没有相互联系，数据和服务无法共享，成为一个个信息孤岛，每个系统就像一根烟囱矗立在那里，相互之间没有任何关联，如图3-3所示。

图3-3 烟囱式架构形成信息孤岛

公司的客户数据、销售数据、商品数据、财务数据都相互独立。例如，销售系统、进销存系统中都有自己的一套用户、一套产品、一套库存管理，不但有大量的重复工作，而且经常出现系统间数据不一致的问题，如销售系统记录成功销售了100件商品，而进销存系统中记录出库了200件商品。系统之间的信息传递往往要依靠大量的数据录入、导出、导入来完成，不仅效率低，差错率也极高。（2）项目臃肿：以Java项目为例，其往往将所有功能打包在一个

WAR包中，在一个JVM（Java虚拟机）进程上运行。随着功能的增

加，代码量不断上升，WAR包甚至达到几百兆字节，启动速度缓慢。

（3）     多团队协作困难：不同的团队负责不同的功能模块，造成项目分支泛滥，代码冲突增加，每次系统发布都蕴含着极大的风险。

（4）     故障难以隔离：一个项目中包含所有业务模块，这些模块中有不经常变动的核心功能，也有经常要修改的非核心功能。经常会因为一个小小的改动而导致整个系统故障。

（5）     服务器配置要求高：由于所有功能都聚合在一起，承载各种各样的业务请求，随着业务的增长，系统功能也在不断地增多，因此对硬件资源的要求也在不断地提高。

（6）     难以按需扩容：一个系统内并非所有的模块都被频繁使用，例如，在电商大促期间，订单服务、商品服务需要大量扩容，而用户信息管理、地址管理并不需要扩容。而单体架构必须全部功能扩容，而且服务器配置要求较高，整体成本较高。

3.2 SOA架构

为了解决单体架构所带来的诸多问题，SOA（Service-Oriented

Architecture，面向服务的架构）应运而生。SOA是一种粗粒度、松耦合的服务架构，可以有效地将各个系统联系起来，从而实现信息互通、数据共享，进行有效的业务组合和编排，可以对外提供聚合服务，通过服务协作可以完成更为复杂的业务流程，是一种天然的分布式架构。SOA架构如图3-4所示，图中不同连线代表不同的交互方式。

图3-4 SOA架构

SOA是一种极佳的架构模式，然而很多公司却在SOA落地过程中发生了偏差，尤其是ESB（Enterprise Service Bus，企业服务总线）的

出现，导致了人们的思维固化，甚至将ESB和SOA架构画上了等号，认为ESB架构就是SOA的最佳实践，笔者对这种观点是持反对态度的。

ESB极大地拉低了SOA的定位，阻碍了SOA架构的发展。

企业内的各个服务可能是由不同的公司、不同的团队开发的，可能使用了不同的开发语言、不同的部署模式，想要让这些系统可以更好地协作，就必须达到统一的交互标准。让所有系统都采用相同的传输协议，报文格式当然最好，对长远发展也十分有利，但是这样所有系统就都必须进行大量的改造，成本极高。

ESB架构的提出很好地解决了这个问题。ESB作为所有系统的中转中心，提供报文格式转换、协议转换、加解密、安全认证、日志记录、监控、统计、服务发现、服务路由等功能，如图3-5所示。

图3-5 ESB架构

如图3-6所示，服务A、B都访问服务C，而服务C只提供了

RPC+XML的访问方式。服务A、B通过HTTP+JSON的形式访问ESB，由ESB负责协议和交互报文的转换，从而达到服务C无须任何修改即可兼容的目的，ESB充当了代理和适配器的角色。

图3-6 ESB架构服务访问

对于企业内的大多数系统由不同的供应商开发，均采用烟囱式架构的情况，为了避免所有系统都进行改造，采用ESB架构是一种成本更低、更加行之有效的改造方案。但需要注意的是，ESB架构不等同于

SOA架构，ESB最大的问题是让原本去中心化的系统又变为了中心化的系统，一旦ESB出现故障就会导致整个系统不可用，所以一定要对ESB 进行冗余部署，避免出现单节点故障。

有些企业也将ESB系统称为开放平台，统一管理各个系统之间的开放API，起到了服务注册与发现的作用。

3.3 微服务架构

微服务架构是SOA架构的延伸，可以粗浅地认为微服务架构是更细粒度的SOA架构。SOA架构中一般将一个业务系统作为一个服务，粒度较粗，关注点在系统集成。而微服务架构的思想是将业务系统进行彻底的组件化和服务化，将一个业务系统拆分为多个相互协作、相互独立的应用，单独开放、单独部署，均可以对外提供服务，关注点在系统分离。

单体架构向SOA架构的演变如图3-7所示。电商系统早期是一个单体架构，一个服务中包含了用户模块、订单模块、产品模块、库存模块、积分模块。经过服务拆分演变为SOA架构（由于ESB架构是SOA架构的典型代表，因此下例均使用ESB架构指代SOA架构），将每个模块独立为用户服务、订单服务、产品服务、库存服务、积分服务。

图3-7 单体架构向SOA架构的演变

SOA架构向微服务架构的演变如图3-8所示。SOA架构经过更细粒度的服务拆分，将用户服务拆分为用户注册服务、用户登录服务，将订单服务拆分为订单创建服务、订单查询服务、订单支付服务，将库存服务拆分为入库服务、出库服务，将商品服务拆分为商品上架服务、商品下架服务，将积分服务拆分为积分计算服务、积分扣减服务。通过多个服务之间的相互协作完成业务流程。

图3-8 SOA架构向微服务架构的演变

服务拆分之后职责更加单一化、边界更小、耦合度更低、服务复用率更高，并且能够达到快速按需扩容的目的。例如，在电商大促期间，可以预估订单创建服务、商品上/下架服务、积分计算服务将成为热点服务（被频繁访问的服务），那么就可以有针对性地对这些服务进行扩容，业务低峰期再将资源回收即可。

微服务架构的优缺点如图3-9所示。

图3-9 微服务架构的优缺点

1.微服务架构的优点

（1）     分布式去中心化：微服务是天然的去中心化分布式架构，具有分布式架构的优点，如易于开发、吞吐量高、易于扩展等。

（2）     服务伸缩性更好：去中心化可以有效地避免系统瓶颈，同时微服务采用无状态开发，具有良好的水平扩展能力，借助服务注册机制可以随时新增和删除节点，为系统带来更好的伸缩性。

（3）     服务自治能力：微服务能够通过服务注册与发现、配置中心、熔断、限流、负载、链路追踪等多种手段实现自我治理，根据服务的状态对自身架构动态调整，从而保证系统的可用性。

（4）     服务内聚更高，耦合更低：由于拆分粒度降低，因此服务更专注于某个领域的职能，边界更加清晰，服务之间相互协作完成复杂的业务，耦合性更低。

（5）     敏捷开发：服务更易于开发，开发人员更专注于某个具体的功能服务，不会陷入复杂的交易流程中，降低了开发的复杂度，项目迭代周期更短，是天然的敏捷开发架构。

（6）     异构开发：对于不同的业务场景可能需要使用不同的开发语言，如Python、Go、Node.js等，也可能使用不同的数据库，如 MySQL、Oracle、MongoDB等，根据不同的需求选用不同的技术，各个服务之间使用统一的交互方式即可。

（7）     对硬件要求降低：从原来的重服务变为了轻服务，负责的职能小而单一，因此对服务器配置的要求降低，配合弹性伸缩扩容，可以有效地降低硬件投入成本。

2.微服务架构的缺点

（1）     拆分粒度难以界定：服务到底应该拆到多细、按照什么原则去拆是没有统一的标准和原则的，尤其是对于数据库的拆分则更是难上加难，一旦拆分又会面临复杂的分布式数据问题。

（2）     增加了运维难度：原来的10个服务可能变为100个微服务，怎样发布、测试、运维就变得十分困难。随着DevOps、Docker容器化、持续集成技术的发展，这个问题已经有了较好的解决方案。

（3）     交易流程变得复杂：原来的一个业务请求只需要在一个服务内部完成（单体架构），或者三四个服务协作完成（SOA架构）。而微服务架构可能需要更多的服务相互协作才能完成，由于交易链条变长，因此复杂度也随之升高。

（4）     网络延迟增加：微服务采用HTTP、RPC远程调用的方式，因此网络延迟增加。

微服务之间的通信方式主要分为HTTP和RPC，代表性框架分别是阿里巴巴Dubbo框架和Spring Cloud框架。

在分布式架构中有一个非常重要的概念是服务自治，要求服务必须具有一定的自我管控、自我治理的能力，应该能够自动发现新的服务、自动剔除故障服务、自动进行请求负载、自动熔断、自动降级保护、自动监控服务的健康状态等。一个完整的微服务必须包括以下十项重要设计，如图3-10所示。

图3-10 微服务的十项重要设计