摘要：在第二部分中，我們將詳細介紹如何啟用其他彈性功能，如超時和重試。在此部署模型中，被部署為服務(wù)的在本例中為客戶端。這些示例的上游服務(wù)是。它們可以幫助傳播故障或?qū)赡苷趻暝膬?nèi)部服務(wù)造成類型攻擊。此延遲應(yīng)足以觸發(fā)超時。

本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現(xiàn)更優(yōu)雅的方式來連接和管理微服務(wù)系列文章的一部分。

這是接下來幾個部分的想法（將在發(fā)布時更新鏈接):

斷路器（第一部分）

重試/超時（第二部分）

分布式跟蹤（第三部分）

Prometheus的指標收集（第四部分）

rate limiter（第五部分）

第一篇博文向您介紹了Envoy Proxy的斷路功能實現(xiàn)。在第二部分中，我們將詳細介紹如何啟用其他彈性功能，如超時和重試。有意進行一些簡單的演示，因此我可以多帶帶說明模式和用法。請下載此演示的源代碼并按照說明進行操作！

該演示由一個客戶端和一個服務(wù)組成?？蛻舳耸且粋€Java http應(yīng)用程序，模擬對“上游”服務(wù)進行http調(diào)用（注意，我們在這里使用Envoys術(shù)語，并貫穿整個repo）?？蛻舳舜虬赿ocker.io/ceposta/http-envoy-client:latest的Docker鏡像中。除了http-client Java應(yīng)用程序之外，還有Envoy Proxy的一個實例。在此部署模型中，Envoy被部署為服務(wù)的sidercar（在本例中為http客戶端）。當(dāng)http-client進行出站調(diào)用（到“上游”服務(wù)）時，所有調(diào)用都通過Envoy Proxy sidercar。

這些示例的“上游”服務(wù)是httpbin.org。 httpbin.org允許我們輕松模擬HTTP服務(wù)行為。它很棒，所以如果你沒有看到它，請查看它。

重試和超時演示有自己的envoy.json配置文件。我絕對建議您查看配置文件每個部分的參考文檔，以幫助理解完整配置。 datawire.io的優(yōu)秀人員也為Envoy及其配置提供了一個很好的介紹，你也應(yīng)該檢查一下。

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

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

    }

這里我們在HTTP狀態(tài)為5xx時重試最多3次。

如果您已經(jīng)運行過以前的演示，請確保為此（或任何）演示開始一個新的初始化狀態(tài)。我們?yōu)槊總€演示提供不同的Envoy配置，并希望確保每次都從一個新的初始化狀態(tài)開始。

首先停止已經(jīng)存在的demo:

./docker-stop.sh

現(xiàn)在開始運行重試demo:

./docker-run.sh -d retries

現(xiàn)在讓我們通過一次調(diào)用來運行客戶端，該調(diào)用將觸發(fā)應(yīng)該返回HTTP 500錯誤的HTTP端點。我們將使用curl.sh腳本，該腳本設(shè)置為在我們的演示容器中調(diào)用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

現(xiàn)在我們檢查一下，envoy為我們做了哪些工作：

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

cluster.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錯誤，envoy重試了3次。

如果從另外一個角度看待，重試可能會對您的服務(wù)架構(gòu)產(chǎn)生有害影響。它們可以幫助傳播故障或?qū)赡苷趻暝膬?nèi)部服務(wù)造成DDoS類型攻擊。

對于重試，需要注意以下幾點：

envoy將通過抖動進行自動指數(shù)重試。有關(guān)更多信息，請參閱文檔

您可以設(shè)置重試超時（每次重試超時），但總路由超時（為路由表配置;請參閱超時演示以獲取確切配置）仍將保留/應(yīng)用;這是為了使任何失控的重試/指數(shù)退避短路
您應(yīng)始終設(shè)置斷路器重試配置，以便在可能具有大量連接時限制重試的配額。請參閱Envoy文檔中斷路器部分的有效重試

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

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

此配置為通過此路由到httpbin_service群集的任何調(diào)用設(shè)置全局（即，包括所有重試）3s超時。

每當(dāng)處理超時時，我們必須知道源自邊緣的請求的整體全局超時。當(dāng)我們深入到網(wǎng)絡(luò)調(diào)用圖中時，我們發(fā)現(xiàn)自己很難調(diào)試超時不會逐漸減少的情況。換句話說，當(dāng)您瀏覽調(diào)用圖時，調(diào)用圖中更深層次的服務(wù)調(diào)用的服務(wù)超時應(yīng)該小于先前服務(wù)的調(diào)用：

envoy可以幫助傳播超時信息，像gRPC這樣的協(xié)議可以傳播截止時間信息。隨著我們繼續(xù)本系列，我們將看到如何使用Istio Mesh控制Envoy代理，并且控制平面可以幫助我們進行故障注入以發(fā)現(xiàn)超時異常。

如果您已經(jīng)運行過以前的演示，請確保為此（或任何）演示開始一個新的初始化狀態(tài)。我們?yōu)槊總€演示提供不同的Envoy配置，并希望確保每次都從一個新的初始化狀態(tài)開始。

首先停止已經(jīng)存在的demo:

./docker-stop.sh

現(xiàn)在開始運超時demo:

./docker-run.sh -d timeouts

現(xiàn)在讓我們用一個調(diào)用來運行客戶端，該調(diào)用將觸發(fā)HTTP端點，該端點應(yīng)該將響應(yīng)延遲大約5秒。此延遲應(yīng)足以觸發(fā)envoy超時。我們將使用curl.sh腳本，該腳本設(shè)置為在我們的演示容器中調(diào)用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的狀態(tài):

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

在這里，我們看到1個請求（我們發(fā)送的請求！）由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

如果我們發(fā)送請求，這次延遲較小，我們應(yīng)該看到調(diào)用：

./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會傳播超時 headers，以便上游服務(wù)可以了解所期望的內(nèi)容。