流量控制

通過合理設定流控配置，避免消費方的併發請求數超出服務提供方的承受能力，導致服務不可用。

靜態流控

靜態流控主要是針對客戶端的併發請求進行控制，根據SLA的約定的QPS做全域性流量控制。

• 傳統靜態流控設定，根據叢集服務節點數量和流控閾值，計算各個節點的閾值，執行時，各個節點按照已分配的閾值進行流控（還有一種設計就是配置的流控閾值其實是節點的閾值，不是整個叢集的全域性數量）；
  
  2點需要注意：

  1. 服務例項通常多執行緒執行，考慮執行緒安全，可以使用Atomic原子類進行原子操作；
  2. 到達流控閾值後拒絕請求接入，不能拒絕已有請求的服務方返回應答訊息。

• 傳統方案的缺點，新服務節點的加入，已有節點的宕機，雲端部署服務的彈性伸縮，導致服務例項的動態變化，預分配的方案會發生變化，重新計算；

• 動態配額分配製，為解決靜態流控的缺點，採用動態分配，原理：註冊中心以流控週期T為單位，動態推送每個節點的流控閾值，節點變化時，註冊中心重新計算節點閾值推送；
  

  1. 生產環境，節點的配置不同，採用上述總閾值/節點數的平均，導致效能高，處理塊的節點，節點的配額很快用完，效能差的總是有剩餘，解決方法就是註冊中心做配額計算時，考慮服務節點的效能（例如服務呼叫時延）做加權，效能好的多分配，差的少分配；
  2. 另一種方案就是配額指標返還和重新申請，服務節點根據自身情況預測，對於分配的指標，多的就返還，少的就申請；
  3. 結合負載均衡做靜態流控，消費者根據各服務節點的負載情況做加權路由，效能差的節點路由得到的訊息更少，由於配額計算也根據負載做了加權調整，最終分配給效能差的接地啊配額指標也較少，這樣既保證了系統的負載均衡，又實現了配額的更合理分配。

• 動態配額申請制，配額分配解決了服務節點變化的問題，也能夠改善平均主義的分配，但是還有缺點：

  1. 流控週期T比較大，節點的負載變化比較快，服務節點的負載反饋到註冊中心，註冊中心計算後再做配額分配，可能誤差比較大；
  2. 流控週期T比較小，註冊中心需要實時獲取節點的效能資料計算負載情況，採集、上報、彙總、計算，會存在一定的時延，導致流控滯後產生誤差；
  3. 採用配額返還和重新申請，增加了互動次數，也有有誤差；
  4. 擴充套件性差，主要是所有壓力全在註冊中心；
     要解決上述問題，可以採用動態配額申請，原理：
  5. 部署時，根據服務節點數和靜態流控閾值，拿出一定比例的配額做初始分配，剩餘的放在資源池；
  6. 節點使用完初始分配的配額，再次申請配額；
  7. 總的配額使用完則流控。
     優點：
  8. 服務節點負載和效能資料，在節點本身計算，實時性高；
  9. 節點根據自身情況計算申請配額，保證效能好的申請更多的配額，差的申請的就少，可以更合理的調配資源，流控的精確性有保障。

動態流控

• 動態流控因子，主要是引發動態流控的因素，包括系統資源和應用資源；
• 分級流控，不同級別的流控遮蔽多少請求，可以想象閘門關閉情況。

併發控制

併發執行數量控制：
- 服務端全域性控制；
- 消費端的流控；

連線控制

服務端消費者之間的鏈路數量控制：
- 服務端連線數流控；
- 服務消費者連線數流控；

併發和連線控制演算法

• 服務端演算法：

  1. 獲取流控閾值；
  2. 從全域性rpc上下文獲取併發執行數，對比閾值，小於，則對當前計數器原子自增；
  3. 等於或者大於，拋rpc流控異常；
  4. 服務呼叫完，併發執行數自減。

• 消費端演算法：

  1. 獲取流控閾值；
  2. 從全域性rpc上下文獲取併發執行數，對比閾值，小於，則對當前計數器原子自增；
  3. 等於或者大於，進入wait狀態，wait超時時間為服務呼叫的超時時間；
  4. 其他執行緒完成服務呼叫，計數器減小，如併發執行數小於閾值，wait執行緒被notify，退出wait，繼續執行。

熔斷

不知道作者在流控這裡沒加熔斷機制，通常情況下都是，流控配合熔斷一起使用。

