用一個實例項目重新認識分佈式系統

前言

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

背景

• 第一次提到分佈式系統，應該還是十幾年前，當時的互聯網還沒有這麼火熱，相關的技術也沒有如今這樣成熟。
• 那是一個涉及銀行安全系統的集成項目，項目的需求主要是對企業用戶的票據加密與支付覈驗服務，項目的難點在於：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中間件實踐》
  《大型網站技術架構演示與性能優化》
  《架構解密：從分佈式到微服務》
  《淘寶技術這十年》
  《什麼是分佈式系統，如何學習分佈式系統》