大家好，我是冰河~~
今天，我們們就暫時不聊【精通高併發系列】了，今天插播一下分散式事務，為啥？因為冰河聯合貓大人共同創作的分散式事務領域的開山之作——《深入理解分散式事務：原理與實戰》一書正式出版了，於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.多服務訪問單資料庫
多個微服務訪問同一個資料庫，例如，訂單微服務和交易微服務訪問同一個資料庫就會產生分散式事務，原因是多個微服務訪問同一個資料庫，本質上也是通過不同的資料庫會話來運算元據庫，此時就會產生分散式事務。商城系統中多服務訪問單資料庫產生分散式事務的場景如下圖所示。
跨資料庫例項場景和多服務訪問單資料庫場景，在本質上都會產生不同的資料庫會話來運算元據庫中的資料，進而產生分散式事務。這兩種場景是比較容易被忽略的。
寫在最後
為了讓小夥伴們更好的瞭解本書，在文章最後冰河附上幾張精美的圖片。
哈哈，喜歡的小夥伴噹噹下單即可，有啥問題可以私信冰河諮詢，冰河看到後都會一一解答。
好了，今天就到這兒吧，我是冰河，我們下期見~~