Linkerd 2.10 系列

• 快速上手 Linkerd v2 Service Mesh（服務網格）
• 騰訊雲 K8S 叢集實戰 Service Mesh—Linkerd2 & Traefik2 部署 emojivoto 應用
• 詳細瞭解 Linkerd 2.10 基礎功能，一起步入 Service Mesh 微服務架構時代
• Linkerd 2.10(Step by Step)—1. 將您的服務新增到 Linkerd
• Linkerd 2.10(Step by Step)—2. 自動化的金絲雀釋出
• Linkerd 2.10(Step by Step)—3. 自動輪換控制平面 TLS 與 Webhook TLS 憑證

Linkerd 2.10 中文手冊持續修正更新中：

• https://linkerd.hacker-linner.com

為了讓 Linkerd 自動重試失敗，有兩個問題需要回答：

• 應該重試哪些請求？
• 請求應該重試多少次？

這兩個問題都可以通過在服務配置檔案
中為您傳送請求的服務指定一些額外資訊來回答。

之所以需要這些配置，是因為重試可能存在潛在危險。
自動重試更改狀態的請求（例如提交金融交易的請求）可能會對您的使用者體驗產生負面影響。
此外，重試會增加系統負載。一組具有不斷重試請求的服務可能會被重試打死，而沒有時間恢復。

重試

對於冪等且沒有主體的路由，您可以編輯服務配置檔案(service profile

spec:
  routes:
  - name: GET /api/annotations
    condition:
      method: GET
      pathRegex: /api/annotations
    isRetryable: true ### ADD THIS LINE ###

重試預算

retry budget 是一種機制，它限制可以對服務執行的重試次數佔原始請求的百分比。
這可以防止重試使您的系統不堪重負。
預設情況下，重試最多可以增加 20% 的請求負載（加上每秒額外的 10 次“免費”重試）。
可以通過在您的 service profile

spec:
  retryBudget:
    retryRatio: 0.2
    minRetriesPerSecond: 10
    ttl: 10s

監控重試

可以使用帶有 --to 標誌和 -o wide 標誌的 linkerd viz routes 命令來監視重試。
由於重試是在客戶端執行的，我們需要使用 --to 標誌來檢視一個資源傳送到
另一個資源的請求的指標（從伺服器的角度來看，重試只是常規請求）。
當指定這兩個標誌時，linkerd routes 命令將區分“有效(effective)”和“實際(actual)”流量。

ROUTE                       SERVICE   EFFECTIVE_SUCCESS   EFFECTIVE_RPS   ACTUAL_SUCCESS   ACTUAL_RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
HEAD /authors/{id}.json     authors             100.00%          2.8rps           58.45%       4.7rps           7ms          25ms          37ms
[DEFAULT]                   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms

實際請求代表客戶端實際傳送的所有請求，包括原始請求和重試。
有效請求只計算原始請求。由於原始請求可能會觸發一次或多次重試，
因此在啟用重試時，實際請求量通常高於有效請求量。
由於原始請求可能第一次失敗，但該請求的重試可能會成功，
因此有效成功率(effective success rate)
通常（但不總是）高於實際成功率(actual success rate)。

我是為少
微信：uuhells123
公眾號：黑客下午茶
加我微信（互相學習交流），關注公眾號（獲取更多學習資料~）