envoy重試

該博客是系列文章的一部分，該系列文章更深入地介紹了Envoy Proxy和Istio.io ，以及它如何實現一種更優雅的連接和管理微服務的方式。 跟隨我@christianposta ，緊跟這些博客文章的發布。

• 什么是Envoy代理 ，它如何工作？
• 如何使用Envoy Proxy實現一些基本模式？
• Istio Mesh如何適合這張照片
• Istio Mesh的工作方式，以及如何通過Envoy跨集群啟用高階功能
• Istio Mesh身份驗證的工作方式

這是接下來幾部分的想法（將在發布時更新鏈接）：

• 斷路器（第一部分）
• 重試/超時（第二部分）
• 分布式跟蹤（第三部分）
• 普羅米修斯的度量標準收集（第四部分）
• 服務發現（第五部分）
• 接下來的部分將介紹更多的客戶端功能（請求陰影，TLS等），只是不確定哪些部分將是:)

第二部分– Envoy代理的超時和重試

第一篇博客文章向您介紹了Envoy Proxy的斷路功能實現 。 在第二部分中，我們將仔細研究如何啟用額外的彈性功能，例如超時和重試。 這些演示有意簡單，因此我可以分別說明模式和用法。 請下載此演示的源代碼，然后繼續！

該演示由客戶端和服務組成。 客戶端是一個Java http應用程序，它模擬對“上游”服務進行http調用（請注意，我們在這里使用Envoys術語，并且貫穿此repo ）。 客戶端打包在名為docker.io/ceposta/http-envoy-client:latest的Docker映像中。 http-client Java應用程序旁邊是Envoy Proxy的實例。 在此部署模型中，Envoy與服務（在本例中為http客戶端）一起作為邊車進行了部署。 當http客戶端發出出站呼叫（到“上游”服務）時，所有呼叫都通過Envoy代理端進行。

這些示例的“上游”服務是httpbin.org 。 httpbin.org允許我們輕松模擬HTTP服務行為。 太棒了，所以如果您沒有看過，請檢查一下。

retries和timeouts演示都有自己的 envoy.json配置文件。 我絕對建議您查看配置文件各部分的參考文檔，以幫助您了解完整的配置。 datawire.io的好伙伴還為Envoy及其配置提供了不錯的介紹 ，您也應該查看一下。

運行重試演示

對于重試演示，我們將在Envoy中配置路由，如下所示：

