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