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

目錄

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

前言

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

背景

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