微服務可用性設計

悠悠聽風發表於2021-11-16

引言

當專案架構演進到微服務的時候，系統分散式部署，傳統單個流程的本地 API 呼叫被拆分成多個微服務之間的跨網路呼叫，由於引入了網路通訊、序列化和反序列化等操作，系統發生故障的概率提高了很多。而業界通常用多少個9來衡量系統的可用性，如99.99%表示一年中有1小時左右的不可用時間。那麼如何有效確保微服務架構的可用性呢？

微服務可用性設計

微服務的可用性通常可以從隔離、超時控制、過載保護、限流、熔斷、降級、重試、負載均衡

隔離

微服務隔離，本質上是對系統或者資源進行分割，從而實現當系統發生事故的時候可以限制傳播範圍和影響範圍，只有發生故障的服務不可用，而其他服務依舊可以提供服務。

服務隔離
- 動靜分離
  動靜分離：動靜分離很好理解，現在的軟體架構大部分都是前後端分離的模式，而前端的靜態資源如圖片、音視訊等資源可以儲存到oss雲端儲存伺服器，動態API則部署在ECS上來做到動靜分離，靜態檔案訪問負載全部通過CDN加速。
- 讀寫分離
  讀寫分離：如資料庫主從讀寫分離，DDD的CQRS模式
輕重隔離
- 核心隔離
  核心隔離：根據業務進行資源劃分，核心業務與非核心業務進行機器資源、依賴資源隔離，核心業務可以搭建多叢集通過冗餘資源來提升吞吐和容災能力。
- 熱點隔離
- 快慢隔離
物理隔離
- 執行緒
- 程式
- 叢集
- 機房

超時控制

超時控制，在微服務的呼叫中，我們希望元件能夠快速失效，不希望等到例項連線超時而導致的頁面無響應和請求掛起。這樣不僅浪費資源同時也會導致使用者體驗感下降。
在實際業務開發中，各微服務的超時策略並不一定都清楚或者隨著業務迭代超時策略發生變動，意外導致超時策略失效，就需要一個保底的機制，在基礎庫中設定預設超時策略來進行配置的防禦保護。同時API服務的提供者需要定義好latency SLO，所有呼叫者都應遵守其超時策略的規定。

超時傳遞：如果一個請求有多個階段，比如由一系列 RPC 呼叫組成，那麼我們的服務應該在每個階段開始前檢查截止時間以避免做無用功，也就是要檢查是否還有足夠的剩餘時間處理請求。

總而言之，超時控制是微服務可用性的第一道關，良好的超時策略可以儘可能的保證服務不堆積請求，不會掛掉，只有服務不掛掉才有能夠執行後續的限流、熔斷、降級、重試等策略

過載保護

在微服務中由於服務間相互依賴很容易出現連鎖故障，連鎖故障可能是由於整個服務鏈路中的某一個服務出現故障，進而導致系統的其他部分也出現故障。之前講的超時控制是為了保證服務在出現連線超時能夠快速失敗，消除請求積壓，而過載保護則是在服務高負載的情況下的一種保護策略。

限流

所謂限流是指在一段時間內，定義某個客戶或者應用可以接收或者處理多少請求，通過限流，我們可以確保服務不會被高流量沖垮導致連鎖故障，確保應用程式在自動擴充套件失效前都不會出現過載的情況。
限流演算法：

令牌桶
令牌桶演算法的核心是系統會以一定的速率往桶裡新增令牌，處理請求前，則需要先從桶裡獲取一個令牌，當桶裡沒有令牌可取時，則返回失敗。
所有的請求在處理之前都需要拿到一個可用的令牌才會被處理；
獲取不到令牌，則請求返回失敗
根據限流大小，設定按照一定的速率往桶裡新增令牌；
桶設定最大的放置令牌限制，當桶滿時、新新增的令牌就被丟棄或者拒絕；
漏斗桶
漏桶(Leaky Bucket)演算法思路很簡單,水(請求)先進入到漏桶裡,漏桶以一定的速度出水(介面有響應速率),當水流入速度過大會直接溢位(訪問頻率超過介面響應速率),然後就拒絕請求,而當入小於出的情況下，漏桶不起任何作用。可以看出漏桶演算法能強行限制資料的傳輸速率.示意圖如下:
固定視窗
使用固定視窗實現限流的思路大致為，將某一個時間段當做一個視窗，在這個視窗記憶體在一個計數器記錄這個視窗接收請求的次數，每接收一次請求便讓這個計數器的值加一,如果計數器的值大於請求閾值的時候，即開始限流。當這個時間段結束後，會初始化視窗的計數器資料，相當於重新開了一個視窗重新監控請求次數。
滑動視窗
滑動視窗為固定視窗的改良版，解決了固定視窗在視窗切換時會受到兩倍於閾值數量的請求，滑動視窗在固定視窗的基礎上，將一個視窗分為若干個等份的小視窗，每個小視窗對應不同的時間點，擁有獨立的計數器，當請求的時間點大於當前視窗的最大時間點時，則將視窗向前平移一個小視窗（將第一個小視窗的資料捨棄，第二個小視窗變成第一個小視窗，當前請求放在最後一個小視窗），整個視窗的所有請求數相加不能大於閥值。
BBR擁塞控制演算法
不管是漏斗桶還是令牌桶，缺點都太過明顯，不能快速適應流量變化，限流的閾值需要人工設定，因此需要一種自適應的限流演算法，這就是BBR動態流控演算法。