使用 Envoy 作为 sidecar 代理的微服务模型 - 1. Circuit Breaker

摘要：将流量直接发送到服务器以帮助处理线路中断。 请致电我们的服务人员。 您将看到以下输出： 还可以看到有 5 次调用成功。

本博客是深入研究 Envoy Proxy 和 Istio.io 并解释如何以更复杂的方式连接和管理微服务的系列文章的一部分。部门。

以下是接下来几部分的一些想法（链接发布后我将立即更新）：

断路器（第 1 部分）

重新尝试/超时（第 2 部分）

分布式跟踪（第 3 部分）

收集 Prometheus 指标（第 4 部分）

速率限制器（第 5 部分）

p>第 1 部分 - 使用 Envoy 代理进行 Fuse

在第一篇博文中，我将介绍 Envoy 代理实现的 Fuse 功能。 这是一个故意简单的演示，旨在帮助更详细地解释模式和用法。 下载此演示的源代码并按照说明进行操作。

该演示由客户端和服务组成。 客户端是一个 Java http 应用程序，它模拟对“上游”服务的 http 调用（请注意此处以及整个存储库中 Envoy 术语的使用）。 客户端打包在 docker.io/ceposta/http-envoy-client:latest 上的 Docker 映像中。 除了 http-client Java 应用程序之外，还有一个 Envoy 代理实例。 在此部署模型中，Envoy 被部署为服务的 sidecar（在本例中为 http 客户端）。 当 http- 客户端发出出站调用（向“上游”服务）时，所有调用都会通过 Envoy 代理 sidecar。

这些示例中的“上游”服务是 httpbin.org。 httpbin.org 允许您轻松模拟 HTTP 服务的行为。 太神奇了，如果你还没有看过，请看一下。

这个保险丝该演示有自己的 envoy.json 配置文件。 我们强烈建议您查看配置文件每个部分的参考文档，以了解完整的配置。 datawire.io 的优秀人员也对 Envoy 及其配置进行了精彩的介绍，因此请务必查看。

运行断路器演示

要运行断路器演示，请熟悉演示框架，然后运行以下命令：

./docker [ k4]run.sh -d Circuit-breaker

断路器的 Envoy 配置如下所示（完整配置为（请参阅此处）。

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

使用此配置文件：您可以实现以下功能：

用于限制对上游集群的访问的 HTTP/1 连接数。 如果超过设定的限制，连接将被短路。

限制在连接可用之前排队/等待的请求数量，如果超出设置的限制，则将其缩短。

限制任何给定时间的并发重试总数（假设设置了重试策略）可以有效地强制执行重试配额。

让我们看一下每个配置。 我们暂时忽略最大重试设置有两个原因。

这个设置没有多大意义。 它只允许 1 个 HTTP 连接和 1 个排队请求，因此不可能同时重试 3 次。

这个演示实际上没有重试策略。 您可以在重试演示中看到重试。

不管怎样，这里的重试设置很可能会导致大的重试风暴-可以避免。 这是一个重要的设置，所以让我们回到重试演示。

max_connections

看看是否太多当多个线程尝试建立与上游集群的同时连接时，特使会执行操作。

回想一下，上游 httbin 集群的断路器配置如下所示（请参阅此处的完整配置）：

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

./Circuit-breaker/http-client.env settings 看文件，最初是一个单线程开始运行，创建一个连接，进行 5 次调用并关闭它。

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

让我们检查一下。 运行演示：

./docker-run.sh -dCircuit-breaker

这将启动客户端应用程序并启动 Envoy 代理。 将流量直接发送到 Envoy 代理，以便 Envoy 代理可以处理断路情况。 让我们调用服务：

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

接下来的输出：

使用 num 线程：1Starting pool-1-thread-1 with numCalls=5 LateBetweenCalls=0 url=http://localhost:15001/getmixedRespTimes=falsepool-1-thread-1:successes=[5],failures=[0],duration=[545ms]

您可以检查多达5. 调用成功。

让我们看一下 Envoy 收集的指标：

./get-envoy-stats.sh

Envoy 收集的内容我们收集了很多跟踪指标！ 让我们检查一下：

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

这将显示 httpbin_service 指标标准 您将看到配置的上游集群命名为 . 快速浏览一下这些统计数据并了解它们在 Envoy 文档中的含义。 需要注意的要点是：

cluster.httpbin_service.upstream_cx_http1_total：1cluster.httpbin_service.upstream_rq_total：5cluster.httpbin_service.upstream_rq_200：5cluster.httpbin_service.upstream_rq_2xx：5cluster.httpbin_service.upstream_rq_pending_overflow：0cluster.httpbin_service。  upload_rq_retry: 0

