摘要：在這篇文章中，我們描述了我們?nèi)绾卧诶镌O(shè)計重試，使能夠在最小化風(fēng)險的同時，自動提高系統(tǒng)可靠性。配置重試的最常用方法，是指定在放棄之前執(zhí)行的最大重試次數(shù)。超時時，將取消請求并返回響應(yīng)。但是在上面的服務(wù)配置文件中，我們將在服務(wù)器端指定重試政策。

作者：Alex Leong

重試是處理分布式系統(tǒng)中的部分或瞬態(tài)故障的基本機(jī)制。但重試也可能是危險的，如果做得不好，他們可以迅速將一個小錯誤升級為系統(tǒng)范圍的中斷。在這篇文章中，我們描述了我們?nèi)绾卧贚inkerd 2.2里設(shè)計重試，使Linkerd能夠在最小化風(fēng)險的同時，自動提高系統(tǒng)可靠性。

在Linkerd 2.2里，我們引入了重試，就是Linkerd能夠自動重試失敗的請求。這使Linkerd能夠自動處理服務(wù)中的部分或瞬態(tài)故障，而無需應(yīng)用程序知道：如果請求失敗，Linkerd可以再次嘗試！結(jié)合Linkerd的請求級負(fù)載平衡，這允許Linkerd處理各個pod的故障。

在Linkerd里，您將重試指定為服務(wù)配置文件的一部分（在之前的博客文章中介紹）。將路由標(biāo)記為可重試就像添加isRetryable一樣簡單：設(shè)定true到相應(yīng)的服務(wù)配置文件條目：

- name: HEAD /authors/{id}.json
    condition:
      method: HEAD
      pathRegex: /authors/[^/]*.json
    isRetryable: true

當(dāng)然，在向路由添加重試行為之前，應(yīng)該確保路由是冪等的（idempotent）。換句話說，對具有相同參數(shù)的相同路由的多次調(diào)用將沒有不良影響。這很重要，因?yàn)橹卦嚕ǜ鶕?jù)定義?。┛赡軐?dǎo)致將同一請求的多個副本發(fā)送到服務(wù)。如果請求做了非冪等的（non-idempotent）事情，例如從您的銀行帳戶中減去一美元，您可能不希望它自動重試。

啟用后，重試有兩個重要參數(shù)：預(yù)算（budget）和超時（timeout）。讓我們依次考慮這兩個方面。

將路由標(biāo)記為可重試后，Linkerd允許您為服務(wù)配置重試預(yù)算。Linkerd附帶了合理的默認(rèn)值，但如果您想自定義預(yù)算，可以在服務(wù)配置文件中進(jìn)行設(shè)置：

retryBudget:
  # The retryRatio is the maximum ratio of retries requests to original
  # requests.  A retryRatio of 0.2 means that retries may add at most an
  # additional 20% to the request load.
  retryRatio: 0.2

  # This is an allowance of retries per second in addition to those allowed
  # by the retryRatio.  This allows retries to be performed, when the request
  # rate is very low.
  minRetriesPerSecond: 10

  # This duration indicates for how long requests should be considered for the
  # purposes of calculating the retryRatio.  A higher value considers a larger
  # window and therefore allows burstier retries.
  ttl: 10s

Linkerd使用重試預(yù)算，較使用最大重試次數(shù)配置重試的常規(guī)做法，是更好替代方法。我們花一點(diǎn)時間來理解為什么。

首先，一些背景。配置重試的最常用方法，是指定在放棄之前執(zhí)行的最大重試次數(shù)。對于使用網(wǎng)絡(luò)瀏覽器的任何人來說，這是一個熟悉的想法：您嘗試加載網(wǎng)頁，如果沒有加載，則再試一次。如果仍然無法加載，則第三次嘗試。最后您放棄了。

不幸的是，以這種方式配置重試至少有兩個問題：

選擇最大重試次數(shù)是猜謎游戲。您需要選擇一個足夠高的數(shù)字，以便在出現(xiàn)某種故障時發(fā)揮作用，但不要太高，以至于當(dāng)系統(tǒng)真正失敗時會在系統(tǒng)上產(chǎn)生額外負(fù)載。在實(shí)踐中，您通常會從帽子中選擇最大重試次數(shù)（例如3），并希望獲得最佳效果。

