4.2　分布式系统架构演进

互联网企业的业务飞速发展，促使系统架构不断变化。总体来说，系统架构大致经历了单体应用架构—垂直应用架构—分布式架构—SOA架构—微服务架构的演变，很多互联网企业的系统架构已经向服务化网格（Service Mesh）演变。接下来简单介绍一下系统架构的发展历程。

4.2.1　单体应用架构

在企业发展的初期，一般公司的网站流量比较小，只需要一个应用将所有的功能代码打包成一个服务并部署到服务器上，就能支撑公司的业务需求。这种方式能够减少开发、部署和维护的成本。比如大家很熟悉的电商系统，里面涉及的业务主要有用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等模块。企业发展初期，我们将所有的模块写到一个Web项目中，再统一部署到一个Web服务器中，这就是单体应用架构，系统架构如图4-1所示。

图4-1　单体应用系统架构

这种架构的优点如下。

1）架构简单，项目开发和维护成本低。

2）所有项目模块部署在一起，对于小型项目来说，方便维护。

但是，其缺点也是比较明显的。

1）所有模块耦合在一起，对于大型项目来说，不易开发和维护。

2）项目各模块之间过于耦合，一旦有模块出现问题，整个项目将不可用。

3）无法针对某个具体模块来提升性能。

4）无法对项目进行水平扩展。

正是由于单体应用架构存在诸多缺点，才逐渐演变为垂直应用架构。

4.2.2　垂直应用架构

随着企业业务的不断发展，单节点的单体应用无法满足业务需求。于是，企业将单体应用部署多份，分别放在不同的服务器上。然而，不是所有的模块都有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升，对于单体应用来说，是做不到的。于是，垂直应用架构诞生了。

垂直应用架构就是将原来的项目应用拆分为互不相干的几个应用，以此提升系统的整体性能。

同样以电商系统为例，在垂直应用架构下，我们可以将整个电商项目拆分为电商交易系统、后台管理系统、数据分析系统，系统架构如图4-2所示。

图4-2　垂直应用系统架构

将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，只需要针对访问量大的业务增加服务器节点，无须针对整个项目增加服务器节点。

这种架构的优点如下。

1）对系统进行拆分，可根据不同系统的访问情况，有针对性地进行优化。

2）能够实现应用的水平扩展。

3）各系统能够分担整体访问流量，解决了并发问题。

4）子系统发生故障，不影响其他子系统的运行情况，提高了整体的容错率。

这种架构的缺点如下。

1）拆分后的各系统之间相对独立，无法进行互相调用。

2）各系统难免存在重叠的业务，会存在重复开发的业务，后期维护比较困难。

4.2.3　分布式架构

将系统演变为垂直应用架构之后，当垂直应用越来越多时，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务，供其他系统或者业务模块调用，这就是分布式架构。

在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。分布式系统架构如图4-3所示。

图4-3　分布式系统架构

这种架构的优点如下。

1）将重复的业务代码抽象出来，形成公共的访问服务，提高了代码的复用性。

2）可以有针对性地对系统和服务进行性能优化，以提升整体的访问性能。

这种架构的缺点如下。

1）系统之间的调用关系变得复杂。

2）系统之间的依赖关系变得复杂。

3）系统维护成本高。

4.2.4　SOA架构

在分布式架构下，当部署的服务越来越多时，重复的代码就会变得越来越多，不利于代码的复用和系统维护。为此，我们需要增加一个统一的调度中心对集群进行实时管理，这就是SOA（面向服务）架构。SOA系统架构如图4-4所示。

图4-4　SOA系统架构

这种架构的优点是通过注册中心解决了各个服务之间服务依赖和调用关系的自动注册与发现。

这种架构的缺点如下。

1）各服务之间存在依赖关系，如果某个服务出现故障，可能会造成服务器崩溃。

2）服务之间的依赖与调用关系复杂，增加了测试和运维的成本。

4.2.5　微服务架构

微服务架构是在SOA架构的基础上进行进一步的扩展和拆分。在微服务架构下，一个大的项目拆分为一个个小的可独立部署的微服务，每个微服务都有自己的数据库。微服务系统架构如图4-5所示。

这种架构的优点如下。

1）服务彻底拆分，各服务独立打包、独立部署和独立升级。

2）每个微服务负责的业务比较清晰，利于后期扩展和维护。

3）微服务之间可以采用REST和RPC协议进行通信。

图4-5　微服务系统架构图

这种架构的缺点如下。

1）开发成本比较高。

2）涉及各服务的容错性问题。

3）涉及数据的一致性问题。

4）涉及分布式事务问题。