微服務可用性設計

引言

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

微服務可用性設計

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

隔離

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

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

超時控制

超時控制，在微服務的調用中，我們希望組件能夠快速失效，不希望等到實例連接超時而導致的頁面無響應和請求掛起。這樣不僅浪費資源同時也會導致用戶體驗感下降。
在實際業務開發中，各微服務的超時策略並不一定都清楚或者隨着業務迭代超時策略發生變動，意外導致超時策略失效，就需要一個保底的機制，在基礎庫中設置默認超時策略來進行配置的防御保護。同時API服務的提供者需要定義好latency SLO，所有調用者都應遵守其超時策略的規定。
當然，在某些時候我們期望即便超時了，他也能夠繼續執行后續的事情，而不是直接中斷在某一步，后續通過重試策略和冪等機制來保證業務的唯一性，這樣大大提高了服務的訪問成功率。

• 超時傳遞：如果一個請求有多個階段，比如由一系列 RPC 調用組成，那么我們的服務應該在每個階段開始前檢查截止時間以避免做無用功，也就是要檢查是否還有足夠的剩余時間處理請求。
  
  總而言之，超時控制是微服務可用性的第一道關，良好的超時策略可以盡可能的保證服務不堆積請求，不會掛掉，只有服務不掛掉才有能夠執行后續的限流、熔斷、降級、重試等策略

過載保護

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

限流

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

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

熔斷

熔斷機制其實是參考了我們日常生活中的保險絲的保護機制，當電路超負荷運行時，保險絲會自動的斷開，從而保證電路中的電器不受損害。而服務治理中的熔斷機制，指的是在發起服務調用的時候，如果被調用方返回的錯誤率超過一定的閾值，那么后續的請求將不會真正發起請求，而是在調用方直接返回錯誤。

降級

舉個耳熟能詳的例子，淘寶雙十一購物節期間，用戶只能夠進行購買而不能進行退款操作，這就是典型的降級處理，當高並發高負載的場景下，服務可以通過降低回復來減少工作量，或者丟棄不重要的請求。
降級的本質實為提供有損的服務，通過一定的降級策略來保護服務不會被大流量沖垮而導致連鎖故障。

重試

當請求返回錯誤例如請求超時、內部錯誤、配額不足，這時候使用重試機制可以提高請求的最終成功率，減少故障影響，讓系統運行更穩定，但是需要留意重試帶來的流量放大。
如下圖，假設 A 服務調用 B 服務，重試次數設置為 r（包括首次請求），當 B 高負載時很可能調用不成功，這時 A 調用失敗重試 B，B 服務的被調用量快速增大，最壞情況下可能放大到 r 倍，不僅不能請求成功，還可能導致 B 的負載繼續升高，甚至直接打掛。
因此重試只應該在失敗的這一層進行，當重試仍然失敗，全局約定錯誤碼直接返回避免級聯重試，重試需要配合限流，防止重試造成雪崩的可能。

負載均衡

在理想情況下，負載完全均勻的分發給后端微服務進行處理，而工作分擔到多個微服務上是為負載均衡，負載均衡是最基本的分流策略，如何將負載均勻的分配大致以下六種算法:
1、輪詢法
將請求按順序輪流地分配到后端服務器上，它均衡地對待后端的每一台服務器，而不關心服務器實際的連接數和當前的系統負載。
2、隨機法
通過系統的隨機算法，根據后端服務器的列表大小值來隨機選取其中的一台服務器進行訪問。由概率統計理論可以得知，隨着客戶端調用服務端的次數增多，
其實際效果越來越接近於平均分配調用量到后端的每一台服務器，也就是輪詢的結果。
3、源地址哈希法
源地址哈希的思想是根據獲取客戶端的IP地址，通過哈希函數計算得到的一個數值，用該數值對服務器列表的大小進行取模運算，得到的結果便是客服端要訪問服務器的序號。采用源地址哈希法進行負載均衡，同一IP地址的客戶端，當后端服務器列表不變時，它每次都會映射到同一台后端服務器進行訪問。
4、加權輪詢法
不同的后端服務器可能機器的配置和當前系統的負載並不相同，因此它們的抗壓能力也不相同。給配置高、負載低的機器配置更高的權重，讓其處理更多的請；而配置低、負載高的機器，給其分配較低的權重，降低其系統負載，加權輪詢能很好地處理這一問題，並將請求順序且按照權重分配到后端。
5、加權隨機法
與加權輪詢法一樣，加權隨機法也根據后端機器的配置，系統的負載分配不同的權重。不同的是，它是按照權重隨機請求后端服務器，而非順序。
6、最小連接數法
最小連接數算法比較靈活和智能，由於后端服務器的配置不盡相同，對於請求的處理有快有慢，它是根據后端服務器當前的連接情況，動態地選取其中當前
積壓連接數最少的一台服務器來處理當前的請求，盡可能地提高后端服務的利用效率，將負責合理地分流到每一台服務器。

負載均衡策略眾多，這里就不一一介紹了。

References

https://developer.aliyun.com/article/59008
https://mp.weixin.qq.com/s/5Q05d6OwvS-Zj-yNGwoh8A
https://learnku.com/articles/61838
https://www.cnblogs.com/duanxz/p/4123068.html
https://blog.csdn.net/weixin_41247920/article/details/100144184
https://blog.csdn.net/dog250/article/details/72849893
https://www.cnblogs.com/yuemoxi/p/15227815.html
https://my.oschina.net/u/4628563/blog/4692603
https://blog.csdn.net/ityouknow/article/details/81230412
https://blog.51cto.com/u_7117633/2864527