Netflix 在这篇文章中描述了他们为什么与 Envoy 社区和Kinvolk合作为 Lyft 开源的代理Envoy实现了一项新功能。这个叫作按需集群发现的新功能帮助 Netflix 实现了零配置服务网格。
进程间通信(IPC) 对于 Netflix 来说至关重要。自 Netflix 从 2010 年将所有基础设施转移到云端(AWS)，就一直需要使用针对云原生环境的工具。其中一些工具是商业版的，一些是内部开发的。为了方便管理 IPC，Netflix 开发了用于服务发现的Eureka和用于 IPC 的Ribbon。Eureka 的主要目标是用虚拟 IP(VIP)抽象目标服务的名称，并且如果有必要的话还可以确保与安全虚拟 IP(VIP)的安全通信。目标服务名称和通信类型(安全或不安全)是服务连接到另一个服务所需的信息。IPC 客户端使用目标 VIP 或 SVIP 实例化，Eureka 客户端负责 VIP 或 SVIP 和端口到 IP 的转换，从 Eureka 服务器获取信息。其缺点是从负载均衡器迁移到 Eureka 存在单点故障问题。
这种架构存在了很长时间，不过 Netflix 因为一些原因需要迁移到服务网格，主要的三个原因如下：
Netflix 决定使用 Envoy 集中实现 IPC 功能集，并让使用各种语言开发的客户端尽可能简单。此外，Envoy 支持发现抽象（Discovery Abstraction），因此 IPC 客户端可以继续使用它。缺点是 Envoy 需要在代理配置中指定集群，这对 Netflix 架构来说是个问题，因为一个服务可能与十几个集群进行通信。此外，Netflix 的架构是不断变化的，这意味着集群会随着时间的推移而变化。为了解决这个问题，Netflix 团队调研了一些方案：
让服务所有者定义他们的服务需要通信的集群。
根据服务的调用图自动生成 Envoy 配置。
将所有的集群信息推送给每个应用。
但所有这些方案都存在缺点，因此他们最终的解决方案是在运行时按需获取集群信息。为了实现这个解决方案，Envoy 需要一个新特性。于是，Envoy 社区、Netflix 和 Kinvolk 合作开发了按需集群发现(ODCDS) 功能。现在，代理可以在第一次连接时查找集群信息。新的流程如下：
客户端的请求进入 Envoy；
根据主机地址提取目标集群信息。如果集群是已知的，进入步骤 7；
如果集群不存在，请求被暂停；
向控制平面上的集群发现服务(CDS)端点发出请求。控制平面根据服务的配置和 Eureka 注册信息生成自定义 CDS 响应；
Envoy 拿到集群信息(CDS)，通过端点发现服务(EDS)拉取端点信息，然后根据 VIP 或 SVIP 的 Eureka 状态信息返回集群的端点；
客户端的请求继续；
Envoy 像往常一样处理请求：使用负载均衡算法选择一个端点并发出请求。
这个流程的执行速度为毫秒级，但在某些场景中，服务需要更低的延迟。为了解决这个问题，目前的解决方案有：
服务需在发出第一个请求之前预先定义目标集群或建立主要连接。
在代理启动时，根据历史请求模式从控制平面预推送集群信息。
Netflix 和 Envoy 社区将继续合作改进 Envoy。
原文链接：
https://www.infoq.com/news/2023/09/zero-config-service-mesh-netflix/
