這部分布式事務開山之作，憑啥第一天預售就拿下當當新書榜No.1？

大家好，我是冰河~~

今天，咱們就暫時不聊【精通高并發系列】了，今天插播一下分布式事務，為啥？因為冰河聯合貓大人共同創作的分布式事務領域的開山之作——《深入理解分布式事務：原理與實戰》一書正式出版了，于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.多服務訪問單資料庫

多個微服務訪問同一個資料庫，例如，訂單微服務和交易微服務訪問同一個資料庫就會產生分布式事務，原因是多個微服務訪問同一個資料庫，本質上也是通過不同的資料庫會話來操作資料庫，此時就會產生分布式事務，商城系統中多服務訪問單資料庫產生分布式事務的場景如下圖所示，

跨資料庫實體場景和多服務訪問單資料庫場景，在本質上都會產生不同的資料庫會話來操作資料庫中的資料，進而產生分布式事務，這兩種場景是比較容易被忽略的，

寫在最后

為了讓小伙伴們更好的了解本書，在文章最后冰河附上幾張精美的圖片，

哈哈，喜歡的小伙伴當當下單即可，有啥問題可以私信冰河咨詢，冰河看到后都會一一解答，

好了，今天就到這兒吧，我是冰河，我們下期見~~