摘要：我們將直接向發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務我們將看到以下的輸出我們也能看到我們五次的調用成功了。

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

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

斷路器（第一部分）

重試/超時（第二部分）

分布式跟蹤（第三部分）

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

rate limiter（第五部分）

這篇第一篇博文向您介紹了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及其配置提供了一個很好的介紹，你也應該檢查一下。

運行熔斷器演示，請熟悉演示框架，然后運行：

./docker-run.sh -d circuit-breaker

熔斷器的Envoy配置如下所示（請參閱此處的完整配置）：

"circuit_breakers": {
  "default": {
    "max_connections": 1,
    "max_pending_requests": 1,
    "max_retries": 3
  }
}

該配置文件允許我們實現下面的功能：

限制我們對上游集群的HTTP / 1連接的數量，如果我們超過設定限制則將它們短路。

限制排隊/等待連接可用的請求數量，如果我們超過設定限制則將它們短路。

限制在任何給定時間的總并發重試次數（假設重試策略已到位）有效地實施重試配額。

我們來看看每個配置。我們現在將忽略最大重試次數設置有兩個原因：

我們的設置并沒有多大意義;我們不能有3個并發重試，因為我們只允許1個HTTP連接和1個排隊請求。

我們實際上沒有為此演示制定任何重試政策;我們可以在重試演示中看到重試。

無論如何，此處的重試設置允許我們避免大型重試風暴 - 在大多數情況下，這可能會在處理與群集中所有實例的連接時出現問題。這是一個重要的設置，我們將回到重試演示。

讓我們看看當應用程序中有太多線程試圖與上游集群建立太多并發連接時，envoy會做什么。

回想一下我們的上游httbin集群的熔斷設置如下所示（請參閱此處的完整配置）：

"circuit_breakers": {
  "default": {
    "max_connections": 1,
    "max_pending_requests": 1,
    "max_retries": 3
  }
}

如果我們查看./circuit-breaker/http-client.env設置文件，我們將看到最初我們將開始運行單個線程，該線程創建一個連接并進行五次調用并關閉。

NUM_THREADS=1
DELAY_BETWEEN_CALLS=0
NUM_CALLS_PER_CLIENT=5
URL_UNDER_TEST=http://localhost:15001/get
MIX_RESPONSE_TIMES=false

我們來驗證一下。運行演示：

./docker-run.sh -d circuit-breaker

這將啟動了客戶端應用程序，并啟動了Envoy Proxy。我們將直接向Envoy Proxy發送流量，以使其幫幫助處理熔斷。讓我們調用我們的服務：

docker exec -it client bash -c "java -jar http-client.jar"

我們將看到以下的輸出：

using num threads: 1
Starting pool-1-thread-1 with numCalls=5 delayBetweenCalls=0 url=http://localhost:15001/get mixedRespTimes=false
pool-1-thread-1: successes=[5], failures=[0], duration=[545ms]

我們也能看到我們五次的調用成功了。

讓我們看一下，Envoy為我們收集的metrics指標：

./get-envoy-stats.sh

Envoy為我們采集了很多的追蹤指標！讓我們通過以下方式查看：

/get-envoy-stats.sh | grep cluster.httpbin_service

這將顯示我們配置的名為httpbin_service的上游群集的度量標準。快速瀏覽一下這些統計數據，并在Envoy文檔中查找它們的含義。需要注意的重要事項在這里提到：

cluster.httpbin_service.upstream_cx_http1_total: 1
cluster.httpbin_service.upstream_rq_total: 5
cluster.httpbin_service.upstream_rq_200: 5
cluster.httpbin_service.upstream_rq_2xx: 5
cluster.httpbin_service.upstream_rq_pending_overflow: 0
cluster.httpbin_service.upstream_rq_retry: 0

這告訴我們我們有1個http / 1連接，有5個請求（總數），其中5個以HTTP 2xx（甚至200個）結束。大！但是如果我們嘗試使用兩個并發連接會發生什么？

首先，讓我們重置統計數據：

./reset-envoy-stats.sh
OK

讓我們用2個線程發起這些調用：

docker exec -it client bash -c "NUM_THREADS=2; java -jar http-client.jar"

我們應該可以看到如下的輸出：

using num threads: 2
Starting pool-1-thread-1 with numCalls=5 delayBetweenCalls=0 url=http://localhost:15001/get mixedRespTimes=false
Starting pool-1-thread-2 with numCalls=5 delayBetweenCalls=0 url=http://localhost:15001/get mixedRespTimes=false
pool-1-thread-1: successes=[0], failures=[5], duration=[123ms]
pool-1-thread-2: successes=[5], failures=[0], duration=[513ms]

我們啟動的一個線程中有5個成功，但其中另外一個線程一個都沒有成功！該線程的所有5個請求都失敗了！讓我們再看看envoy的統計數據：

./get-envoy-stats.sh | grep cluster.httpbin_service

我們將看到如下的輸出：

cluster.httpbin_service.upstream_cx_http1_total: 1
cluster.httpbin_service.upstream_rq_total: 5
cluster.httpbin_service.upstream_rq_200: 5
cluster.httpbin_service.upstream_rq_2xx: 5
cluster.httpbin_service.upstream_rq_503: 5
cluster.httpbin_service.upstream_rq_5xx: 5
cluster.httpbin_service.upstream_rq_pending_overflow: 5
cluster.httpbin_service.upstream_rq_retry: 0

