系統設計：關於高可用系統的一些技術方案

系統設計：關於高可用系統的一些技術方案可靠的系統是業務穩定、快速發展的基石。那麼，如何做到系統高可靠、高可用呢？下麵從技術方面介紹幾種提高系統可靠性、可用性的方法。擴展擴展是最常見的提升系統可靠性的方法，系統的擴展可以避免單點故障，即一個節點出現了問題造成整個系統無法正常工作。換一個角度講，一 ...

系統設計：關於高可用系統的一些技術方案 可靠的系統是業務穩定、快速發展的基石。那麼，如何做到系統高可靠、高可用呢？下麵從技術方面介紹幾種提高系統可靠性、可用性的方法。擴展擴展是最常見的提升系統可靠性的方法，系統的擴展可以避免單點故障，即一個節點出現了問題造成整個系統無法正常工作。換一個角度講，一個容易擴展的系統，能夠通過擴展來成倍的提升系統能力，輕鬆應對系統訪問量的提升。一般地，擴展可以分為垂直擴展和水平擴展：

垂直擴展：是在同一邏輯單元里添加資源從而滿足系統處理能力上升的需求。比如，當機器記憶體不夠時，我們可以幫機器增加記憶體，或者數據存不下時，我們為機器掛載新的磁碟。

垂直擴展能夠提升系統處理能力，但不能解決單點故障問題。
優點：擴展簡單。
缺點：擴展能力有限。

水平擴展：通過增加一個或多個邏輯單元，並使得它們像整體一樣的工作。

水平擴展，通過冗餘部署解決了單點故障，同時又提升了系統處理能力。
優點：擴展能力強。
缺點：增加系統複雜度，維護成本高，系統需要是無狀態的、可分散式的。

可擴展性繫數 scalability factor 通常用來衡量一個系統的擴展能力，當增加 1 單元的資源時，系統處理能力只增加了 0.95 單元，那麼可擴展性繫數就是 95%。當系統在持續的擴展中，可擴展繫數始終保持不變，我們就稱這種擴展是線性可擴展。在實際應用中，水平擴展最常見：

通常我們在部署應用伺服器的時候，都會部署多台，然後使用 nginx 來做負載均衡，nginx 使用心跳機制來檢測伺服器的正常與否，無響應的服務就從集群中剔除。這樣的集群中每台伺服器的角色是相同的，同時提供一樣的服務。
在資料庫的部署中，為了防止單點故障，一般會使用一主多從，通常寫操作只發生在主庫。不同資料庫之間角色不同。當主機宕機時，一臺從庫可以自動切換為主機提供服務。

隔離隔離，是對什麼進行隔離呢？是對系統、業務所占有的資源進行隔離，限制某個業務對資源的占用數量，避免一個業務占用整個系統資源，對其他業務造成影響。隔離級別按粒度從小到大，可以分為線程池隔離、進程隔離、模塊隔離、應用隔離、機房隔離。在資料庫的使用中，還經常用到讀寫分離。

線程池隔離：不同的業務使用不同的線程池，避免低優先順序的任務阻塞高優先順序的任務。或者高優先順序的任務過多，導致低優先順序任務永遠不會執行。
進程隔離：Linux 中有用於進程資源隔離的 Linux CGroup，通過物理限制的方式為進程間資源控制提供了簡單的實現方式，為 Linux Container 技術、虛擬化技術的發展奠定了技術基礎。在工作中的實際應用，可以看看這篇文章：日誌壓縮資源消耗優化: Linux CGroup 的使用。
模塊隔離、應用隔離：很多線上故障的發生源於代碼修改後，測試不到位導致。按照代碼或業務的易變程度來劃分模塊或應用，把變化較少的劃分到一個模塊或應用中，變化較多的劃分到另一個模塊或應用中。減少代碼修改影響的範圍，也就減少了測試的工作量，減少了故障出現的概率。
機房隔離：主要是為了避免單個機房網路問題或斷電吧。
讀寫分離：一方面，將對實時性要求不高的讀操作，放到 DB 從庫上執行，有利於減輕 DB 主庫的壓力。另一方面，將一些耗時離線業務 sql 放到 DB 從庫上執行，能夠減少慢 sql 對 DB 主庫的影響，保證線上業務的穩定可靠。

解耦在軟體工程中，對象之間的耦合度就是對象之間的依賴性。對象之間的耦合越高，維護成本越高，因此對象的設計應使模塊之間的耦合度儘量小。在軟體架構設計中，模塊之間的解耦或者說松耦合有兩種，假設有兩個模塊A、B，A依賴B：

