导读：随着互联网的不断发展，企业积累的数据越来越多。当单台数据库难以存储海量数据时，人们便开始探索如何将这些数据分散地存储到多台服务器的多台数据库中，逐渐形成了分布式数据库。如果将数据分散存储，对于数据的增删改查操作就会变得更加复杂，尤其是难以保证数据的一致性问题，这就涉及了常说的分布式事务。

 

本文对分布式事务的基本概念进行介绍，涉及的内容如下。

·分布式系统架构原则。

·分布式系统架构演进。

·分布式事务场景。

 

01分布式系统架构

随着互联网的快速发展，传统的单体系统架构已不能满足海量用户的需求。于是，更多的互联网企业开始对原有系统进行改造和升级，将用户产生的大规模流量进行分解，分而治之，在不同的服务器上为用户提供服务，以满足用户的需求。慢慢地，由原来的单体系统架构演变为分布式系统架构。

1、产生的背景

在互联网早期，互联网企业的业务并不是很复杂，用户量也不大，一般使用单体系统架构快速实现业务。此时，系统处理的流量入口更多来自PC端。

随着用户量爆发式增长，此时的流量入口不再只有PC端，更多来自移动端App、H5、微信小程序、自主终端机、各种物联网设备和网络爬虫等。用户和企业的需求也开始变得越来越复杂。在不断迭代升级的过程中，单体系统变得越来越臃肿，系统的业务也变得越来越复杂，甚至难以维护。修改一个很小的功能可能会导致整个系统的变动，并且系统需要经过严格测试才能上线，一个很小的功能就要发布整个系统，直接影响了系统中其他业务的稳定性与可用性。

此时开发效率低下，升级和维护系统成本很高，测试周期越来越长，代码的冲突率也会变得越来越高。最让人头疼的是，一旦有开发人员离职，新入职的人需要很长的时间来熟悉整个系统。单体系统架构已经无法支撑大流量和高并发的场景。

面对单体系统架构的种种问题，解决方案是对复杂、臃肿的系统进行水平拆分，把共用的业务封装成独立的服务，供其他业务调用，把各相关业务封装成子系统并提供接口，供其他系统或外界调用，以此达到降低代码耦合度，提高代码复用率的目的。此时，由于各个子系统之间进行了解耦，因此对每个子系统内部的修改不会影响其他子系统的稳定性。这样一来降低了系统的维护和发布成本，测试时也不需要把整个系统再重新测试一遍，提高了测试效率。在代码维护上，各个子系统的代码单独管理，降低了代码的冲突率，提高了系统的研发效率。

 

2、架构目标和架构原则

好的分布式系统架构并不是一蹴而就的，而是随着企业和用户的需求不断迭代演进的，能够解决分布式系统当前最主要的矛盾，同时对未来做出基本的预测，使得系统架构具备高并发、高可用、高可扩展性、高可维护性等非功能性需求，能够快速迭代，以适应不断变化的需求。

分布式系统架构的设计虽然比较复杂，但是也有一些业界遵循的原则。其中一些典型的架构原则来自The Art of Scalability一书，作者马丁L.阿伯特和迈克尔T.费舍尔分别是eBay和PayPal的CTO。他们在书中总结了15项架构原则，分别如下所示。

·N + 1设计。

·回滚设计。

·禁用设计。

·监控设计。

·设计多活数据中心。

·使用成熟的技术。

·异步设计。

·无状态系统。

·水平扩展而非垂直升级。

·设计时至少要有两步前瞻性。

·非核心则购买。

·使用商品化硬件。

·小构建、小发布和快试错。

·隔离故障。

·自动化。

 

 

02分布式系统架构演进

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

 

1、单体应用架构

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

图1　单体应用系统架构

 

这种架构的优点如下。

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

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

 

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

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

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

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

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

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

 

2、垂直应用架构

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

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

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

图2　垂直应用系统架构

 

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

 

