使用Envoy 作Sidecar Proxy的微服務模式-2.超時和重試

vibiu 發布于2019-07-01 17:37 / 530人閱讀

摘要：在第二部分中，我們將詳細介紹如何啟用其他彈性功能，如超時和重試。在此部署模型中，被部署為服務的在本例中為客戶端。這些示例的上游服務是。它們可以幫助傳播故障或對可能正在掙扎的內部服務造成類型攻擊。此延遲應足以觸發超時。

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

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

斷路器（第一部分）

重試/超時（第二部分）

分布式跟蹤（第三部分）

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

rate limiter（第五部分）

第一部分 - 使用envoy proxy 實現超時和重試

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

該演示由一個客戶端和一個服務組成。客戶端是一個Java http應用程序，模擬對“上游”服務進行http調用（注意，我們在這里使用Envoys術語，并貫穿整個repo）。客戶端打包在docker.io/ceposta/http-envoy-client:latest的Docker鏡像中。除了http-client Java應用程序之外，還有Envoy Proxy的一個實例。在此部署模型中，Envoy被部署為服務的sidercar（在本例中為http客戶端）。當http-client進行出站調用（到“上游”服務）時，所有調用都通過Envoy Proxy sidercar。

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

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

運行重試 demo

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

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

    }

這里我們在HTTP狀態為5xx時重試最多3次。

如果您已經運行過以前的演示，請確保為此（或任何）演示開始一個新的初始化狀態。我們為每個演示提供不同的Envoy配置，并希望確保每次都從一個新的初始化狀態開始。

首先停止已經存在的demo:

./docker-stop.sh

現在開始運行重試demo:

./docker-run.sh -d retries

現在讓我們通過一次調用來運行客戶端，該調用將觸發應該返回HTTP 500錯誤的HTTP端點。我們將使用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 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次。

如果從另外一個角度看待，重試可能會對您的服務架構產生有害影響。它們可以幫助傳播故障或對可能正在掙扎的內部服務造成DDoS類型攻擊。

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

envoy將通過抖動進行自動指數重試。有關更多信息，請參閱文檔

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

運行超時 demo

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

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

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

每當處理超時時，我們必須知道源自邊緣的請求的整體全局超時。當我們深入到網絡調用圖中時，我們發現自己很難調試超時不會逐漸減少的情況。換句話說，當您瀏覽調用圖時，調用圖中更深層次的服務調用的服務超時應該小于先前服務的調用：

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

首先停止已經存在的demo:

./docker-stop.sh

現在開始運超時demo:

./docker-run.sh -d timeouts

現在讓我們用一個調用來運行客戶端，該調用將觸發HTTP端點，該端點應該將響應延遲大約5秒。此延遲應足以觸發envoy超時。我們將使用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會傳播超時 headers，以便上游服務可以了解所期望的內容。

云服務器 GPU云服務器云服務器超時請稍后重試 Proxy模式 Sidecar Envoy

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/33140.html

使用Envoy 作Sidecar Proxy的微服務模式-3.分布式追蹤

摘要：在第三部分中，我們將了解如何在服務網格中啟用分布式跟蹤。在此部署模型中，被部署為服務的在本例中為客戶端。會在服務調用之間添加一些追蹤，并發送到或您的跟蹤提供商目前支持和。這些示例的上游服務是。本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分） ...

Fundebug 2019-07-01 17:37 評論0 收藏0
使用Envoy 作Sidecar Proxy的微服務模式-1.熔斷

摘要：我們將直接向發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務我們將看到以下的輸出我們也能看到我們五次的調用成功了。本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分）重試/超時（第二部分）分布式跟蹤（第三部分） Prometheus的指標...

NotFound 2019-07-01 17:37 評論0 收藏0
使用Envoy 作Sidecar Proxy的微服務模式-1.熔斷

摘要：我們將直接向發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務我們將看到以下的輸出我們也能看到我們五次的調用成功了。本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分）重試/超時（第二部分）分布式跟蹤（第三部分） Prometheus的指標...

Drummor 2019-06-28 17:04 評論0 收藏0
使用Envoy 作Sidecar Proxy的微服務模式-5.rate limiter

摘要：為安裝過濾器的偵聽器上的每個新請求調用服務，路由表指定應調用服務。使用了令牌桶算法來限流。本博客是深入研究Envoy Proxy和Istio.io 以及它如何實現更優雅的方式來連接和管理微服務系列文章的一部分。這是接下來幾個部分的想法（將在發布時更新鏈接): 斷路器（第一部分）重試/超時（第二部分）分布式跟蹤（第三部分） Prometheus的指標收集（第四部分） rate ...

CocoaChina 2019-07-01 17:36 評論0 收藏0
微服務架構下 Service Mesh 會是閃亮的明天嗎？

摘要：以下內容根據魏巍分享整編，希望對大家了解有所幫助。數據平面由一組智能代理組成，代理部署為，其控制微服務之間所有的網絡通信。 7月7日，時速云企業級容器 PaaS 技術沙龍第 10 期在上海成功舉辦，時速云容器架構負責人魏巍為大家詳細講解了 Service Mesh 中代表性的實踐方案、并以 Istio 為例詳細講解了 Service Mesh 中的技術關鍵點，包括 Istio 控制平面...

hlcfan 2019-07-25 14:20 評論0 收藏0