【服务网格】Envoy架构概览(3)：服务发现

服务发现

在配置中定义上游群集时，Envoy需要知道如何解析群集的成员。这被称为服务发现。

支持的服务发现类型

静态的

静态是最简单的服务发现类型。配置明确指定每个上游主机的已解析网络名称（IP地址/端口，unix域套接字等）。

严格的DNS

当使用严格的DNS服务发现时，Envoy将持续并异步地解析指定的DNS目标。 DNS结果中的每个返回的IP地址将被视为上游群集中的显式主机。这意味着如果查询返回三个IP地址，Envoy将假定集群有三个主机，并且三个主机都应该负载平衡。如果主机从结果中删除，则Envoy认为它不再存在，并将从任何现有的连接池中汲取流量。请注意，Envoy绝不会在转发路径中同步解析DNS。以最终一致性为代价，永远不会担心长时间运行的DNS查询会受到阻塞。

逻辑DNS

逻辑DNS使用类似的异步解析机制严格DNS。但是，并不是严格考虑DNS查询的结果，而是假设它们构成整个上游集群，而逻辑DNS集群仅使用在需要启动新连接时返回的第一个IP地址。因此，单个逻辑连接池可以包含到各种不同上游主机的物理连接。连接永远不会流失。此服务发现类型适用于必须通过DNS访问的大型Web服务。这种服务通常使用循环法的DNS来返回许多不同的IP地址。通常会为每个查询返回不同的结果。如果在这种情况下使用严格的DNS，Envoy会认为集群的成员在每个解决时间间隔期间都会发生变化，这会导致连接池，连接循环等消失。相反，使用逻辑DNS，连接保持活动状态，直到它们循环。在与大型Web服务交互时，这是所有可能的世界中最好的：异步/最终一致的DNS解析，长期连接，以及转发路径中的零阻塞。

原始目的地

传入连接通过iptables REDIRECT规则或Proxy协议重定向到Envoy时，可以使用原始目标集群。在这些情况下，路由到原始目标群集的请求会按照重定向元数据转发给上游主机，而不需要任何明确的主机配置或上游主机发现。到上游主机的连接会被合并，未使用的主机在空闲时间超过* cleanup_interval_ms *时会被刷新，默认值为5000ms。如果原始目标地址不可用，则不会打开上游连接。原始目标服务发现必须与原始目标负载均衡器一起使用。

服务发现服务（SDS）

服务发现服务是Envoy用来获取集群成员的通用REST API。 Lyft通过Python发现服务提供了一个参考实现。该实现使用AWS DynamoDB作为后备存储，但是该API非常简单，可以轻松地在各种不同的后备存储之上实施。对于每个SDS群集，Envoy将定期从发现服务中获取群集成员。 SDS是首选的服务发现机制，原因如下：

• Envoy对每个上游主机都有明确的了解（与通过DNS解析的负载均衡器进行路由相比），并能做出更智能的负载平衡决策。

• 在每个主机的发现API响应中携带的附加属性通知Envoy负载平衡权重，金丝雀状态，区域等。这些附加属性在负载平衡，统计信息收集等过程中由Envoy网络全局使用。

通常，主动健康检查与最终一致的服务发现服务数据结合使用，以进行负载平衡和路由决策。这将在下一节进一步讨论。

最终一致的服务发现

许多现有的RPC系统将服务发现视为完全一致的过程。为此，他们使用完全一致的领导选举支持商店，如Zookeeper，etcd，Consul等。我们的经验是，大规模操作这些支持商店是痛苦的。

Envoy从一开始就设计了服务发现不需要完全一致的想法。相反，Envoy假定主机以一种最终一致的方式来自网格。我们推荐的部署服务以服务Envoy网格配置的方式使用最终一致的服务发现以及主动运行状况检查（Envoy显式健康检查上游集群成员）来确定集群运行状况。这种范例有许多好处：

所有的健康决定是完全分配的。因此，网络分区被优雅地处理（应用程序是否优雅地处理分区是另一回事）。

当为上游群集配置运行状况检查时，Envoy使用2x2矩阵来确定是否路由到主机：

Host discovered / health check OK

Envoy将路由到目标主机。

Host absent / health check OK:

Envoy将路由到目标主机。 这是非常重要的，因为设计假定发现服务可以随时失败。 如果主机即使在发现数据缺失之后仍继续通过健康检查，Envoy仍将路由。 虽然在这种情况下添加新主机是不可能的，但现有的主机仍然可以正常运行。 当发现服务再次正常运行时，数据将最终重新收敛。

Host discovered / health check FAIL

Envoy不会路由到目标主机。 假设健康检查数据比发现数据更准确。

Host absent / health check FAIL

Envoy不会路由并将删除目标主机。 这是Envoy将清除主机数据的唯一状态。