这种架构的优点如下。

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

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

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

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

 

这种架构的缺点如下。

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

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

 

 

3、分布式架构

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

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

                                                                

图3　分布式系统架构

 

这种架构的优点如下。

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

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

 

这种架构的缺点如下。

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

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

3）系统维护成本高。

 

4、SOA架构

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

 

图4　SOA系统架构

 

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

 

这种架构的缺点如下。

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

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

 

5、微服务架构

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

这种架构的优点如下。

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

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

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

 

图5　微服务系统架构图

这种架构的缺点如下。

1）开发成本比较高。

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

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

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

 

 

03分布式事务场景

 

将一个大的应用系统拆分为多个可以独立部署的应用服务，需要各个服务远程协作才能完成某些事务操作，这就涉及分布式事务的问题。总的来讲，分布式事务会在3种场景下产生，分别是跨JVM进程、跨数据库实例和多服务访问单数据库。

 

1、跨JVM进程

将单体项目拆分为分布式、微服务项目之后，各个服务之间通过远程REST或者RPC调用来协同完成业务操作。典型的场景是商城系统的订单微服务和库存微服务，用户在下单时会访问订单微服务。订单微服务在生成订单记录时，会调用库存微服务来扣减库存。各个微服务部署在不同的JVM进程中，此时会产生因跨JVM进程而导致的分布式事务问题。商城系统中跨JVM进程产生分布式事务的场景如图6所示。

                                                               

图6　商城系统中跨JVM进程产生分布式事务场景

 

 

2、跨数据库实例

 

单体系统访问多个数据库实例，也就是跨数据源访问时会产生分布式事务。例如，系统中的订单数据库和交易数据库放在不同的数据库实例中，当用户发起退款时，会同时操作用户的订单数据库和交易数据库（在交易数据库中执行退款操作，在订单数据库中将订单的状态变更为已退款）。由于数据分布在不同的数据库实例中，需要通过不同的数据库连接会话来操作数据库中的数据，因此产生了分布式事务。商城系统中跨数据库实例产生分布式事务场景如图7所示。

图7　商城系统中跨数据库实例产生分布式事务场景

 

 

3、多服务访问单数据库

 

多个微服务访问同一个数据库，例如，订单微服务和交易微服务访问同一个数据库就会产生分布式事务，原因是多个微服务访问同一个数据库，本质上也是通过不同的数据库会话来操作数据库，此时就会产生分布式事务。商城系统中多服务访问单数据库产生分布式事务的场景如图8所示。

图8　商城系统中多服务访问单数据库产生分布式事务的场景

 

跨数据库实例场景和多服务访问单数据库场景，在本质上都会产生不同的数据库会话来操作数据库中的数据，进而产生分布式事务。这两种场景是比较容易被忽略的。

 

 

- END -

 

本书摘编自《深入理解分布式事务：原理与实践》，经出版方授权发布。

 

推荐语：本书的广度与深度兼备、理论与实战兼顾的分布式事务专著，它从基础知识、解决方案、原理分析、源码实现、工程实战5个维度对分布式事务做了全面、细致的讲解，试图解决你在实践中遇到的所有关于分布式事务的问题。

 

作者简介：

肖宇
分布式事务架构专家，Apache ShenYu（incubating）网关创始人，Dromara开源组织创始人，Hmily、RainCat、Myth等分布式事务框架的作者，Apache ShardingSphere提交者。
热爱开源，追求优雅代码。有丰富的微服务架构经验，尤其擅长微服务技术栈中的分布式事务、微服务架构、分布式数据库、API网关等解决方案。

冰河
互联网高级技术专家、MySQL技术专家、分布式事务架构专家。
多年来，一直致力于分布式系统架构、微服务、分布式数据库、分布式事务与大数据技术的研究，在高并发、高可用、高可扩展性、高可维护性和大数据等领域拥有丰富的架构经验。