以這種方式配置的系統(tǒng)易受重試風(fēng)暴的影響。當(dāng)一個服務(wù)開始出現(xiàn)大于正常的故障率時，重試風(fēng)暴開始。這會導(dǎo)致其客戶端重試這些失敗的請求。重試帶來的額外負(fù)載，會導(dǎo)致服務(wù)進(jìn)一步減速，并使更多請求失敗，從而觸發(fā)更多重試。如果每個客戶端配置為最多重試3次，則可以將發(fā)送的請求數(shù)量翻兩番！更糟糕的是，如果任何客戶端的客戶端配置了重試，則重試次數(shù)會成倍增加，并且可以將少量錯誤轉(zhuǎn)化為自我造成的拒絕服務(wù)攻擊。

為了避免這些問題，Linkerd使用重試預(yù)算。Linkerd不是為每個請求指定固定的最大重試次數(shù)，而是跟蹤常規(guī)請求和重試之間的比率，并將此數(shù)字保持在限制之下。例如，您可以指定要重試最多添加20％的請求。然后，Linkerd將盡可能多地重試，同時保持該比率。

因此，使用重試預(yù)算可以明確在提高成功率和額外負(fù)載之間進(jìn)行權(quán)衡。您的重試預(yù)算正是您的系統(tǒng)愿意從重試中接受的額外負(fù)載。

（最后，Linkerd的重試預(yù)算還包括允許的最小重試次數(shù)，這將是唯一允許的，與比率無關(guān)。這使得Linkerd可以在非常低的流量系統(tǒng)中重試。）

除了預(yù)算之外，重試還按每個請求的超時參數(shù)。超時可確保始終失敗的請求最終會返回響應(yīng)，即使該響應(yīng)失敗也是如此。超時時，Linkerd將取消請求并返回HTTP 504響應(yīng)。

與重試預(yù)算類似，重試超時具有可在服務(wù)配置文件中覆蓋的合理默認(rèn)值：

- name: HEAD /authors/{id}.json
    condition:
      method: HEAD
      pathRegex: /authors/[^/]*.json
    timeout: 50ms

您可能已經(jīng)注意到上面的配置片段中的有趣內(nèi)容。在“傳統(tǒng)”重試系統(tǒng)（例如Web瀏覽器）中，是在客戶端上配置重試行為，畢竟，這是重試實(shí)際發(fā)生的地方。但是在上面的服務(wù)配置文件中，我們將在服務(wù)器端指定重試政策。

能夠?qū)⒄吒郊拥椒?wù)器端，但客戶端必須遵守該政策，這是Linkerd服務(wù)配置文件方法的基本優(yōu)勢之一。重試配置在邏輯上屬于服務(wù)級別（“這是您應(yīng)該和我說話的方式”）。由于Linkerd控制客戶端和服務(wù)器行為，我們可以正確的方式執(zhí)行此操作：服務(wù)配置文件允許服務(wù)準(zhǔn)確發(fā)布“這是我希望您與我交談的方式”，通過Linkerd的所有流量，無論來源如何，會尊重這種行為。太酷了！

我們已經(jīng)展示了如何通過組合超時、預(yù)算和可重試性來配置Linkerd的重試行為?，F(xiàn)在讓我們將它們放在一起進(jìn)行簡短的演示。如果您有一個終端窗口和一個Kubernetes集群，您可以在家里跟隨。

我們首先安裝Linkerd和我們的樣本書應(yīng)用程序：

$ linkerd install | kubectl apply -f -
$ curl https://run.linkerd.io/bookapp.yml | linkerd inject - | kubectl apply -f -
$ linkerd check

關(guān)于這個應(yīng)用程序，我們可以注意到的一件事是，從書籍服務(wù)到作者服務(wù)的請求的成功率非常低：

$ linkerd routes deploy/books --to svc/authors
ROUTE       SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
[DEFAULT]   authors    54.24%   3.9rps           5ms          14ms          19ms

為了更好地了解這里發(fā)生了什么，讓我們?yōu)樽髡叻?wù)添加一個服務(wù)配置文件，從Swagger定義生成：

$ curl https://run.linkerd.io/booksapp/authors.swagger | linkerd profile --open-api - authors | kubectl apply -f  -
$ linkerd routes deploy/books --to svc/authors
ROUTE                       SERVICE   SUCCESS      RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
DELETE /authors/{id}.json   authors     0.00%   0.0rps           0ms           0ms           0ms
GET /authors.json           authors     0.00%   0.0rps           0ms           0ms           0ms
GET /authors/{id}.json      authors     0.00%   0.0rps           0ms           0ms           0ms
HEAD /authors/{id}.json     authors    50.85%   3.9rps           5ms          10ms          17ms
POST /authors.json          authors     0.00%   0.0rps           0ms           0ms           0ms
[DEFAULT]                   authors     0.00%   0.0rps           0ms           0ms           0ms

