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

本博客是深入研究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)的熔斷功能。有意進(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)查看它。

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

運(yùn)行熔斷器演示，請(qǐng)熟悉演示框架，然后運(yùn)行：

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

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

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

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

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

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

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

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

我們的設(shè)置并沒(méi)有多大意義;我們不能有3個(gè)并發(fā)重試，因?yàn)槲覀冎辉试S1個(gè)HTTP連接和1個(gè)排隊(duì)請(qǐng)求。

我們實(shí)際上沒(méi)有為此演示制定任何重試政策;我們可以在重試演示中看到重試。

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

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

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

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

如果我們查看./circuit-breaker/http-client.env設(shè)置文件，我們將看到最初我們將開(kāi)始運(yùn)行單個(gè)線程，該線程創(chuàng)建一個(gè)連接并進(jìn)行五次調(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

我們來(lái)驗(yàn)證一下。運(yùn)行演示：

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

這將啟動(dòng)了客戶端應(yīng)用程序，并啟動(dò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)！讓我們通過(guò)以下方式查看：

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

這將顯示我們配置的名為httpbin_service的上游群集的度量標(biāo)準(zhǔn)。快速瀏覽一下這些統(tǒng)計(jì)數(shù)據(jù)，并在Envoy文檔中查找它們的含義。需要注意的重要事項(xiàng)在這里提到：

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個(gè)http / 1連接，有5個(gè)請(qǐng)求（總數(shù)），其中5個(gè)以HTTP 2xx（甚至200個(gè)）結(jié)束。大！但是如果我們嘗試使用兩個(gè)并發(fā)連接會(huì)發(fā)生什么？

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

./reset-envoy-stats.sh
OK

讓我們用2個(gè)線程發(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]

我們啟動(dòng)的一個(gè)線程中有5個(gè)成功，但其中另外一個(gè)線程一個(gè)都沒(méi)有成功！該線程的所有5個(gè)請(qǐng)求都失敗了！讓我們?cè)倏纯磂nvoy的統(tǒng)計(jì)數(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

從這個(gè)輸出中我們可以看到只有一個(gè)連接成功！我們最終得到5個(gè)請(qǐng)求，導(dǎo)致HTTP 200和5個(gè)請(qǐng)求以HTTP 503結(jié)束。我們還看到upstream_rq_pending_overflow已經(jīng)增加到5.這表明斷路器在這里完成了它的工作。它會(huì)使任何與我們的配置設(shè)置不匹配的調(diào)用短路。

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

讓我們運(yùn)行一些類(lèi)似的測(cè)試來(lái)運(yùn)行max_pending_requests設(shè)置。

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

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

我們想要做的是模擬在單個(gè)HTTP連接上同時(shí)發(fā)生的多個(gè)請(qǐng)求（因?yàn)槲覀冎辉试Smax_connections為1）。我們期望請(qǐng)求排隊(duì)，但是Envoy應(yīng)該拒絕排隊(duì)的消息，因?yàn)槲覀儗ax_pending_requests設(shè)置為1。我們想要設(shè)置隊(duì)列深度的上限，目的不允許重試風(fēng)暴，惡意下游請(qǐng)求，DoS和我們系統(tǒng)中的bug。

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

./reset-envoy-stats.sh
OK

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

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]

我們的四個(gè)要求失敗了......讓我們查看envoy的統(tǒng)計(jì)數(shù)據(jù):

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

果然，我們看到我們的4個(gè)請(qǐng)求被短路了：

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對(duì)集群的短路和批量處理線程有什么斷路設(shè)施，但是如果集群中的節(jié)點(diǎn)完全崩潰（或者似乎下降）怎么辦？

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

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

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

./reset-envoy-stats.sh
OK

接下來(lái)，讓我們使用一個(gè)URL來(lái)調(diào)用我們的客戶端，該URL將返回HTTP 500結(jié)果。我們將發(fā)起十次調(diào)用，因?yàn)槲覀兊漠惓z測(cè)將檢查5個(gè)連續(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個(gè)會(huì)返回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)計(jì)數(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檢測(cè)！我們還從負(fù)載均衡組中刪除了該主機(jī)。