服务发现
Last updated
Was this helpful?
Last updated
Was this helpful?
在配置上游群集时，Envoy需要知道解析这些群集的成员。这被称为服务发现。
静态是最简单的服务发现类型。通过静态配置明确每个上游主机的网络名称（IP地址/端口，unix域套接字等）。
当使用DNS服务发现时，Envoy将持续并异步地解析指定的DNS目标。DNS结果中的每个返回的IP地址将被视为上游群集中的显式主机。 这意味着如果查询返回三个IP地址，Envoy将假定集群有三个主机，并且三个主机都应该负载平衡。如果主机从结果中删除，则Envoy认为它不再存在，并将从任何现有的连接池中摄取流量。请注意，Envoy绝不会在转发路径中同步解析DNS。以最终一致性为代价，永远不会担心长时间运行的DNS查询会受到阻塞。
逻辑DNS使用类似的异步机制来解析严格DNS。但是，并不是严格考虑DNS查询的结果，而是假设它们构成整个上游集群，而逻辑DNS集群仅使用在需要启动新连接时返回的第一个IP地址。因此，单个逻辑连接池可以包含到各种不同上游主机的物理连接。连接永远不会流失。此服务发现类型适用于必须通过DNS访问的大型Web服务。这种服务通常使用循环法的DNS来返回许多不同的IP地址。通常会为每个查询返回不同的结果。如果在这种情况下使用严格的DNS，Envoy会认为集群的成员在每个解决时间间隔期间都会发生变化，这会导致连接池，连接循环等消失。相反，使用逻辑DNS，连接将保持活动状态，直到它们循环。在与大型Web服务交互时，这是所有可能的世界中最好的：异步/最终一致的DNS解析，长期连接，以及转发路径中的零阻塞。
Envoy通过向服务发现服务，获取集群的成员。Lyft通过Python提供了一个发现服务的。该实现是使用AWS DynamoDB作为后端存储，但该API非常简单，可以轻松地在各种不同的后备存储之上实现。对于每个SDS群集，Envoy将定期从发现服务中获取群集成员。SDS做为首选的服务发现机制，原因如下：
Envoy能够对每个上游主机都有更加详细的信息（相比通过DNS解析），并能做出更智能的负载均衡决策。
在每个主机发现的API响应中，通过携带附加的属性，如负载均衡权重，灰度状态，区域等。这些附加属性在负载均衡，统计信息收集等过程中由Envoy网络全局使用。
通常，主动健康检查与最终一致的服务发现服务结合起来使用，以进行负载平衡和路由决策。这将在下一节进一步讨论。
许多现有的RPC系统将服务发现视为完全一致的过程。为此，他们使用支持完全一致的leader选举存储，如Zookeeper，etcd，Consul等。我们的经验是，在大规模操作这些存储会很痛苦。
Envoy从一开始就设计了服务发现不需要完全一致的想法。相反，Envoy假定主机以一种最终一致的方式来自网格。在部署服务间Envoy网格时，我们推荐使用最终一致的服务发现，结合主动健康检查（Envoy主动健康检查上游集群成员状态）来确定集群运行状况。这种范例有许多好处：
有的健康决定是完全分配的。 因此，网络分区被正常处理（应用程序是否正常处理分区是另一回事）。
为上游群集配置运行状况检查时，Envoy使用2x2矩阵来确定是否路由到主机：
服务发现状态
健康检查正常
健康检查失败
存在
路由
停止路由
不存在
路由
停止路由/删除
主机被发现/健康检查确定 特使将路由到目标主机。
主机无法被发现/健康检查确定 Envoy将路由到目标主机。这是非常重要的，因为设计假定发现服务可以随时失败。如果主机即使在发现数据缺失之后仍继续通过健康检查，Envoy仍将路由。 虽然在这种情况下添加新主机是不可能的，但现有的主机仍然可以正常运行。 当发现服务再次正常运行时，数据将最终重新收敛。
主机被发现/健康检查失败 Envoy不会路由到目标主机。假设健康检查数据比发现数据更准确。
主机无法被发现/健康检查失败 Envoy不会路由并将删除目标主机。这是Envoy将清除主机数据的唯一状态。