使用Envoy代理的微服务模式，第二部分：超时和重试

该博客是系列文章的一部分&＃xff0c;该系列文章更深入地介绍了Envoy Proxy和Istio.io &＃xff0c;以及它如何实现更优雅的连接和管理微服务的方式。 跟随我&＃64;christianposta &＃xff0c;紧跟这些博客文章的发布。

• 什么是Envoy代理 &＃xff0c;它如何工作&＃xff1f;
• 如何使用Envoy Proxy实现一些基本模式&＃xff1f;
• Istio Mesh如何适合这张照片
• Istio Mesh的工作方式&＃xff0c;以及如何通过Envoy跨集群启用高阶功能
• Istio Mesh身份验证的工作方式

这是接下来几部分的想法&＃xff08;将在发布时更新链接&＃xff09;&＃xff1a;

• 断路器&＃xff08;第一部分&＃xff09;
• 重试/超时&＃xff08;第二部分&＃xff09;
• 分布式跟踪&＃xff08;第三部分&＃xff09;
• 普罗米修斯的度量标准收集&＃xff08;第四部分&＃xff09;
• 服务发现&＃xff08;第五部分&＃xff09;
• 接下来的部分将介绍更多的客户端功能&＃xff08;请求阴影&＃xff0c;TLS等&＃xff09;&＃xff0c;只是不确定哪些部分将是&＃xff1a;:)

第二部分– Envoy代理的超时和重试

第一篇博客文章向您介绍了Envoy Proxy的断路功能实现 。 在第二部分中&＃xff0c;我们将仔细研究如何启用额外的弹性功能&＃xff0c;例如超时和重试。 这些演示故意是简单的&＃xff0c;因此我可以分别说明这些模式和用法。 请下载此演示的源代码&＃xff0c;然后继续&＃xff01;

该演示由客户端和服务组成。 客户端是一个Java http应用程序&＃xff0c;它模拟对“上游”服务进行http调用&＃xff08;请注意&＃xff0c;我们在这里使用Envoys术语&＃xff0c;并且贯穿此repo &＃xff09;。 客户端打包在名为docker.io/ceposta/http-envoy-client:latest的Docker映像中。 http-client Java应用程序旁边是Envoy Proxy的实例。 在此部署模型中&＃xff0c;Envoy与服务&＃xff08;在本例中为http客户端&＃xff09;一起作为边车进行了部署。 当http客户端发出出站呼叫&＃xff08;到“上游”服务&＃xff09;时&＃xff0c;所有呼叫都通过Envoy代理端进行。

这些示例的“上游”服务是httpbin.org 。 httpbin.org允许我们轻松模拟HTTP服务行为。 太棒了&＃xff0c;所以如果您没有看过&＃xff0c;请检查一下。

retries和timeouts演示都有自己的 envoy.json配置文件。 我绝对建议您查看配置文件各部分的参考文档&＃xff0c;以帮助您了解完整的配置。 datawire.io的好伙伴还为Envoy及其配置提供了不错的介绍 &＃xff0c;您也应该查看一下。

运行重试演示

对于重试演示&＃xff0c;我们将在Envoy中配置路由&＃xff0c;如下所示&＃xff1a;

