Netflix 为 Envoy 开发新功能，实现零配置服务网格

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 因为一些原因需要迁移到服务网格，主要的三个原因如下：

1. 现在使用了REST、graphQL和gRPC混合的 IPC 技术。

2. 已经从 Java 基础架构迁移到了多语言架构。

3. 向 IPC 客户端中添加功能。

Netflix 决定使用 Envoy 集中实现 IPC 功能集，并让使用各种语言开发的客户端尽可能简单。此外，Envoy 支持发现抽象（Discovery Abstraction），因此 IPC 客户端可以继续使用它。缺点是 Envoy 需要在代理配置中指定集群，这对 Netflix 架构来说是个问题，因为一个服务可能与十几个集群进行通信。此外，Netflix 的架构是不断变化的，这意味着集群会随着时间的推移而变化。为了解决这个问题，Netflix 团队调研了一些方案：

• 让服务所有者定义他们的服务需要通信的集群。

• 根据服务的调用图自动生成 Envoy 配置。

• 将所有的集群信息推送给每个应用。

但所有这些方案都存在缺点，因此他们最终的解决方案是在运行时按需获取集群信息。为了实现这个解决方案，Envoy 需要一个新特性。于是，Envoy 社区、Netflix 和 Kinvolk 合作开发了按需集群发现(ODCDS) 功能。现在，代理可以在第一次连接时查找集群信息。新的流程如下：

1. 客户端的请求进入 Envoy；

2. 根据主机地址提取目标集群信息。如果集群是已知的，进入步骤 7；

3. 如果集群不存在，请求被暂停；

4. 向控制平面上的集群发现服务(CDS)端点发出请求。控制平面根据服务的配置和 Eureka 注册信息生成自定义 CDS 响应；

5. Envoy 拿到集群信息(CDS)，通过端点发现服务(EDS)拉取端点信息，然后根据 VIP 或 SVIP 的 Eureka 状态信息返回集群的端点；

6. 客户端的请求继续；

7. Envoy 像往常一样处理请求：使用负载均衡算法选择一个端点并发出请求。

使用Eureka和Envoy的IPC

这个流程的执行速度为毫秒级，但在某些场景中，服务需要更低的延迟。为了解决这个问题，目前的解决方案有：

1. 服务需在发出第一个请求之前预先定义目标集群或建立主要连接。

2. 在代理启动时，根据历史请求模式从控制平面预推送集群信息。

Netflix 和 Envoy 社区将继续合作改进 Envoy。

原文链接：

https://www.infoq.com/news/2023/09/zero-config-service-mesh-netflix/