共计 4259 个字符，预计需要花费 11 分钟才能阅读完成。
大家好，我是冰河~~
明天，咱们就临时不聊【精通高并发系列】了，明天插播一下分布式事务，为啥？因为冰河联结猫小孩儿独特创作的分布式事务畛域的开山之作——《深刻了解分布式事务：原理与实战》一书正式出版了，于 2021 年 10 月 20 日开始在当当预售，当天即登上当当新书榜第一的地位！
划重点：当当 10.20~10.24 限时 5 折优惠！！关上当当首页，搜寻：分布式事务，找到 5 折优惠商品链接，点击加购，下单即可。
为了让小伙伴们更好的理解这本书的内容，咱们就简略的聊聊书中对于分布式系统架构和分布式事务产生的场景吧。好了，咱们开始明天的注释吧。
前言
随着互联网的一直倒退，企业积攒的数据越来越多。当单台数据库难以存储海量数据时，人们便开始摸索如何将这些数据扩散地存储到多台服务器的多台数据库中，逐步造成了分布式数据库。如果将数据扩散存储，对于数据的增删改查操作就会变得更加简单，尤其是难以保证数据的一致性问题，这就波及了常说的分布式事务。
本文对分布式事务的基本概念进行介绍，波及的内容如下。
- 分布式系统架构准则。
- 分布式系统架构演进。
- 分布式事务场景。
分布式系统架构
随着互联网的疾速倒退，传统的单体零碎架构已不能满足海量用户的需要。于是，更多的互联网企业开始对原有零碎进行革新和降级，将用户产生的大规模流量进行合成，分而治之，在不同的服务器上为用户提供服务，以满足用户的需要。缓缓地，由原来的单体零碎架构演变为 分布式系统架构。
1. 产生的背景
在互联网晚期，互联网企业的业务并不是很简单，用户量也不大，个别应用单体零碎架构疾速实现业务。此时，零碎解决的流量入口更多来自 PC 端。
随着用户量爆发式增长，此时的流量入口不再只有 PC 端，更多来自挪动端 App、H5、微信小程序、自主终端机、各种物联网设施和网络爬虫等。用户和企业的需要也开始变得越来越简单。在一直迭代降级的过程中，单体零碎变得越来越臃肿，零碎的业务也变得越来越简单，甚至难以保护。批改一个很小的性能可能会导致整个零碎的变动，并且零碎须要通过严格测试能力上线，一个很小的性能就要公布整个零碎，间接影响了零碎中其余业务的稳定性与可用性。
此时开发效率低下，降级和保护零碎老本很高，测试周期越来越长，代码的抵触率也会变得越来越高。最让人头疼的是，一旦有开发人员到职，新入职的人须要很长的工夫来相熟整个零碎。单体零碎架构曾经无奈撑持大流量和高并发的场景。
面对单体零碎架构的种种问题，解决方案是对简单、臃肿的零碎进行程度拆分，把共用的业务封装成独立的服务，供其余业务调用，把各相干业务封装成子系统并提供接口，供其余零碎或外界调用，以此达到升高代码耦合度，进步代码复用率的目标。
此时，因为各个子系统之间进行理解耦，因而对每个子系统外部的批改不会影响其余子系统的稳定性。这样一来升高了零碎的保护和公布老本，测试时也不须要把整个零碎再从新测试一遍，进步了测试效率。在代码保护上，各个子系统的代码独自治理，升高了代码的抵触率，进步了零碎的研发效率。
2. 架构指标和架构准则
好的分布式系统架构并不是欲速不达的，而是随着企业和用户的需要一直迭代演进的，可能解决分布式系统以后最次要的矛盾，同时对将来做出根本的预测，使得零碎架构具备高并发、高可用、高可扩展性、高可维护性等非功能性需要，可能疾速迭代，以适应一直变动的需要。
分布式系统架构的设计尽管比较复杂，然而也有一些业界遵循的准则。其中一些典型的架构准则来自 The Art of Scalability 一书，作者马丁 L. 阿伯特和迈克尔 T. 费舍尔别离是 eBay 和 PayPal 的 CTO。他们在书中总结了15 项架构准则，别离如下所示。
- N + 1 设计。
- 回滚设计。
- 禁用设计。
- 监控设计。
- 设计多活数据中心。
- 应用成熟的技术。
- 异步设计。
- 无状态零碎。
- 程度扩大而非垂直降级。
- 设计时至多要有两步前瞻性。
- 非核心则购买。
- 应用商品化硬件。
- 小构建、小公布和快试错。
- 隔离故障。
- 自动化。
分布式系统架构演进
互联网企业的业务飞速发展，促使零碎架构一直变动。总体来说，零碎架构大抵经验了 单体利用架构 — 垂直利用架构 — 分布式架构 —SOA 架构— 微服务架构 的演变，很多互联网企业的零碎架构曾经向 服务化网格（Service Mesh）演变。接下来简略介绍一下零碎架构的倒退历程。
1. 单体利用架构
在企业倒退的初期，个别公司的网站流量比拟小，只须要一个利用将所有的性能代码打包成一个服务并部署到服务器上，就能撑持公司的业务需要。这种形式可能缩小开发、部署和保护的老本。
比方大家很相熟的电商零碎，外面波及的业务次要有用户治理、商品治理、订单治理、领取治理、库存治理、物流治理等模块。企业倒退初期，咱们将所有的模块写到一个 Web 我的项目中，再对立部署到一个 Web 服务器中，这就是 单体利用架构，零碎架构如下图所示。
这种架构的 长处 如下。
1）架构简略，我的项目开发和保护成本低。
2）所有我的项目模块部署在一起，对于小型我的项目来说，不便保护。
然而，其 毛病 也是比拟显著的。
1）所有模块耦合在一起，对于大型项目来说，不易开发和保护。
2）我的项目各模块之间过于耦合，一旦有模块呈现问题，整个我的项目将不可用。
3）无奈针对某个具体模块来晋升性能。
4）无奈对我的项目进行程度扩大。
正是因为单体利用架构存在诸多毛病，才逐步演变为垂直利用架构。
2. 垂直利用架构
随着企业业务的一直倒退，单节点的单体利用无奈满足业务需要。于是，企业将单体利用部署多份，别离放在不同的服务器上。然而，不是所有的模块都有比拟大的访问量。如果想针对我的项目中的某些模块进行优化和性能晋升，对于单体利用来说，是做不到的。于是，垂直利用架构诞生了。
垂直利用架构 就是将原来的我的项目利用拆分为互不相干的几个利用，以此晋升零碎的整体性能。
同样以电商零碎为例，在垂直利用架构下，咱们能够将整个电商我的项目拆分为电商交易系统、后盾管理系统、数据分析系统，零碎架构如下图所示。
将单体利用架构拆分为垂直利用架构之后，一旦访问量变大，只须要针对访问量大的业务减少服务器节点，毋庸针对整个我的项目减少服务器节点。
这种架构的 长处 如下。
1）对系统进行拆分，可依据不同零碎的拜访状况，有针对性地进行优化。
2）可能实现利用的程度扩大。
3）各零碎可能分担整体拜访流量，解决了并发问题。
4）子系统产生故障，不影响其余子系统的运行状况，进步了整体的容错率。
这种架构的 毛病 如下。
1）拆分后的各零碎之间绝对独立，无奈进行相互调用。
2）各零碎不免存在重叠的业务，会存在反复开发的业务，前期保护比拟艰难。
3. 分布式架构
将零碎演变为垂直利用架构之后，当垂直利用越来越多时，反复编写的业务代码就会越来越多。此时，咱们须要将反复的代码形象进去，造成对立的服务，供其余零碎或者业务模块调用，这就是 分布式架构。
在分布式架构中，咱们会将零碎整体拆分为服务层和体现层。服务层封装了具体的业务逻辑供体现层调用，体现层则负责解决与页面的交互操作。分布式系统架构如下图所示。
这种架构的 长处 如下。
1）将反复的业务代码形象进去，造成公共的拜访服务，进步了代码的复用性。
2）能够有针对性地对系统和服务进行性能优化，以晋升整体的拜访性能。
这种架构的 毛病 如下。
1）零碎之间的调用关系变得复杂。
2）零碎之间的依赖关系变得复杂。
3）系统维护老本高。
4.SOA 架构
在分布式架构下，当部署的服务越来越多时，反复的代码就会变得越来越多，不利于代码的复用和系统维护。为此，咱们须要减少一个对立的调度核心对集群进行实时治理，这就是SOA（面向服务）架构。SOA 零碎架构如下图所示。
这种架构的 长处 是通过注册核心解决了各个服务之间服务依赖和调用关系的主动注册与发现。
这种架构的 毛病 如下。
1）各服务之间存在依赖关系，如果某个服务呈现故障，可能会造成服务器解体。
2）服务之间的依赖与调用关系简单，减少了测试和运维的老本。
5. 微服务架构
微服务架构 是在 SOA 架构的根底上进行进一步的扩大和拆分。在微服务架构下，一个大的我的项目拆分为一个个小的可独立部署的微服务，每个微服务都有本人的数据库。微服务零碎架构如下图所示。
这种架构的 长处 如下。
1）服务彻底拆分，各服务独立打包、独立部署和独立降级。
2）每个微服务负责的业务比拟清晰，利于前期扩大和保护。
3）微服务之间能够采纳 REST 和 RPC 协定进行通信。
这种架构的 毛病 如下。
1）开发成本比拟高。
2）波及各服务的容错性问题。
3）波及数据的一致性问题。
4）波及分布式事务问题。
分布式事务场景
将一个大的利用零碎拆分为多个能够独立部署的应用服务，须要各个服务近程合作能力实现某些事务操作，这就波及分布式事务的问题。总的来讲，分布式事务会在 3 种场景下产生，别离是跨 JVM 过程、跨数据库实例和多服务拜访单数据库。
1. 跨 JVM 过程
将单体我的项目拆分为分布式、微服务项目之后，各个服务之间通过近程 REST 或者 RPC 调用来协同实现业务操作。典型的场景是商城零碎的订单微服务和库存微服务，用户在下单时会拜访订单微服务。
订单微服务在生成订单记录时，会调用库存微服务来扣减库存。各个微服务部署在不同的 JVM 过程中，此时会产生因跨 JVM 过程而导致的分布式事务问题。商城零碎中跨 JVM 过程产生分布式事务的场景如下图所示。
2. 跨数据库实例
单体零碎拜访多个数据库实例，也就是跨数据源拜访时会产生分布式事务。例如，零碎中的订单数据库和交易数据库放在不同的数据库实例中，当用户发动退款时，会同时操作用户的订单数据库和交易数据库（在交易数据库中执行退款操作，在订单数据库中将订单的状态变更为已退款）。
因为数据分布在不同的数据库实例中，须要通过不同的数据库连贯会话来操作数据库中的数据，因而产生了分布式事务。商城零碎中跨数据库实例产生分布式事务场景如下图所示。
3. 多服务拜访单数据库
多个微服务拜访同一个数据库，例如，订单微服务和交易微服务拜访同一个数据库就会产生分布式事务，起因是多个微服务拜访同一个数据库，实质上也是通过不同的数据库会话来操作数据库，此时就会产生分布式事务。商城零碎中多服务拜访单数据库产生分布式事务的场景如下图所示。
跨数据库实例场景和多服务拜访单数据库场景，在实质上都会产生不同的数据库会话来操作数据库中的数据，进而产生分布式事务。这两种场景是比拟容易被疏忽的。
写在最初
为了让小伙伴们更好的理解本书，在文章最初冰河附上几张精美的图片。
哈哈，喜爱的小伙伴当当下单即可，有啥问题能够私信冰河征询，冰河看到后都会一一解答。
好了，明天就到这儿吧，我是冰河，咱们下期见~~
