Envoy架构概览(4):健康检查和连接池

简介: Envoy架构概览(4):健康检查和连接池

健康检查


主动运行状况检查可以在每个上游群集的基础上进行配置。如服务发现部分所述,主动运行状况检查和SDS服务发现类型齐头并进。但是,即使使用其他服务发现类型,也有其他需要进行主动健康检查的情况。 Envoy支持三种不同类型的健康检查以及各种设置(检查时间间隔,标记主机不健康之前所需的故障,标记主机健康之前所需的成功等):


  • HTTP:在HTTP健康检查期间,Envoy将向上游主机发送HTTP请求。如果主机健康,预计会有200个回应。如果上游主机想立即通知下游主机不再转发流量,则返回503。
  • L3 / L4:在L3 / L4健康检查期间,Envoy会向上游主机发送一个可配置的字节缓冲区。它期望如果主机被认为是健康的,则在响应中回应字节缓冲区。Envoy也支持只连接L3 / L4健康检查。
  • Redis:Envoy将发送一个Redis PING命令并期待一个PONG响应。上游Redis服务器可以使用PONG以外的任何其他响应来引起立即激活的运行状况检查失败。

被动健康检查

Envoy还支持通过异常值检测进行被动健康检查。


连接池交互

浏览此处获取更多信息。


HTTP健康检查过滤器

当部署Envoy网格时,在集群之间进行主动健康检查时,可以生成大量健康检查流量。 Envoy包含一个可以安装在配置的HTTP侦听器中的HTTP健康检查过滤器。这个过滤器有几种不同的操作模式:


  • 不通过:在此模式下,运行状况检查请求永远不会传递到本地服务。Envoy将根据服务器当前的耗尽状态,以200或503响应。
  • 通过:在这种模式下,Envoy会将每个健康检查请求传递给本地服务。预计该服务将返回200或503取决于其健康状况。
  • 通过缓存:在这种模式下,Envoy会将健康检查请求传递给本地服务,但是会将结果缓存一段时间。随后的运行状况检查请求会将缓存的值返回到缓存时间。当达到缓存时间时,下一个运行状况检查请求将被传递给本地服务。操作大网格时,这是推荐的操作模式。Envoy使用持久性连接进行健康检查,健康检查请求对Envoy本身的成本很低。因此,这种操作模式产生了每个上游主机的健康状态的最终一致的视图,而没有使大量的健康检查请求压倒本地服务。

进一步阅读:

  • Health check filter configuration.
  • /healthcheck/fail admin endpoint.
  • /healthcheck/ok admin endpoint.


主动健康检查快速失败

当使用主动健康检查和被动健康检查(异常检测)时,通常使用较长的健康检查间隔来避免大量的主动健康检查流量。在这种情况下,在使用/ healthcheck / fail管理端点时,能够快速排除上游主机仍然很有用。为了支持这个,路由器过滤器将响应x-envoy-immediate-health-check-fail头。如果此报头由上游主机设置,则Envoy将立即将主机标记为主动运行状况检查失败。请注意,只有在主机的集群配置了活动的健康状况检查时才会发生这种情况如果Envoy已通过/ healthcheck / fail admin端点标记为失败,则运行状况检查过滤器将自动设置此标头。


健康检查身份

只需验证上游主机是否响应特定运行状况检查URL,并不一定意味着上游主机是有效的。例如,在云自动扩展或容器环境中使用最终一致的服务发现时,主机可能会消失,然后以相同的IP地址返回,但会以不同的主机类型返回。解决这个问题的一个办法是为每个服务类型设置不同的HTTP健康检查URL。这种方法的缺点是整体配置变得更加复杂,因为每个运行状况检查URL都是完全自定义的。


Envoy HTTP健康检查器支持service_name选项。如果设置了此选项,运行状况检查程序会另外将x-envoy-upstream-healthchecked-cluster响应标头的值与service_name进行比较。如果值不匹配,健康检查不通过。上游运行状况检查过滤器会将x-envoy-upstream-healthchecked-cluster附加到响应标头。附加值由--service-cluster命令行选项确定。


连接池

对于HTTP流量,Envoy支持在基础有线协议(HTTP / 1.1或HTTP / 2)之上分层的抽象连接池。利用过滤器代码不需要知道底层协议是否支持真正的复用。实际上,底层实现具有以下高级属性:


HTTP / 1.1

HTTP / 1.1连接池根据需要获取上游主机的连接(达到断路极限)。当连接可用时,请求被绑定到连接上,或者是因为连接完成处理先前的请求,或者是因为新的连接准备好接收其第一请求。 HTTP / 1.1连接池不使用流水线,因此如果上游连接被切断,则只有一个下游请求必须被重置。


HTTP / 2

HTTP / 2连接池获取与上游主机的单个连接。所有请求都通过此连接复用。如果收到一个GOAWAY帧,或者如果连接达到最大流限制,连接池将创建一个新的连接并且耗尽现有连接。 HTTP / 2是首选的通信协议,因为连接很少被切断。


健康检查交互

如果将Envoy配置为进行主动或被动运行状况检查,则将代表从正常状态转换为不健康状态的主机关闭所有连接池连接。如果主机重新进入负载均衡旋转,它将创建新的连接,这将最大限度地处理坏流量(由于ECMP路由或其他)的机会。

相关文章
|
1月前
|
数据管理 Nacos 开发者
"Nacos架构深度解析:一篇文章带你掌握业务层四大核心功能,服务注册、配置管理、元数据与健康检查一网打尽!"
【10月更文挑战第23天】Nacos 是一个用于服务注册发现和配置管理的平台,支持动态服务发现、配置管理、元数据管理和健康检查。其业务层包括服务注册与发现、配置管理、元数据管理和健康检查四大核心功能。通过示例代码展示了如何在业务层中使用Nacos,帮助开发者构建高可用、动态扩展的微服务生态系统。
110 0
|
5月前
|
存储 分布式计算 大数据
从零到一建设数据中台 - 架构概览
从零到一建设数据中台 - 架构概览
136 1
|
7月前
|
存储 SQL 分布式计算
TiDB整体架构概览:构建高效分布式数据库的关键设计
【2月更文挑战第26天】本文旨在全面概述TiDB的整体架构,深入剖析其关键组件和功能,从而帮助读者理解TiDB如何构建高效、稳定的分布式数据库。我们将探讨TiDB的计算层、存储层以及其他核心组件,并解释这些组件是如何协同工作以实现卓越的性能和扩展性的。通过本文,读者将能够深入了解TiDB的整体架构,为后续的学习和实践奠定坚实基础。
|
供应链 架构师 双11
供应链业务架构设计概览(一)
供应链业务架构设计概览
1601 0
|
供应链 监控 数据可视化
供应链业务架构设计概览(二)
供应链业务架构设计概览
743 0
|
前端开发 定位技术 项目管理
【架构设计 领域驱动开发 二】基本概念概览
【架构设计 领域驱动开发 二】基本概念概览
105 0
|
架构师
「TOGAF架构框架」ArchiMate视图指南(1):基本视图概览
「TOGAF架构框架」ArchiMate视图指南(1):基本视图概览
|
存储 设计模式 缓存
【云应用架构】Azure 云设计模式概览
【云应用架构】Azure 云设计模式概览
|
架构师
「架构框架」ArchiMate视图指南(1):基本视图概览
「架构框架」ArchiMate视图指南(1):基本视图概览
|
负载均衡 前端开发 网络协议
【服务网格架构】Envoy 部署类型
【服务网格架构】Envoy 部署类型

热门文章

最新文章