这表示有 1 个 http/1 连接，5 个请求（总共），其中 5 个以 HTTP 2xx（或我是 200）结尾。 大的！ 但是如果我们尝试同时使用两个连接会发生什么？

首先，让我们重置统计信息：

。/reset-envoy-stats.shOK

让我们在两个线程中运行这些调用：

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

您将看到以下输出：

using num thread: 2Starting pool-1 [ k4]thread[ k4]1 numCalls=5 DelayBetweenCalls=0 url=http://localhost:15001/getmixedRespTimes=falseStarting 池-1-线程-2 numCalls=5 DelayBetweenCalls=0 url= http:// localhost:15001 /getmixedRespTimes=falsepool-1-线程-1：成功=[0]，失败=[5]，持续时间=[123ms]池-1-线程- 2：成功= [5]，failures=[0]，duration=[513ms]

启动的五个线程成功，但其他线程均未成功。 ！ 该线程的所有 5 个请求均失败。 让我们再看一下特使的统计数据。

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

您将看到以下输出：

cluster.httpbin_service 。 upload_cx_http1_total：1cluster.httpbin_service.upstream_rq_total：5cluster.httpbin_service.upstream_rq_200：5cluster.httpbin_service.upstream_rq_2xx：5cluster.httpbin_service.upstream_rq_503：5cluster.httpbin_service.upstream_rq_pending_over：流：.httpbin_service.upstream_rq_retry：0

在此输出中，您可以看到只有一次连接成功。 五个请求以 HTTP 200 结束，五个请求以 HTTP 503 结束。 您还可以看到upstream_rq_pending_overflow已增加到5。 这表明断路器在这里已经完成了它的工作。 任何与配置设置不匹配的呼叫都将被断开。

为了说明 Envoy 的断路功能，我们将 max_connections 设置为一个人为的小数字（在本例中为 1）。 这不是一个现实的设置，但我希望它有助于说明这一点。

max_pending_requests

让我们运行一些类似的测试来练习 max_pending_requests 设置。

回想一下，上游 httbin 集群的断路器配置如下所示（请参阅此处的完整配置）：

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

你想做什么这是为了模拟单个 HTTP 连接上同时发生的多个请求（因为 max_connections 只允许为 1）。 我们期望请求排队，但由于我们将 max_pending_requests 设置为 1，Envoy 必须拒绝排队的消息。 我们希望对队列深度设置上限，以不允许出现重试风暴、恶意下游请求、DoS 和系统错误。

继续上一节，让我们重置 Envoy 的统计信息：

./reset-envoy-stats.shOK

一让我们启动一个线程（即一个 HTTP 连接）来调用客户端，但请求将并行发送（默认情况下以 5 个为一批）。 我还想随机化发送延迟，以便可以排队：

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

您将看到以下输出：

Starting pool-1-thread -1 with numCalls=5 ParallelSends= truelateBetweenCalls=0 url=http://localhost:15001/getmixedRespTimes=truepool-2-thread-3：使用延迟：3pool-2-thread-2：使用延迟： 0pool-2-thread-1：使用延迟：2pool-2-thread-4：使用延迟：4pool-2-线程-5：使用延迟：0个已完成批次0池-1-线程-1：成功=[1]，失败=[4]，持续时间=[4242ms]

我们的四个要求失败了...让我们检查一下 envoy 统计信息：

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

正如预期，您可以看到 4 个请求被缩短：

cluster.httpbin_service.upstream_rq_pending_active: 0cluster.httpbin_service.upstream_rq_pending_failure_eject : 0cluster.httpbin_service.upstream_rq_pending_overflow: 4cluster。   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.shOK

然后调用客户端如下：这是返回 HTTP 500 结果的 URL，对 5 个连续 5xx 响应进行 10 次调用作为异常检测检查，因此，启动 5 次以上的调用：

docker exec -it java [ k4] jar http-client.jar"

您将看到类似以下内容的响应，其中所有调用都将失败（正如预期，其中至少有 5 个返回 HTTP 500）

使用线程计数：1Starting pool-1-thread-1 with numCalls=10ParallelSends=false LateBetweenCalls=0 url=http:// localhost:15001/status/500mixedRespTimes=falsepool -1 -线程-1：成功=[0]，失败res=[10],uration=[929ms]

接下来，让我们检查 Envoy 统计数据，看看发生了什么。

./get-envoy[ k4]stats.sh | grep cluster.httpbin_service | grep 异常值

cluster.httpbin_service.outlier_detection.ejections_active：0cluster.httpbin_service.outlier_detection.ejections_consecutive_5xx ：1cluster.httpbin_service.outlier_detection.ejections_overflow：0cluster.httpbin_service.outlier_detection。ejections_success_rate：0cluster.httpbin_service.outlier_detection.ejections_total：1

连续5xx检测表明电量不足。 我还将该主机从负载均衡组中删除。