### 服务发现
在配置上游群集时,Envoy需要知道解析这些群集的成员。这被称为服务发现。
#### 支持的服务发现类型
##### 静态
静态是最简单的服务发现类型。通过静态配置明确每个上游主机的网络名称(IP地址/端口,unix域套接字等)。
##### 严格(Strict)DNS
当使用DNS服务发现时,Envoy将持续并异步地解析指定的DNS目标。DNS结果中的每个返回的IP地址将被视为上游群集中的显式主机。 这意味着如果查询返回三个IP地址,Envoy将假定集群有三个主机,并且三个主机都应该负载平衡。如果主机从结果中删除,则Envoy认为它不再存在,并将从任何现有的连接池中摄取流量。请注意,Envoy绝不会在转发路径中同步解析DNS。以最终一致性为代价,永远不会担心长时间运行的DNS查询会受到阻塞。
##### 逻辑(Logical)DNS
逻辑DNS使用类似的异步机制来解析严格DNS。但是,并不是严格考虑DNS查询的结果,而是假设它们构成整个上游集群,而逻辑DNS集群仅使用在需要启动新连接时返回的第一个IP地址。因此,单个逻辑连接池可以包含到各种不同上游主机的物理连接。连接永远不会流失。此服务发现类型适用于必须通过DNS访问的大型Web服务。这种服务通常使用循环法的DNS来返回许多不同的IP地址。通常会为每个查询返回不同的结果。如果在这种情况下使用严格的DNS,Envoy会认为集群的成员在每个解决时间间隔期间都会发生变化,这会导致连接池,连接循环等消失。相反,使用逻辑DNS,连接将保持活动状态,直到它们循环。在与大型Web服务交互时,这是所有可能的世界中最好的:异步/最终一致的DNS解析,长期连接,以及转发路径中的零阻塞。
##### 服务发现服务(SDS)
Envoy通过[REST API](../../v1APIreference/Clustermanager/Servicediscoveryservice.md)向服务发现服务,获取集群的成员。Lyft通过Python提供了一个发现服务的[参考实现](https://github.com/lyft/discovery)。该实现是使用AWS DynamoDB作为后端存储,但该API非常简单,可以轻松地在各种不同的后备存储之上实现。对于每个SDS群集,Envoy将定期从发现服务中获取群集成员。SDS做为首选的服务发现机制,原因如下:
- Envoy能够对每个上游主机都有更加详细的信息(相比通过DNS解析),并能做出更智能的负载均衡决策。
- 在每个主机发现的API响应中,通过携带附加的属性,如负载均衡权重,灰度状态,区域等。这些附加属性在负载均衡,统计信息收集等过程中由Envoy网络全局使用。
通常,主动健康检查与最终一致的服务发现服务结合起来使用,以进行负载平衡和路由决策。这将在下一节进一步讨论。
##### 最终一致的服务发现
许多现有的RPC系统将服务发现视为完全一致的过程。为此,他们使用支持完全一致的leader选举存储,如Zookeeper,etcd,Consul等。我们的经验是,在大规模操作这些存储会很痛苦。
Envoy从一开始就设计了服务发现不需要完全一致的想法。相反,Envoy假定主机以一种最终一致的方式来自网格。在部署服务间Envoy网格时,我们推荐使用最终一致的服务发现,结合主动健康检查(Envoy主动健康检查上游集群成员状态)来确定集群运行状况。这种范例有许多好处:
- 有的健康决定是完全分配的。 因此,网络分区被正常处理(应用程序是否正常处理分区是另一回事)。
- 为上游群集配置运行状况检查时,Envoy使用2x2矩阵来确定是否路由到主机:
<table>
<tr>
<th> 服务发现状态 </th>
<th> 健康检查正常 </th>
<th> 健康检查失败 </th>
</tr>
<tr>
<th>存在</th>
<th>路由</th>
<th>停止路由</th>
</tr>
<tr>
<th>不存在</th>
<th>路由</th>
<th>停止路由/删除</th>
</tr>
</table>
- **主机被发现/健康检查确定**<br />
特使将路由到目标主机。
- **主机无法被发现/健康检查确定**<br />
Envoy将路由到目标主机。这是非常重要的,因为设计假定发现服务可以随时失败。如果主机即使在发现数据缺失之后仍继续通过健康检查,Envoy仍将路由。 虽然在这种情况下添加新主机是不可能的,但现有的主机仍然可以正常运行。 当发现服务再次正常运行时,数据将最终重新收敛。
- **主机被发现/健康检查失败**<br />
Envoy不会路由到目标主机。假设健康检查数据比发现数据更准确。
- **主机无法被发现/健康检查失败**<br />
Envoy不会路由并将删除目标主机。这是Envoy将清除主机数据的唯一状态。
### 返回
- [架构介绍](../Architectureoverview.md)
- [简介](../../Introduction.md)
- [首页目录](../../README.md)
- 首页
- 简介
- Envoy是什么
- 架构介绍
- 术语
- 线程模型
- 监听器
- L3/L4网络过滤器
- HTTP连接管理
- HTTP过滤器
- HTTP路由
- gRPC
- WebSocket支持
- 集群管理
- 服务发现
- 健康检查
- 连接池
- 负载均衡
- 异常检测
- 熔断
- 全局限速
- TLS
- 统计
- 运行时配置
- 跟踪
- TCP代理
- 访问日志
- MongoDB
- DynamoDB
- Redis
- 热重启
- 动态配置
- 初始化
- 逐出
- 脚本
- 部署
- 业界对比
- 获得帮助
- 历史版本
- 编译安装
- 编译
- 参考配置
- 演示沙箱
- 前端代理
- Zipkin跟踪
- Jaeger跟踪
- gRPC桥接
- 构建Envoy Docker镜像
- 工具
- 配置参考
- V1 API 概述
- V2 API 概述
- 监听器
- 网络过滤器
- TLS客户端身份认证
- Echo
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP连接管理器
- 路由匹配
- 流量转移/分流
- HTTP头部操作
- HTTP头部清理
- 统计
- 运行时设置
- 路由发现服务
- HTTP过滤器
- 缓存
- CORS过滤器
- 故障注入
- DynamoDB
- gRPC HTTP/1.1 桥接
- gRPC-JSON 转码过滤器
- gRPC-Web 过滤器
- 健康检查
- 速率限制
- 路由
- Lua
- 集群管理
- 统计
- 运行时设置
- 集群发现服务
- 健康检查
- 熔断
- 访问日志
- 限速服务
- 运行时配置
- 路由表检查工具
- 运维管理
- 命令行选项
- 热重启
- 管理接口
- 统计概述
- 运行时配置
- 文件系统
- 自定义扩展示例
- V1 API参考
- 监听器
- 网络过滤器
- TLS客户端身份认证
- Echo
- HTTP连接管理
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP路由配置
- 虚拟主机
- 路由
- 虚拟集群
- 速率限制配置
- 路由发现服务
- HTTP过滤器
- 缓存
- CORS过滤器
- DynamoDB
- 故障注入
- gRPC HTTP/1.1 桥接
- gRPC-JSON 转码过滤器
- gRPC-Web 过滤器
- 健康检查
- Lua
- 速率限制
- 路由
- 集群管理
- 集群
- 健康检查
- 熔断
- TLS上下文
- 异常值检测
- HASH环负载均衡配置
- 异常检测
- 集群发现服务
- 服务发现服务
- 访问日志
- 管理接口
- 限速服务
- 运行时配置
- 跟踪
- V2 API参考
- 启动引导
- 监听&监听发现
- 集群&集群发现
- 服务发现
- 健康检查
- HTTP路由管理&发现
- TLS配置
- 通用的类型
- 网络地址
- 协议选项
- 发现API
- 限速组件
- 过滤器
- 网络过滤器
- TLS客户端身份认证
- HTTP连接管理
- Mongo代理
- 速率限制
- Redis代理
- TCP代理
- HTTP过滤器
- 缓存
- 故障注入
- 健康检查
- Lua
- 速率限制
- 路由
- gRPC-JSON转码器
- 常见访问日志类型
- 常见故障注入类型
- FAQ
- Envoy有多快?
- 我在哪里获得二进制文件?
- 我如何设置SNI?
- 如何设置区域感知路由?
- 我如何设置Zipkin跟踪?