熔斷可以理解為保險絲。由於提供方故障，導致服務不可用，如果這時候我們還不停的請求，就會導致阻塞，消耗系統資源，如果這種情況發生在呼叫鏈中，情況就會更嚴重。
1. 閉合狀態，正常呼叫，記錄呼叫結果，連續多少次失敗，則轉換狀態為熔斷開啟；
2. 熔斷開啟狀態，這種狀態下，不容許服務呼叫，返回錯誤，一般來說，持續多少時間進入半開啟狀態；
3. 熔斷半開狀態，這種狀態，可以按比例放行部分請求，持續多少時間無呼叫異常或多少次呼叫無異常，熔斷開關關閉，放行所有請求。

服務降級

大促期間，會針對核心業務做流控和熔斷，而對於非核心業務，通常的處理方式則是服務降級。

遮蔽降級

大促期間的，為保證核心業務的穩定性，對非核心業務做遮蔽降級，服務放通，當服務呼叫時，不發起遠端呼叫，直接返回空，異常或執行本地邏輯。

• 遮蔽降級的流程
  

• 遮蔽降級的設計實現，配置平臺人工設定降級策略，配置操作可逆：
  

容錯降級

非核心業務不可用時，對故障做業務邏輯放通。不僅僅用於業務放通，也常用於提供方在客戶端執行容錯邏輯，容錯邏輯主要有：
1. Rpc異常：超時異常、解碼異常、流控異常、阻塞異常等；
2. Service異常：校驗失敗異常、資料庫操作異常等；

• 容錯降級的工作原理
  
  容錯降級與遮蔽降級區別：

  1. 觸發條件不同，容錯是根據呼叫結果觸發，遮蔽通常是人工干預觸發；
  2. 作用不同，容錯是服務不可用時做放行，遮蔽是將原本要發起遠端呼叫的服務做本地執行或異常等，將原屬於降級業務的資源調配出來供核心業務使用；
  3. 呼叫機制不同，容錯是會發起遠端呼叫的，遮蔽不會發起遠端，只做本地；
     

• 執行時容錯降級，支援執行時，動態配置容錯降級
  

業務層降級

業務層的處理通常包含一定業務邏輯和服務條用，在服務呼叫做降級後，業務層邏輯要支援服務降級後處理，做到業務層整體邏輯放行。

服務優先順序排程

在系統資源有限的情況下，包含核心業務或高優先順序的業務優先執行排程，降低低優先順序服務的排程頻次。

服務釋出的時候支援優先順序的設定。

執行緒排程器方案

執行緒排程的時候通過設定執行緒的優先順序，理論上，高優先順序的執行緒會優先排程，但是這種依賴底層，不一定精確。

優先順序佇列

基於優先順序佇列時，入佇列，比較優先順序，這樣高優先的訊息會先處理，但是如果持續有高優先順序的訊息到來，這樣會導致低優先的訊息得不到處理機會，一直積壓。

加權優先順序佇列

按照不同的優先順序設定不同的佇列，服務請求訊息按優先順序入不同的佇列，工作現場按照加權值從不同佇列取訊息處理。需要設定合理的佇列數量，防止膨脹。

服務的遷入遷出

服務治理平臺，支援服務動態的遷入遷出，這樣就可以實現資源緊張時將低優先順序的服務遷出，優先保證核心業務和高優先順序的服務。

服務治理

rpc框架邁向分散式服務框架的重要的一步。服務治理包含的東西太多了，常用的：
1. 服務呼叫統計；
2. top統計；
3. 容量規劃；
4. 日誌分析；
5. 依賴關係分析；

服務治理技術的歷史變遷

• SOA 治理

  1. 服務建模：驗證需求，發現和評估當前服務，服務建模和效能需求，開發治理規劃；
  2. 服務組裝：建立服務更新計劃，建立和修改服務滿足業務需求；
  3. 服務部署：確保服務的質量，功能測試、效能測試；
  4. 服務管理，生命週期管理和監控。
     缺點：
  5. 缺乏動態服務治理；

• 分散式服務框架服務治理
  

• AWS雲端微服務治理
  

服務化後的挑戰

• 跨團隊協作
• 服務上下線管控
• 服務安全
• SLA保障
• 故障定位

服務治理

目標：
1. 防止服務框架腐化：依賴關係分析，梳理不合理的依賴和呼叫路徑，優化服務化架構，防止程式碼腐化；
2. 故障定位；
3. 服務管控；

• 架構設計
  

• 執行態服務治理功能設計，作者以Dubbo為案例，介紹了服務治理的一些東西：

  1. 服務列表資訊；
  2. 服務消費、提供者資訊；
  3. 呼叫日誌；
  4. kpi資料；
  5. 流控等；

• 線下服務治理，
  

• 安全和許可權管理，服務的呼叫許可權，管理普通的各種功能選單的許可權

總結

一定要明白為什麼需要服務治理，以及服務治理的功能內容。服務治理除了各種管控外，最重要的是通用呼叫日誌進行呼叫分析，依賴關係分析，kpi效能等。

下節繼續……