從這個輸出中我們可以看到只有一個連接成功！我們最終得到5個請求，導致HTTP 200和5個請求以HTTP 503結束。我們還看到upstream_rq_pending_overflow已經增加到5.這表明斷路器在這里完成了它的工作。它會使任何與我們的配置設置不匹配的調用短路。

我們將max_connections人為設置為一個小點的數字，在這種情況下為1，為了說明Envoy的斷路功能。這不是一個現實的設置，但希望有助于說明這一點。

讓我們運行一些類似的測試來運行max_pending_requests設置。

回想一下我們的上游httbin集群的熔斷設置如下所示（請參閱此處的完整配置）：

"circuit_breakers": {
  "default": {
    "max_connections": 1,
    "max_pending_requests": 1,
    "max_retries": 3
  }
}

我們想要做的是模擬在單個HTTP連接上同時發生的多個請求（因為我們只允許max_connections為1）。我們期望請求排隊，但是Envoy應該拒絕排隊的消息，因為我們將max_pending_requests設置為1。我們想要設置隊列深度的上限，目的不允許重試風暴，惡意下游請求，DoS和我們系統中的bug。

繼續上一節，讓我們重置特使的統計數據：

./reset-envoy-stats.sh
OK

讓我們啟動1個線程（即1個HTTP連接）調用客戶端，但是并行發送我們的請求（默認情況下是5個批次）。我們還希望隨機化我們發送的延遲，以便事情可以排隊：

docker exec -it client bash -c "NUM_THREADS=1 && PARALLEL_SENDS=true && MIX_RESPONSE_TIMES=true; java -jar http-client.jar"

我們應該看到如下的輸出：

Starting pool-1-thread-1 with numCalls=5 parallelSends=true delayBetweenCalls=0 url=http://localhost:15001/get mixedRespTimes=true
pool-2-thread-3: using delay of : 3
pool-2-thread-2: using delay of : 0
pool-2-thread-1: using delay of : 2
pool-2-thread-4: using delay of : 4
pool-2-thread-5: using delay of : 0
finished batch 0
pool-1-thread-1: successes=[1], failures=[4], duration=[4242ms]

我們的四個要求失敗了......讓我們查看envoy的統計數據:

./get-envoy-stats.sh | grep cluster.httpbin_service | grep pending

果然，我們看到我們的4個請求被短路了：

cluster.httpbin_service.upstream_rq_pending_active: 0
cluster.httpbin_service.upstream_rq_pending_failure_eject: 0
cluster.httpbin_service.upstream_rq_pending_overflow: 4
cluster.httpbin_service.upstream_rq_pending_total: 1

我們已經看到了Envoy對集群的短路和批量處理線程有什么斷路設施，但是如果集群中的節點完全崩潰（或者似乎下降）怎么辦？

Envoy具有“離群值檢測”設置，可以檢測群集中的主機何時不可靠，并且可以完全從群集摘掉它們（一段時間）。需要了解的一個有趣現象是，默認情況下，Envoy會根據負載平衡算法，最多摘除某一數量的不可靠的主機。如果太多（即> 50％）的主機被認為是不健康的，那么Envoy的負載均衡器算法將檢測到一個恐慌閾值，并且只會對所有主機進行負載均衡。此恐慌閾值是可配置的，并且為了獲得斷電功能，可以在嚴重中斷期間為所有主機提供負載（一段時間），您可以配置異常值檢測設置。在我們的示例斷路器）envoy.json配置中，您可以看到以下內容：

outlier_detection" : {
      "consecutive_5xx": 5,
      "max_ejection_percent": 100,
      "interval_ms": 3
    }
    

讓我們測試一下這個案例，看看會發生什么。首先，重置統計數據：

./reset-envoy-stats.sh
OK

接下來，讓我們使用一個URL來調用我們的客戶端，該URL將返回HTTP 500結果。我們將發起十次調用，因為我們的異常檢測將檢查5個連續的5xx響應，因此我們將要發起多于5次的調用。

docker exec -it client bash -c "URL_UNDER_TEST=http://localhost:15001/status/500 && NUM_CALLS_PER_CLIENT=10; java -jar http-client.jar"

我們應該看到這樣的響應，其中所有調用都失敗了（正如我們所期望的那樣：其中至少有5個會返回HTTP 500）：

using num threads: 1
Starting pool-1-thread-1 with numCalls=10 parallelSends=false delayBetweenCalls=0 url=http://localhost:15001/status/500 mixedRespTimes=false
pool-1-thread-1: successes=[0], failures=[10], duration=[929ms]

現在讓我們檢查一下Envoy的統計數據，看看究竟發生了什么：

./get-envoy-stats.sh | grep cluster.httpbin_service | grep outlier

cluster.httpbin_service.outlier_detection.ejections_active: 0
cluster.httpbin_service.outlier_detection.ejections_consecutive_5xx: 1
cluster.httpbin_service.outlier_detection.ejections_overflow: 0
cluster.httpbin_service.outlier_detection.ejections_success_rate: 0
cluster.httpbin_service.outlier_detection.ejections_total: 1

我們可以看到我們斷電了連續5xx檢測！我們還從負載均衡組中刪除了該主機。