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

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

這是接下來(lái)幾個(gè)部分的想法（將在發(fā)布時(shí)更新鏈接):

斷路器（第一部分）

重試/超時(shí)（第二部分）

分布式跟蹤（第三部分）

Prometheus的指標(biāo)收集（第四部分）

rate limiter（第五部分）

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

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

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

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

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

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

    }

這里我們?cè)贖TTP狀態(tài)為5xx時(shí)重試最多3次。

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

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

./docker-stop.sh

現(xiàn)在開(kāi)始運(yùn)行重試demo:

./docker-run.sh -d retries

現(xiàn)在讓我們通過(guò)一次調(diào)用來(lái)運(yùn)行客戶端，該調(diào)用將觸發(fā)應(yīng)該返回HTTP 500錯(cuò)誤的HTTP端點(diǎn)。我們將使用curl.sh腳本，該腳本設(shè)置為在我們的演示容器中調(diào)用curl。

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

我們將會(huì)看到類似的輸出：

* 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

我們?cè)谶@里看到由于HTTP 500錯(cuò)誤，envoy重試了3次。

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

對(duì)于重試，需要注意以下幾點(diǎn)：

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

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

對(duì)于超時(shí)演示，我們將在Envoy中配置我們的路由，如下所示：

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

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

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

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

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

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

./docker-stop.sh

現(xiàn)在開(kāi)始運(yùn)超時(shí)demo:

./docker-run.sh -d timeouts

現(xiàn)在讓我們用一個(gè)調(diào)用來(lái)運(yùn)行客戶端，該調(diào)用將觸發(fā)HTTP端點(diǎn)，該端點(diǎn)應(yīng)該將響應(yīng)延遲大約5秒。此延遲應(yīng)足以觸發(fā)envoy超時(shí)。我們將使用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

我們看到我們的請(qǐng)求是超時(shí)的。

下面我們檢查以下envoy的狀態(tài):

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

在這里，我們看到1個(gè)請(qǐng)求（我們發(fā)送的請(qǐng)求！）由Envoy超時(shí)。

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ā)送請(qǐng)求，這次延遲較小，我們應(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

另請(qǐng)注意，Envoy會(huì)傳播超時(shí) headers，以便上游服務(wù)可以了解所期望的內(nèi)容。