高併發架構設計漫談

商業系統的架構設計知易行難，少有一蹴而就的。

它往往是業務、技術、人員、時間的四重平衡與取捨。

架構如下棋，如是見棋走子，不做提前兩三步的預測和判斷，通常難勝。

當業務已經在系統上跑起來後，想要再改架構，積重難返。

業務不等人，競爭對手進攻，決策層耐心有限，專案成員精力疲憊信心不在，何去何從？

本文討論的是面向商業的高併發系統，

介紹了一種面向高併發的流媒體傳輸系統的架構設計，它和具體的業務關係不大。

和自下而上設計（如從使用開源軟體驗證功能到最終開發出滿足業務需要的系統）不同，

這裡更注重討論自上而下的架構設計（從業務目標開始再到實現功能的開源軟體使用）的一些基本套路。

一、資料分離

無論是媒體處理系統，還是媒體傳輸系統，都可以將系統內流動的資料分成四種流，

它們分別是信令流，媒體流，狀態流和日誌流。

將資料分流，

一是為了解藕高併發系統各個處理單元，對瓶頸點，高頻訪問點，資料密集點，計算密集點等用不同的技術進行最佳化；

二是為了人員與專案的並行開發，提高整體的開發效率。

下圖是一個帶客戶端的資料分離的高併發流媒體傳輸系統架構設計框圖。

在邏輯上（真正實現上可以靈活）它的四種流如下：

> 信令流：

它是用於系統內的信令通訊和控制，如客戶端的註冊，鑑權，邊緣節點的分配，會話管理，信令反饋和通知等。

它是客戶端與服務端互動的起點和終點。

起點是指客戶端先要和服務端建立起信令通訊道，才能進行如覆蓋客戶端所在地域的邊緣節點分配，

客戶端的註冊，鑑權，及客戶端的全域性設定，媒體屬性設定，從客戶端A到客戶端B的路由路徑等，然後到開始建立媒體通道。

終點是指當整個通訊結束後，服務端將會通知到客戶端會話結束，客戶端可以釋放各種資源；

> 媒體流：

它是真正的媒體資料的流通通道，流動的是音影片編碼資料。

它依據信令流指定的路由路徑，將媒體資料從客戶端A經服務端處理，分發後送到客戶端B。

它的實現可以是RTP/RTCP，也可以是RTMP等。

> 狀態流：

它是服務端節點的”狀態採集器“將本節點狀態（如CPU，網路，業務是否飽和等）實時上報到監控中心節點後，

由全域性排程服務選擇性地使用。

它是實時更新，即時處理的，用以實現系統的熱新增、摘除服務節點，自動平衡節點、通道的負載。

其工作流程是，在每個節點上，有獨立於實際業務處理程式之外的狀態採集器，

由它來主動收集節點的業務和效能狀態，將它們推送到監控中心節點，監控中心節點會將資料分層，

儲存到如Redis， MySQL， sqlite等資料庫叢集，全域性排程服務從資料庫叢集中獲得這些分層後的資料，

來做為負載排程，節點增刪的依據。

> 日誌流：

它是客戶端，服務端的日誌資料的收集、清洗和展示。

同時也用來做運維監控和異常報警用。

它不需要實時處理，能做到業務響應要求即可。

在之前的專案經歷中，

曾遇到過只實現了信令流，媒體流的系統設計。

功能開發完成後，只用了半年時間不到，

就因為業務增長，系統需要進一步擴容，

導致了嚴重的負載不均，系統的自檢測和異常處理的穩定性很差，而不得不重構。

也遇到過以開源軟體為中心，去貼合業務需求，

但因為開源軟體是半成品，功能不全。

當要將它接入到已有的業務系統時，

因為相容的問題涉及系統實現的語言，業務的邏輯適配，

對業務系統和基於開源的新系統的架構改動都很複雜，

到後來系統只小範圍地內部使用了不到一年，專案直接宣告死亡。

二、無單點

商業系統的穩定性、健壯性和可擴容性都是業務需求的必選項。

無單指的是系統中所有節點至少都有二個選擇，並且它們都是獨立的，互為備份。

這和蘋果公司對供應鏈中供應商的選擇，一定是有備份的，這也是蘋果對供應鏈廠商進行控制和議價的手段。

下圖是無單點的設計的一個方框圖

對於客戶端來說，它的每個資料流同時有兩臺可用邊緣伺服器可用；

對於邊緣節點來說，它的每臺伺服器都中心節點都有兩條資料鏈路可選；

對於中心節點來說，它使用LVS為它獨立的多臺伺服器提供負載均衡服務；

三、三重熱備

對於使用者或客戶來說，商業系統不僅僅是一個系統，更認為它是一項可以依賴的服務，

無論是人為，還是天災地禍，它都能穩健地提代服務，

換句話說，服務要達到99。99%的可用性。

這時，可能就不僅僅是一個系統架構設計的問題，而是服務可靠性的策略選擇問題。

如上圖所示，比較通用的做法是，

在內部部署兩套相互獨立（如雲服務商獨立，或叢集獨立）的系統外，

還需要在外部找一個第三方系統做備份。

這個選擇對於客戶來說，提供的是服務的可靠性保障。

對於決策者來這，這是技術系統與人員雙重備份，也是對內部系統與外部系統的控制和議價手段。