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

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

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

斷路器（第一部分）

重試/超時（第二部分）

分布式跟蹤（第三部分）

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

rate limiter（第五部分）

這篇第一篇博文向您介紹了Envoy Proxy實現(xiàn)的熔斷功能。有意進行一些簡單的演示，因此我可以多帶帶說明模式和用法。請下載此演示的源代碼并按照說明進行操作！

該演示由一個客戶端和一個服務(wù)組成。客戶端是一個Java http應(yīng)用程序，模擬對“上游”服務(wù)進行http調(diào)用（注意，我們在這里使用Envoys術(shù)語，并貫穿整個repo）。客戶端打包在docker.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)該檢查一下。

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

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

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

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

該配置文件允許我們實現(xiàn)下面的功能：

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

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

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

我們來看看每個配置。我們現(xiàn)在將忽略最大重試次數(shù)設(shè)置有兩個原因：

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

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

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

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

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

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

如果我們查看./circuit-breaker/http-client.env設(shè)置文件，我們將看到最初我們將開始運行單個線程，該線程創(chuàng)建一個連接并進行五次調(diào)用并關(guān)閉。

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

這將啟動了客戶端應(yīng)用程序，并啟動了Envoy Proxy。我們將直接向Envoy Proxy發(fā)送流量，以使其幫幫助處理熔斷。讓我們調(diào)用我們的服務(wù)：

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]

我們也能看到我們五次的調(diào)用成功了。

讓我們看一下，Envoy為我們收集的metrics指標(biāo)：

./get-envoy-stats.sh

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

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

這將顯示我們配置的名為httpbin_service的上游群集的度量標(biāo)準(zhǔn)。快速瀏覽一下這些統(tǒng)計數(shù)據(jù)，并在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個請求（總數(shù)），其中5個以HTTP 2xx（甚至200個）結(jié)束。大！但是如果我們嘗試使用兩個并發(fā)連接會發(fā)生什么？

首先，讓我們重置統(tǒng)計數(shù)據(jù)：

./reset-envoy-stats.sh
OK

讓我們用2個線程發(fā)起這些調(diào)用：

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

我們應(yīng)該可以看到如下的輸出：

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的統(tǒng)計數(shù)據(jù)：

./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個請求，導(dǎo)致HTTP 200和5個請求以HTTP 503結(jié)束。我們還看到upstream_rq_pending_overflow已經(jīng)增加到5.這表明斷路器在這里完成了它的工作。它會使任何與我們的配置設(shè)置不匹配的調(diào)用短路。

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

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

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

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

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

繼續(xù)上一節(jié)，讓我們重置特使的統(tǒng)計數(shù)據(jù)：

./reset-envoy-stats.sh
OK

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

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

我們應(yīng)該看到如下的輸出：

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的統(tǒng)計數(shù)據(jù):

./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

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

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

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

讓我們測試一下這個案例，看看會發(fā)生什么。首先，重置統(tǒng)計數(shù)據(jù)：

./reset-envoy-stats.sh
OK

接下來，讓我們使用一個URL來調(diào)用我們的客戶端，該URL將返回HTTP 500結(jié)果。我們將發(fā)起十次調(diào)用，因為我們的異常檢測將檢查5個連續(xù)的5xx響應(yīng)，因此我們將要發(fā)起多于5次的調(diào)用。

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

我們應(yīng)該看到這樣的響應(yīng)，其中所有調(diào)用都失敗了（正如我們所期望的那樣：其中至少有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]

現(xiàn)在讓我們檢查一下Envoy的統(tǒng)計數(shù)據(jù)，看看究竟發(fā)生了什么：

./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

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