"routes": [{"timeout_ms": 0,"prefix": "/","auto_host_rewrite": true,"cluster": "httpbin_service","retry_policy": {"retry_on": "5xx","num_retries": 3}}

在这里&＃xff0c;我们说要对5xx的HTTP状态最多重试3次。

如果您已经运行了以前的演示&＃xff0c;请确保对此&＃xff08;或任何&＃xff09;演示重新开始。 对于每个演示&＃xff0c;我们都有不同的Envoy配置&＃xff0c;并希望确保每次都从干净的开始。

首先停止任何现有的演示&＃xff1a;

./docker-stop.sh

现在让我们进行retries演示&＃xff1a;

./docker-run.sh -d retries

现在&＃xff0c;让我们行使客户端通过一个调用&＃xff0c;这将创下一个HTTP端点应返回一个HTTP 500错误。 我们将使用curl.sh脚本&＃xff0c;该脚本被设置为在演示容器内调用curl。

./curl.sh -vvvv localhost:15001/status/500

我们应该看到这样的东西&＃xff1a;

* Hostname was NOT found in DNS cache
* Trying ::1...
* connect to ::1 port 15001 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 15001 (#0)
> GET /status/500 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:15001
> Accept: */*
>
* Server envoy is not blacklisted
<
* Connection #0 to host localhost left intact

大&＃xff01; 现在&＃xff0c;让我们检查Envoy为我们做了什么&＃xff1a;

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

cluster.httpbin_service.retry.upstream_rq_500: 3
cluster.httpbin_service.retry.upstream_rq_5xx: 3
cluster.httpbin_service.upstream_rq_retry: 3
cluster.httpbin_service.upstream_rq_retry_overflow: 0
cluster.httpbin_service.upstream_rq_retry_success: 0

好极了&＃xff01; 我们在这里看到&＃xff0c;由于HTTP 500错误&＃xff0c;特使已重试了3次。

如果天真的处理&＃xff0c;重试会对您的服务体系结构产生有害影响。 它们可以帮助传播故障或对可能陷入困境的内部服务造成DDoS类型的攻击。

重试时要注意以下几点&＃xff1a;

• Envoy会自动进行带抖动的指数重试。 有关更多信息&＃xff0c;请参阅文档
• 您可以设置重试超时&＃xff08;每次重试超时&＃xff09;&＃xff0c;但是总路由超时&＃xff08;为路由表配置&＃xff1b;请参阅timeouts演示以获取确切配置&＃xff09;仍将保留/应用&＃xff1b; 这是为了短路任何失控重试/指数补偿
• 当您可能有大量连接时&＃xff0c;应始终设置断路器重试配置以限制重试的配额数量。 请参阅Envoy文档中断路器部分中的有效重试

运行超时演示

对于超时演示&＃xff0c;我们将在Envoy中配置路由&＃xff0c;如下所示&＃xff1a;

"routes": [{"timeout_ms": 0,"prefix": "/","auto_host_rewrite": true,"cluster": "httpbin_service","timeout_ms": 3000}

此配置为通过此路由到达httpbin_service群集的所有呼叫设置了全局&＃xff08;即&＃xff0c;包括所有重试&＃xff09;3s超时。

每当处理超时时&＃xff0c;我们都必须了解源自边缘的请求的整体全局超时。 我们会发现自己非常难以调试&＃xff0c;因为随着我们对网络调用图的深入了解&＃xff0c;超时不会逐渐减少。 换句话说&＃xff0c;当您浏览调用图时&＃xff0c;在调用图中更深的服务调用的服务超时应该小于先前服务的调用&＃xff1a;

Envoy可以帮助传播超时信息&＃xff0c;而gRPC之类的协议可以传播deadline信息。 在继续本系列文章的过程中&＃xff0c;我们将看到如何使用Istio Mesh控制Envoy代理&＃xff0c;而控制平面可以帮助我们进行故障注入以发现超时异常。

如果您已经运行了以前的演示&＃xff0c;请确保对此&＃xff08;或任何&＃xff09;演示重新开始。 对于每个演示&＃xff0c;我们都有不同的Envoy配置&＃xff0c;并希望确保每次都从干净的开始。

首先停止任何现有的演示&＃xff1a;

./docker-stop.sh

现在让我们进行timeouts演示&＃xff1a;

./docker-run.sh -d timeouts

现在&＃xff0c;让我们行使客户端通过一个调用&＃xff0c;这将创下一个HTTP端点应该推迟了大约5秒的响应。 此延迟应足以触发使节超时。 我们将使用curl.sh脚本&＃xff0c;该脚本被设置为在演示容器内调用curl。

./curl.sh -vvvv localhost:15001/delay/5

我们应该看到类似以下的输出&＃xff1a;

* Hostname was NOT found in DNS cache
* Trying ::1...
* connect to ::1 port 15001 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 15001 (#0)
> GET /delay/5 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:15001
> Accept: */*
>
* Server envoy is not blacklisted
<
* Connection #0 to host localhost left intact
upstream request timeout

我们看到我们的请求已超时&＃xff01;

让我们检查特使统计信息&＃xff1a;

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

在这里&＃xff0c;我们看到1个请求&＃xff08;我们发送的那个&＃xff01;&＃xff09;被Envoy超时了。

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

如果我们以较小的延迟这次发送请求&＃xff0c;则应该看到该呼叫通过&＃xff1a;

./curl.sh -vvvv localhost:15001/delay/2

* Hostname was NOT found in DNS cache
* Trying ::1...
* connect to ::1 port 15001 failed: Connection refused
* Trying 127.0.0.1...
* Connected to localhost (127.0.0.1) port 15001 (#0)
> GET /delay/2 HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:15001
> Accept: */*
>
* Server envoy is not blacklisted
<
{"args": {}, "data": "", "files": {}, "form": {}, "headers": {"Accept": "*/*", "Connection": "close", "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"
}
* Connection #0 to host localhost left intact

还要注意&＃xff0c;Envoy传播超时头&＃xff0c;以便上游服务对预期的情况有所了解。

系列

请继续关注 &＃xff01; 第三部分跟踪应该很快着陆&＃xff01;

翻译自: https://www.javacodegeeks.com/2017/05/microservices-patterns-envoy-proxy-part-ii-timeouts-retries.html