★微服務系列
微服務1：微服務及其演進史
微服務2：微服務全景架構
微服務3：微服務拆分策略
微服務4：服務注冊與發現
微服務5：服務注冊與發現（實踐篇）
微服務6：通信之網關
微服務7：通信之RPC
微服務8：通信之RPC實踐篇（附源碼）
微服務9：服務治理來保證高可用
微服務10：系統服務熔斷、限流
微服務11：熔斷、降級的Hystrix實現（附源碼）
微服務12：流量策略
微服務13：雲基礎場景下流量策略實現原理
1 背景
在復雜的互聯網場景中，不可避免的會出現請求失敗的情況。
從程序的的響應結果來看，一般是Response返回5xx狀態的錯誤；從用戶的角度去看，一般是請求結果不符合預期，即操作失敗（如轉賬失敗、下單失敗、信息獲取不到等）。
偶發的不可避免的5xx請求錯誤，產生的原因有很多種，比如：
- 網絡延遲或者抖動
- 服務器資源不足（CPU、內存走高、連接池滿）
- 服務器故障
- 符合某些特定條件下的服務程序bug（大都非必現）
2 系統穩定性等級划分
大部分服務容忍低頻、偶發的5xx錯誤，並使用可用性級別來衡量系統的健壯性，級別系數越高，健壯性越好，如下：
| 等級描述 | 故障時長（年） | 可用行等級 |
|---|---|---|
| 基本可用性 | 87.6h | 99% |
| 較高可用 | 8.8h | 99.9% |
| 非常高的可用性（大部分故障可自動恢復） | 52m | 99.99% |
| 極高可用性 | 5m | 99.999% |
對於強系統可靠性、強結果預期性 要求的系統，如轉賬、下單、付款，即使微小的可用性降級也是不可接受，用戶強烈需要接收到正確的結果。
可以想想你付款的時候發現付款失敗有多么驚慌，訂外賣的時候獲取信息失敗有多么沮喪，這些都是用戶痛點。
3 異常的治理手段
3.1 采用異常重試實現故障恢復
通過上面的故障原因分析我們知道，排除了必現的程序邏輯錯誤，大部分環境導致的錯誤是可以通過重試進行恢復的。
治理的手段主要是采用 異常重試 來實現的，通過重試負載到健康實例上（實例越多重試成功率越高），降低用戶感知到的故障頻率。
執行過程說明
- 這邊以示例服務 Svc-A 向 Svc-B 發起訪問為例子。
- 第1次執行失敗之后，根據策略，間隔25ms之后發起第2次請求。
- 會看到有兩條日志，日志的trace_id 一致，說明他是同一個調用過程（1個調用過程，包含2次請求，首發1次與重試1次）
- 請求方為同一個實例 Svc-A-Instance1，說明請求發起方一致。
- 被請求方發生了變動，說明調度到新的實例（Svc-B-Instance1 到 Svc-B-Instance2）。
- 返回正常的 200 。
因為我們的負載均衡模式默認是RR，所以實例越多，實際上重試成功的概率會越高。比如有50個實例，其中一個實例出故障，導致執行返回5xx，那么第二次請求的時候一般來說會有 49/50 的成功概率。如下圖：
3.2 策略實現（Service Mesh方案）
注釋比較清晰了，這邊就不解釋了。
# VirtualService
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: xx-svc-b-vs
namespace: kube-ns-xx
spec:
hosts:
- svc_b.google.com # 治理發往 svc-b 服務的流量
http:
- match: # 匹配條件的流量進行治理
- uri:
prefix: /v1.0/userinfo # 匹配路由前綴為 /v1.0/userinfo 的，比如 /v1.0/userinfo/1305015
retries:
attempts: 1 # 重試一次
perTryTimeout: 1s # 首次調用和每次重試的超時時間
retryOn: 5xx # 重試觸發的條件
timeout: 2.5s # 請求整體超時時間為2.5s，無論重試多少次，超過該時間就斷開。
route:
- destination:
host: svc_b.google.com
weight: 100
- route: # 其他未匹配的流量默認不治理，直接流轉
- destination:
host: svc_c.google.com
weight: 100
4 總結
雲基礎場景下的治理手段各種各樣，這邊講解了初級版的異常重試，讓用戶有一個更優良的使用環境。
后續的章節我們逐一了解下超時保護、故障注入、熔斷限流、異常驅逐等高級用法。