第一種是，模塊A和模塊B只通過介面交互，只要介面設計不變，那麼模塊B內部細節的變化不影響模塊A對模塊B服務能力的消費。

面向介面設計下真正實現了將介面契約的定義和介面的實現徹底分離，實現變化不影響到介面契約，自然不影響到基於介面的交互。
模塊A和B之間的松耦合，主要通過合理的模塊劃分、介面設計來完成。如果出現迴圈依賴，可以將模塊A、B共同依賴的部分移除到另一個模塊C中，將A、B之間的相互依賴，轉換為A、B同時對C的依賴。

第二種是，將同步調用轉換成非同步消息交互。

比如在買機票系統中，機票支付完成後需要通知出票系統出票、代金券系統發券。如果使用同步調用，那麼出票系統、代金券系統宕機是會影響到機票支付系統，如果另一個系統比如專車系統也想要在機票支付完成後向用戶推薦專車服務，那麼同步調用模式下機票支付系統就需要為此而改動，容易影響核心支付業務的可靠性。
如果我們將同步調用替換成非同步消息，機票支付系統發送機票支付成功的消息到消息中間件，出票系統、代金券系統從消息中間件訂閱消息。這樣一來，出票系統、代金券系統的宕機也就不會對機票支付系統造成任何影響了。專車系統想要知道機票支付完成這一事件，也只需要從消息中間件訂閱消息即可，機票支付系統完全不需要做任何改動。
非同步消息解耦，適合那些信息流單向流動（類似發佈-訂閱這樣的），實時性要求不高的系統。常見的開源消息隊列框架有：Kafka、RabbitMQ、RocketMQ。

限流為什麼要做限流呢？舉一個生活中的例子，大家早上上班都要擠地鐵吧，地鐵站在早高峰的時候經常要限制客流，為什麼呢？有人會覺得這是人為添堵。真是這樣嗎？如果不執行客流控制，大家想想會是什麼場景呢？站臺到處都擠滿了乘客，就算你使出洪荒之力也不一定能順利上車，且非常容易引發肢体碰撞，造成衝突。有了客流控制之後，地鐵站才能變得秩序井然，大家才能安全上地鐵。一個系統的處理能力是有上限的，當服務請求量超過處理能力，通常會引起排隊，造成響應時間迅速提升。如果對服務占用的資源量沒有約束，還可能因為系統資源占用過多而宕機。因此，為了保證系統在遭遇突發流量時，能夠正常運行，需要為你的服務加上限流。常見的限流演算法有：漏桶、令牌桶、滑動視窗計數。分類按照計數範圍，可以分為：單機限流、全局限流。單機限流，一般是為了應對突發流量，而全局限流，通常是為了給有限資源進行流量配額。按照計數周期，可以分為：QPS、併發（連接數）。按照閾值設定方式的不同，可以分為：固定閾值、動態閾值。 漏桶演算法 下麵這張圖，是漏桶的示意圖。漏桶演算法思路很簡單，水（請求）先進入到漏桶里，漏桶以一定的速度出水，當水流入速度過大時，會直接溢出，可以看出漏桶演算法能強行限制數據的傳輸速率。漏桶演算法(Leaky Bucket)是網路世界中流量整形（Traffic Shaping）或速率限制（Rate Limiting）時經常使用的一種演算法，它的主要目的是控制數據註入到網路的速率，平滑網路上的突發流量。

漏桶演算法原理 漏桶演算法可以使用 Redis 隊列來實現，生產者發送消息前先檢查隊列長度是否超過閾值，超過閾值則丟棄消息，否則發送消息到 Redis 隊列中；消費者以固定速率從 Redis 隊列中取消息。Redis 隊列在這裡起到了一個緩衝池的作用，起到削峰填谷、流量整形的作用。 令牌桶演算法 對於很多應用場景來說，除了要求能夠限制數據的平均傳輸速率外，還要求允許某種程度的突發傳輸。這時候漏桶演算法可能就不合適了，令牌桶演算法更為適合。令牌桶演算法的原理是系統會以一個恆定的速度往桶里放入令牌，而如果請求需要被處理，則需要先從桶里獲取一個令牌，當桶里沒有令牌可取時，則拒絕服務。桶里能夠存放令牌的最高數量，就是允許的突發傳輸量。