用一個例項專案重新認識分散式系統

目錄

• 前言
• 背景
• 單機系統的弊病
• 嘗試分散式改造
• 為什麼要分散式
• 分散式系統特性
• 分散式系統的最大問題
• 寫在最後

前言

對於分散式系統的理解不能光停留在理論上，本文旨在通過一個實際的案例來闡述分散式系統框架的基本概念，起到拋磚引玉的效果。

背景

• 第一次提到分散式系統，應該還是十幾年前，當時的網際網路還沒有這麼火熱，相關的技術也沒有如今這樣成熟。
• 那是一個涉及銀行安全系統的整合專案，專案的需求主要是對企業使用者的票據加密與支付核驗服務，專案的難點在於：1、安全服務系統做為一個獨立的子系統 ，需要跟銀行現有支付後臺業務系統進行完美對接；2、系統整合後整個業務處理過程不會影響原有業務系統的效能。
• 當時的系統架構是這樣的：
  

單機系統的弊病

• 我們暫且不說銀行業務系統後臺那龐大的小型機叢集，只看專案整合的這套系統：這是一個典型的單機系統架構，該系統只做為一箇中間系統嵌入原有銀行系統框架中，系統使用C語言程式設計，與客戶端及介面通訊均採用底層Socket通訊。

1. 客戶端組織報文將資訊提交給支付密碼系統；
2. 支付密碼系統進行密碼核驗，得出核驗結果，並將核驗日誌儲存到資料庫中，儲存完成後將核驗結果與使用者報文轉交給銀行業務介面；
3. 銀行業務介面進行校驗，若核驗結果錯誤，則返回客戶端核驗錯誤資訊；若核驗成功，則交由後臺系統繼續業務處理過程。
4. 銀行業務後臺系統處理完畢，返回最終結果。

• 由於前期業務邏輯設計的不合理，支付密碼系統被錯誤地架在了客戶端與銀行支付後臺業務的中間；沒有管理功能，後臺管理只能通過配置檔案進行。
• 另外單機版的系統架構，遠遠達不到高可靠高效能的要求，系統一旦當機，銀行系統企業票據遠端支付業務就處於癱瘓狀態。

1. 應用服務與資料庫未分離，導致單機負載高；
2. 應用服務只能單機多程式運算不支援併發，更沒有負載均衡處理，導致業務堵塞。
3. 交易業務儲存依賴於關係型資料庫，且沒有快取處理技術，資料庫讀寫壓力大。
4. 底層通訊以BIO方式進行，通訊效率低下。
5. 日誌處理不支援非同步處理模式，搶佔系統資源。
6. ...

• 當然，這個專案還是上線了，付出的代價是把系統的伺服器進行了高配的升級，並加入了EMC的儲存，通過雙機熱備的方式來保證系統的高可用性；其次銀行在業務端也做了限制，每個銀行網點只允許一臺終端有許可權能處理該業務....
  

嘗試分散式改造

• 假設一下，如果我們通過現在成熟的中介軟體及框架對該系統進行分散式改造，應該怎麼做？
• 我覺得應該主要解決以下兩個問題：

1. 業務邏輯的合理性：業務功能分層並梳理出合理的業務邏輯是首要任務，（微服務拆分、中臺化管理其實說的也是這個道理）
2. 引入合適的分散式框架或中介軟體，解決一切單點的問題：比如分散式RPC框架、非同步訊息日誌系統、負載均衡機制等
   

為什麼要分散式

• 分散式架構與傳統的單機架構最大的區別在於分散式架構能解決兩個方向的擴充套件問題：一是橫向擴充套件，二是縱向擴充套件；

1. 橫向擴充套件：主要解決的是容量的擴充套件問題，不管單臺伺服器的效能多高，支撐的能力總是有上限的，所以我們在架構上必須能做到支援橫向擴容，即理論上隨著請求的無限增長，系統的容量也是具備無限增長的能力。比如：上述案例中交易系統的RPC介面與管理系統中的API介面都具備容量橫向擴充套件的能力。
2. 縱向擴充套件：主要解決的是業務的擴充套件問題。當業務擴充套件時，業務邏輯的複雜度也會不斷上升，所以在架構上需要根據功能定義進行縱向層次的劃分，且該功能層次劃分能符合業務快速迭代的要求。比如：上述案例中將系統功能縱向劃分為3次層次，RPC介面定義為與銀行交易系統互動的業務功能層次，API介面定義為與外部查詢與審計系統互動的業務功能層次，管理應用定義為後臺管理功能層次。

• 用一句話來概括：分散式系統目的就是能利用更多的機器，處理更多的業務與資料。
  

分散式系統特性

• 看了上面的案例，我們首先釐清了這樣一個概念：分散式系統不是一個專門面對網際網路的架構（雖然目前絕多大數的網際網路應用系統都是分散式甚至是微服務架構），那分散式架構的主要特性有哪些呢？

1. 透明性：使用者根本不會感知到這是一個分散式系統，對於使用者來說從請求到最終業務完成，是一個黑匣子。
2. 可擴充套件性：分散式系統具備橫向容量擴充套件、縱向業務擴充套件的能力。
3. 高效能：單位時間內處理的任務越多越好，每個任務步驟處理的平均時間越少越好。
4. 可用性：一般來說，分散式系統是需要長時間甚至7*24小時提供服務的，系統可用性需要達到99.999% 。

分散式系統的最大問題

分散式系統的最大問題，我們必須要深刻理解和牢記一點：分散式系統是不可靠的。 分散式系統中重要的理論和設計都是建立在分散式系統不可靠這一基礎上的，因為系統不可靠，所以我們需要增加一些額外的複雜設計和功能，來確保由於分散式系統的不可靠導致系統不可用性的概率降到最低。

分散式系統一般會引入冗餘機制，在任務執行序列中不管是主節點還是冗餘節點，都需要達到一致的狀態。比如：在上述案例中，交易系統呼叫核驗介面，如何保證所有核驗的節點的狀態一致性需要用到中介軟體進行解決。

寫在最後

• 前段時間讀了許多關於“分散式系統”的書及文章，有基礎理論的，有技術發展趨勢的，有實際案例解析的...，為了讓自己帶著思考，真正去了解這個概念，於是動手寫了這篇文章。
• 分散式系統解決問題的思路是早就有的，分散式系統也不僅侷限於網際網路行業的應用，我們把這個思想掌握了，研究透了，在遇到實際專案時才能從架構師的角度去解決問題。
• 很多Java程式設計師在初入學習分散式框架時，往往只對各種中介軟體進行生搬硬套，但真正掌握好計算機基礎知識，如作業系統、計算機網路，對學習分散式系統是大有益處的。
• 參考資料
  《大型網站系統與Java中介軟體實踐》
  《大型網站技術架構演示與效能優化》
  《架構解密：從分散式到微服務》
  《淘寶技術這十年》
  《什麼是分散式系統，如何學習分散式系統》