"routes": [{"timeout_ms": 0,"prefix": "/","auto_host_rewrite": true,"cluster": "httpbin_service","retry_policy": {"retry_on": "5xx","num_retries": 3}}

在這里，我們說要對5xx的HTTP狀態最多重試3次。

如果您已經運行了先前的演示，請確保對此（或任何）演示重新開始。 對于每個演示，我們都有不同的Envoy配置，并希望確保每次都從干凈的開始。

首先停止任何現有的演示：

./docker-stop.sh

現在讓我們進行retries演示：

./docker-run.sh -d retries

現在，讓我們行使客戶端通過一個調用，這將創下一個HTTP端點應返回一個HTTP 500錯誤。 我們將使用curl.sh腳本，該腳本設置為在演示容器內調用curl。

./curl.sh -vvvv localhost:15001/status/500

我們應該看到這樣的東西：

* Hostname was NOT found in DNS cache * Trying ::1... * connect to ::1 port 15001 failed: Connection refused * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 15001 (#0) > GET /status/500 HTTP/1.1 > User-Agent: curl/7.35.0 > Host: localhost:15001 > Accept: */* > < HTTP/1.1 500 Internal Server Error * Server envoy is not blacklisted < server: envoy < date: Thu, 25 May 2017 05:55:37 GMT < content-type: text/html; charset=utf-8 < access-control-allow-origin: * < access-control-allow-credentials: true < x-powered-by: Flask < x-processed-time: 0.000718116760254 < content-length: 0 < via: 1.1 vegur < x-envoy-upstream-service-time: 684 < * Connection #0 to host localhost left intact

大！ 現在，讓我們檢查Envoy為我們做了什么：

./get-envoy-stats.sh | grep retrycluster.httpbin_service.retry.upstream_rq_500: 3 cluster.httpbin_service.retry.upstream_rq_5xx: 3 cluster.httpbin_service.upstream_rq_retry: 3 cluster.httpbin_service.upstream_rq_retry_overflow: 0 cluster.httpbin_service.upstream_rq_retry_success: 0

好極了！ 我們在這里看到，由于HTTP 500錯誤，特使已重試了3次。

如果天真的處理，重試會對您的服務體系結構產生有害影響。 它們可以幫助傳播故障或對可能陷入困境的內部服務造成DDoS類型的攻擊。

重試時要注意以下幾點：

• Envoy會自動進行帶抖動的指數重試。 有關更多信息，請參閱文檔
• 您可以設置重試超時（每次重試超時），但是總體路由超時（已為路由表配置；請參見timeouts演示以獲取確切配置）；仍然可以設置/應用； 這是為了短路任何失控重試/指數補償
• 當您可能有大量連接時，應始終設置斷路器重試配置以限制重試的配額數量。 請參閱Envoy文檔中斷路器的有效重試部分

運行超時演示

對于超時演示，我們將在Envoy中配置路由，如下所示：

"routes": [{"timeout_ms": 0,"prefix": "/","auto_host_rewrite": true,"cluster": "httpbin_service","timeout_ms": 3000}

此配置為通過此路由到達httpbin_service集群的所有呼叫設置了全局（即包括所有重試）3s超時。

每當處理超時時，我們都必須了解源自邊緣的請求的整體全局超時。 我們會發現自己非常難以調試，因為隨著我們對網絡調用圖的深入了解，超時不會逐漸減少。 換句話說，當您瀏覽調用圖時，在調用圖中更深的服務調用的服務超時應小于先前服務的調用：

Envoy可以幫助傳播超時信息，而gRPC之類的協議可以傳播deadline信息。 在繼續閱讀本系列文章時，我們將看到如何使用Istio Mesh控制Envoy代理，而控制平面可以幫助我們進行故障注入以發現超時異常。

如果您已經運行了先前的演示，請確保對此（或任何）演示重新開始。 對于每個演示，我們都有不同的Envoy配置，并希望確保每次都從干凈的開始。

首先停止任何現有的演示：

./docker-stop.sh

現在讓我們進行timeouts演示：

./docker-run.sh -d timeouts

現在，讓我們行使客戶端通過一個調用，這將創下一個HTTP端點應該推遲了大約5秒的響應。 此延遲應足以觸發使節超時。 我們將使用curl.sh腳本，該腳本設置為在演示容器內調用curl。

./curl.sh -vvvv localhost:15001/delay/5

我們應該看到類似以下的輸出：

* Hostname was NOT found in DNS cache * Trying ::1... * connect to ::1 port 15001 failed: Connection refused * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 15001 (#0) > GET /delay/5 HTTP/1.1 > User-Agent: curl/7.35.0 > Host: localhost:15001 > Accept: */* > < HTTP/1.1 504 Gateway Timeout < content-length: 24 < content-type: text/plain < date: Thu, 25 May 2017 06:13:53 GMT * Server envoy is not blacklisted < server: envoy < * Connection #0 to host localhost left intact upstream request timeout

我們看到我們的請求已超時！

讓我們檢查Envoy的統計信息：

./get-envoy-stats.sh | grep timeout

在這里，我們看到1個請求（我們發送的那個！）被Envoy超時了。

cluster.httpbin_service.upstream_cx_connect_timeout: 0 cluster.httpbin_service.upstream_rq_per_try_timeout: 0 cluster.httpbin_service.upstream_rq_timeout: 1 http.admin.downstream_cx_idle_timeout: 0 http.egress_http.downstream_cx_idle_timeout: 0

如果我們以較小的延遲這次發送請求，則應該看到該呼叫通過：

./curl.sh -vvvv localhost:15001/delay/2* Hostname was NOT found in DNS cache * Trying ::1... * connect to ::1 port 15001 failed: Connection refused * Trying 127.0.0.1... * Connected to localhost (127.0.0.1) port 15001 (#0) > GET /delay/2 HTTP/1.1 > User-Agent: curl/7.35.0 > Host: localhost:15001 > Accept: */* > < HTTP/1.1 200 OK * Server envoy is not blacklisted < server: envoy < date: Thu, 25 May 2017 06:15:41 GMT < content-type: application/json < access-control-allow-origin: * < access-control-allow-credentials: true < x-powered-by: Flask < x-processed-time: 2.00246119499 < content-length: 309 < via: 1.1 vegur < x-envoy-upstream-service-time: 2145 < {"args": {}, "data": "", "files": {}, "form": {}, "headers": {"Accept": "*/*", "Connection": "close", "Host": "httpbin.org", "User-Agent": "curl/7.35.0", "X-Envoy-Expected-Rq-Timeout-Ms": "3000"}, "origin": "68.3.84.124", "url": "http://httpbin.org/delay/2" } * Connection #0 to host localhost left intact

還要注意，Envoy傳播超時頭，以便上游服務對預期的情況有所了解。

系列

請繼續關注 ！ 第三部分跟蹤應該很快著陸！

翻譯自: https://www.javacodegeeks.com/2017/05/microservices-patterns-envoy-proxy-part-ii-timeouts-retries.html

envoy重試

總結

以上是生活随笔為你收集整理的envoy重试_具有Envoy代理的微服务模式，第二部分：超时和重试的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。