关注分享主机优惠活动
国内外VPS云服务器

使用 Envoy 作为 sidecar 代理的微服务模型 - 2. 超时和重试

摘要:第 2 部分详细介绍了如何启用其他恢复功能,例如超时和重试。 在此部署模型中,客户端(在本例中)被部署为服务。 这些示例中的上游服务是 。 这些可能会传播故障或触发针对可能遇到问题的内部服务的类型攻击。 此延迟应该足以导致超时。

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

以下是接下来几部分的一些想法(链接发布后我将立即更新):

断路器(第 1 部分)

重新尝试/超时(第 2 部分)

分布式跟踪(第 3 部分)

收集 Prometheus 指标(第 4 部分)

速率限制器(第 5 部分)

p>第 1 部分 - 使用 Envoy 代理实现超时和重试

在我们的第一篇博文中,我们将介绍 Envoy 代理的熔断功能的实现。 第 2 部分详细介绍了如何启用额外的恢复功能,例如超时和重试。 这是一个故意简单的演示,旨在帮助更详细地解释模式和用法。 下载此演示的源代码并按照说明进行操作。

该演示由客户端和服务组成。 客户端是一个 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 配置文件。请查看配置文件每个部分的参考文档以了解完整的配置。 /b>

重试演示在 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 配置并以新的状态开始。每次初始化状态。

首先停止现有的演示。再次开始运行演示:

./docker-run.sh -d 重试

接下来,触发返回 HTTP 500 错误的 HTTP 端点。使用配置为在演示容器中调用curl 的curl.sh 脚本运行客户端。-vvvv localhost:15001/status/500

您将看到类似的输出:

* 在 DNS 缓存中找不到主机名* 尝试 ::1.. * 连接到 :: 1 端口 15001 失败:连接被拒绝* 尝试 127.0.0.1...* 连接到本地主机 (127.0.0.1) 端口 15001 (#0) > GET /status/500 HTTP/1.1> User-Agent :curl/ 7.35。 0> 主机: localhost:15001> 接受: */*> < HTTP/1.1 500 内部服务器错误* 服务器特使已列入黑名单 未注册< 服务器: 特使< 日期: 星期四, 2017 年 5 月 25 日 05:55:37 GMT< 内容 [ k4] 类型:text/html;charset=utf-8< access-control-allow-origin:*<access-control-allow-credentials:true<x[ k4]供电-作者:Flask< x-处理-时间:0.000718116760254<内容-长度:0<通过:1.1 vegur<x-envoy-upstream-service[k4 ]time: 684< * 在主机 localhost 上保持连接号 0 不变t

接下来,让我们看看 Envoy 为我们做了什么。

./get-envoy-stats.sh | grep 重试
cluster.httpbin_service.retry.upstream_rq_500: 3cluster.httpbin_service.retry.upstream_rq_5xx: 3cluster.httpbin_service。 upload_rq_retry: 3cluster.httpbin_service.upstream_rq_retry_overflow: 0cluster.httpbin_service.upstream_rq_retry_success: 0

这里可以看到 Envoy 由于 HTTP 500 错误已重试 3 次。

从另一个角度来看,重试会对服务架构产生负面影响。 这些可能会传播故障或对遇到问题的内部服务造成 DDoS 类型的攻击。

重试时,应注意以下事项:

envoy 通过抖动自动执行指数重试。 请参阅文档以获取更多信息。

虽然可以设置重试超时(每次重试超时),但总路由超时(在路由表中设置,具体设置请参见超时演示)仍然没有设置。 保留/应用。 这是为了避免失控重试/指数退避
如果您有大量连接,则应始终设置断路器重试配置以限制重试配额。 请参阅 Envoy 文档的电路部分中的有效重试。

运行超时演示

对于超时演示,请在 Envoy 中配置路由,如下所示:

 "路由": [ { "timeout_ms": 0, "前缀": "/", "auto_host_rewrite": true, "cluster": "httpbin_service", "timeout_ms": 3000 }

此设置使通过此路由全局调用 httpbin_service 集群(即所有重播)。

每当您处理超时时,您都需要了解来自边缘的请求的整体全局超时。当您深入研究时,您会发现很难调试超时不随时间增加的情况。换句话说,当您浏览调用图时,调用图下方的服务调用比其他调用更难调试。服务超时应该小于调用。

envoy。传播超时信息,gRPC 等协议可以传播截止时间信息。在我们继续本系列文章时,我们将向您展示如何使用 Istio Mesh 来控制 Envoy 代理并帮助控制平面检测超时异常。 (或任何)演示。我们为每个演示提供不同的 Envoy 配置,并希望每次都能从新的初始化状态开始

首先停止现有演示:

。 /docker-stop.sh

然后开始运行超时演示:

 ./docker-run.sh -d 超时

现在让我们通过触发 HTTP 端点的调用来运行客户端。该延迟应该足以触发 envoy 超时。 ]vvvv localhost:15001/late/5

您将看到类似于以下内容的输出:

* 找不到主机名。   DNS 缓存* 正在尝试::1...* ::1 无法连接到端口 15001:连接被拒绝* 尝试 127.0.0.1...* 本地主机 (127.0.0.1) 端口 15001 (#0) 连接到 > GET /delay/5 HTTP/ 1.1 > 用户-代理:curl/7.35.0>主机:localhost:15001>接受:*/*><HTTP/1.1 504网关超时<内容-长度:24<内容-类型:文本/ plain < date: Thu, 25 May 2017 06:13:53 GMT* Server envoy 未列入黑名单<server: envoy< * 连接到主机 localhost #0 已留在上游请求超时

您可以看到请求的时间是在外部指定的。

让我们检查以下 Envoy 状态:

./get-envoy-stats.sh | grep timeout

这里我们看到一个请求(我们发送的那个)被 Envoy 超时了。

cluster.httpbin_service.upstream_cx_connect_timeout:0cluster.httpbin_service.upstream_rq_per_try_timeout:0cluster.httpbin_service.upstream_rq_timeout:1http.admin.downstream_cx_idle_timeout:0http.egress_http.downstream_cx_idle_timeout: 0

发送请求,这次应该有更少的延迟,你应该看到以下调用:

./curl.sh [k4 ]vvvv localhost :15001 /delay/2
* 在 DNS 缓存中找不到主机名* 尝试 ::1...* ::1 无法连接到端口 15001:连接被拒绝 * 正在尝试 127.0.0.1... *连接到 localhost (127.0.0.1) 端口 15001 (#0)> GET /delay/2 HTTP/1.1> User-Agent:curl/7.35. 0> 主机: localhost:15001> 接受: */*> < HTTP /1.1 200 OK* 服务器 envoy 未列入黑名单< 服务器:envoy< 日期:2017 年 5 月 25 日,星期四 06:15 :41 GMT< content-type: application/json< access-control-allow[ k4]起源:*<访问-控制-允许-凭证:true<x-供电-:Flask<x-处理-时间:2.00246119499<内容-长度:309 < 通过:1.1 vegur< x-envoy-upstream-service- 时间:2145<{ "args": {}, "数据": "", "文件": {}, "表单": {}, "标题": { "接受": "*/*", "连接": "关闭", "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"}* 连接 #0 到主机本地主机保持不变

另请注意,Envoy 会传播超时标头,以便上游服务知道会发生什么。

未经允许不得转载:主机频道 » 使用 Envoy 作为 sidecar 代理的微服务模型 - 2. 超时和重试

评论 抢沙发

评论前必须登录!