Netflix 在这篇文章中描述了他们为什么与 Envoy 社区和合作为 Lyft 开源的代理实现了一项新功能。这个叫作按需集群发现的新功能帮助 Netflix 实现了零配置服务网格。
进程间通信(IPC)对于 Netflix 来说至关重要。自 Netflix 从 2010 年将所有基础设施转移到云端(AWS)，就一直需要使用针对云原生环境的工具。其中一些工具是商业版的，一些是内部开发的。为了方便管理 IPC，Netflix 开发了用于服务发现的和用于 IPC 的。Eureka 的主要目标是用虚拟 IP(VIP)抽象目标服务的名称，并且如果有必要的话还可以确保与安全虚拟 IP(VIP)的安全通信。目标服务名称和通信类型(安全或不安全)是服务连接到另一个服务所需的信息。IPC 客户端使用目标 VIP 或 SVIP 实例化，Eureka 客户端负责 VIP 或 SVIP 和端口到 IP 的转换，从 Eureka 服务器获取信息。其缺点是从负载均衡器迁移到 Eureka 存在单点故障问题。
使用Eureka的IPC
这种架构存在了很长时间，不过 Netflix 因为一些原因需要迁移到服务网格，主要的三个原因如下：
Netflix 决定使用 Envoy 集中实现 IPC 功能集，并让使用各种语言开发的客户端尽可能简单。此外，Envoy 支持发现抽象（Discovery Abstraction），因此 IPC 客户端可以继续使用它。缺点是 Envoy 需要在代理配置中指定集群，这对 Netflix 架构来说是个问题，因为一个服务可能与十几个集群进行通信。此外，Netflix 的架构是不断变化的，这意味着集群会随着时间的推移而变化。为了解决这个问题，Netflix 团队调研了一些方案：
但所有这些方案都存在缺点，因此他们最终的解决方案是在运行时按需获取集群信息。为了实现这个解决方案，Envoy 需要一个新特性。于是，Envoy 社区、Netflix 和 Kinvolk 合作开发了按需集群发现(ODCDS)功能。现在，代理可以在第一次连接时查找集群信息。新的流程如下：
使用Eureka和Envoy的IPC
这个流程的执行速度为毫秒级，但在某些场景中，服务需要更低的延迟。为了解决这个问题，目前的解决方案有：
Netflix 和 Envoy 社区将继续合作改进 Envoy。
原文链接 ：
