作者 | Claudio Masolo
译者 | 明知山
策划 | 丁晓昀
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 存在单点故障问题。
使用 Eureka 的 IPC
这种架构存在了很长时间，不过 Netflix 因为一些原因需要迁移到 服务网格，主要的三个原因如下：
- 现在使用了 REST、graphQL 和 gRPC 混合的 IPC 技术。
- 已经从 Java 基础架构迁移到了多语言架构。
- 向 IPC 客户端中添加功能。
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 像往常一样处理请求：使用负载均衡算法选择一个端点并发出请求。
使用 Eureka 和 Envoy 的 IPC
这个流程的执行速度为毫秒级，但在某些场景中，服务需要更低的延迟。为了解决这个问题，目前的解决方案有：
- 服务需在发出第一个请求之前预先定义目标集群或建立主要连接。
- 在代理启动时，根据历史请求模式从控制平面预推送集群信息。
Netflix 和 Envoy 社区将继续合作改进 Envoy。
原文链接：
https://www.infoq.com/news/2023/09/zero-config-service-mesh-netflix/