有一件事是清楚的，從書籍到作者的所有請求都是針對HEAD /authors/{id}.json路線，這些請求在大約50％的時間內(nèi)失敗。為了糾正這個問題，讓我們編輯作者服務(wù)配置文件，并使這些請求可以重試：

$ kubectl edit sp/authors.default.svc.cluster.local
[...]
  - condition:
      method: HEAD
      pathRegex: /authors/[^/]*.json
    name: HEAD /authors/{id}.json
    isRetryable: true ### ADD THIS LINE ###

在編輯服務(wù)配置文件后，我們看到成功率幾乎立即有所改善：

$ linkerd routes deploy/books --to svc/authors -o wide
ROUTE                       SERVICE   EFFECTIVE_SUCCESS   EFFECTIVE_RPS   ACTUAL_SUCCESS   ACTUAL_RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
DELETE /authors/{id}.json   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
GET /authors.json           authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
GET /authors/{id}.json      authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
HEAD /authors/{id}.json     authors             100.00%          2.8rps           58.45%       4.7rps           7ms          25ms          37ms
POST /authors.json          authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
[DEFAULT]                   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms

成功率看起來很好，但p95和p99延遲有所增加。這是可以預(yù)料到的，因?yàn)橹卦囆枰獣r間。但是，我們可以通過設(shè)置超時，Linkerd 2.x的另一個新功能，在我們愿意等待的最長持續(xù)時間來限制此操作。出于本演示的目的，我將設(shè)置25ms的超時。您的結(jié)果將根據(jù)系統(tǒng)的特性而有所不同。

$ kubectl edit sp/authors.default.svc.cluster.local
[...]
  - condition:
      method: HEAD
      pathRegex: /authors/[^/]*.json
    isRetryable: true
    name: HEAD /authors/{id}.json
    timeout: 25ms ### ADD THIS LINE ###

我們現(xiàn)在看到成功率略有下降，因?yàn)橛行┱埱蟪瑫r，但尾部延遲已大大減少：

$ linkerd routes deploy/books --to svc/authors -o wide
ROUTE                       SERVICE   EFFECTIVE_SUCCESS   EFFECTIVE_RPS   ACTUAL_SUCCESS   ACTUAL_RPS   LATENCY_P50   LATENCY_P95   LATENCY_P99
DELETE /authors/{id}.json   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
GET /authors.json           authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
GET /authors/{id}.json      authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
HEAD /authors/{id}.json     authors              97.73%          2.9rps           49.71%       5.8rps           9ms          25ms          29ms
POST /authors.json          authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms
[DEFAULT]                   authors               0.00%          0.0rps            0.00%       0.0rps           0ms           0ms           0ms

請注意，由于直方圖分段工件，p99延遲似乎大于我們的25ms超時。

在這篇文章中，我們描述了Linkerd如何以最小化系統(tǒng)風(fēng)險的方式自動重試請求。我們描述了為什么在服務(wù)器，而不是客戶端級別，指定了重試行為，我們向您介紹了如何在演示應(yīng)用程序中部署服務(wù)的重試和超時功能。

重試是Linkerd可靠性路線圖中的一大進(jìn)步。服務(wù)配置文件、重試和診斷的交集是Linkerd特別令人興奮的領(lǐng)域，您可以期待未來版本中更酷的功能。敬請期待！

喜歡這篇文章？Linkerd是一個社區(qū)項(xiàng)目，由CNCF托管。如果您有功能請求、問題或評論，我們很樂意讓您加入我們快速發(fā)展的社區(qū)！Linkerd的倉庫在GitHub上，我們在Slack、Twitter和郵件列表上擁有一個蓬勃發(fā)展的社區(qū)?？靵砑尤氚?！

KubeCon + CloudNativeCon和Open Source Summit大會日期：

會議日程通告日期：2019 年 4 月 10 日

會議活動舉辦日期：2019 年 6 月 24 至 26 日

KubeCon + CloudNativeCon和Open Source Summit贊助方案
KubeCon + CloudNativeCon和Open Source Summit多元化獎學(xué)金現(xiàn)正接受申請
KubeCon + CloudNativeCon和Open Source Summit即將首次合體落地中國