他们将生产环境从nginx迁移到envoy，原因竟然是…… 随着Service Mesh在最近一年进入人们的

导读：随着Service Mesh在最近一年进入人们的视野，Envoy 作为其中很关键的组件，也开始被广大技术人员熟悉。本文作者所在公司已经从

nginx

迁移到 Envoy。

随着我们下一代产品发布，我们将代理软件从

nginx

切换到 Envoy 。

我们很早就开始关注 Envoy。公司的一些人之前在 Twitter 工作，其中一些人和 Matt Klein 一起组建了 Twitter 的边缘代理 TFE。我们知道 Lyft 正在计划建立一个基于 TFE 的开源代理模型，我们对此很感兴趣。不幸的是，我们刚开始做自己产品的时候它还没有准备好，所以起初我们还是使用

nginx

。

我们很高兴看到 Envoy 的最初功能集合中包含了大量灵活运用微服务的想法。我们更加兴奋地看到它的社区已经成型并且技术已经成熟。现在 Envoy 提供的功能(相比于

nginx

)可以使我们能够更快地为客户提供新功能。当然，Envoy 的功能路线图也非常令人兴奋。

选择代理

在启动Turbine Labs时，我们就知道负载均衡将成为我们基础架构的关键组成部分。

在2015年秋季的时候，代理软件并不是我们今天看到的样子。

我们选择

nginx

是因为它轻巧，经过大量生产环境测试，开源，相对来说易于扩展，并且拥有蓬勃发展的用户群体。然而我们必须做很多额外的工作才能在
nginx
之上构建一个全功能的流量管理解决方案。

服务发现，统计管理和更细粒度的负载均衡是现代基础架构的关键特性。我们在

nginx

之上来实现这些功能，虽然已经花了很长时间，但仍有很多工作要做。

相比之下，Envoy 有很多非常有用功能（如 gRPC，tracing 等等），同时提供类似（或更好）的性能，稳定性和社区。

克服反对意见

采用任何新技术都需要考虑相反的意见。由于我们已经部署了代理服务，不仅需要考虑到自己的问题，还需要考虑到客户提出的问题。对于开源项目，这些问题通常分为以下几类：

当它失败时，它是如何失败的？

获取帮助容易吗？

需要改很多代码吗？

要多少钱？

我们一直密切关注 Envoy 的开发进展，并对它的成熟速度感到惊讶。已经有不少公司在生产环境使用 Envoy。Envoy 现在是一个 CNCF 项目，这意味着社区是透明和开放的。代码贡献者来自很多公司，我们也在其中。

成本也是需要考虑的因素。随着 sidecars 成为更普遍的部署方式，代理会得到更广泛的应用。虽然许多客户将继续集中式运行负载均衡，但我们希望代理软件可以优雅地支持边车部署模型。

Envoy 采用 C++ 11 编写，运行时占用的内存很少，与依赖较重运行时的代理相比，显着减少了 sidecars 部署的负担。

服务提供方的好处

应始终谨慎对待技术堆栈的大型更改。我们没有轻易转向 Envoy，但我们获得的好处以及我们可以传递给我们客户的好处非常显著。

可管理性

从一开始，Envoy 就被设计为可以大规模管理。我们已经做了很多工作来使我们的基于

nginx

的代理可管理，但是这个配置接口不太容易地暴露给其他工具。

Envoy 数据平面 API 为其集中管理提供了一个开放标准。我们可以提供一个集中的，开放的控制点，而不是复制配置文件。

可扩展性

nginx

是一个非常成功，稳定的开源项目。其配置文件和模块生态系统具有较大的外围应用，并有大量现有用户支持。给

nginx

贡献核心代码是非常有挑战性的，这导致在许多情况下需要编写自定义模块或 Lua 脚本以扩展其功能。

Envoy 更为聚焦，使用更为现代的语言支持改变代理行为。过去几个月中，我们向 Envoy 提交了超过 30 个功能，其中包括 OSX 构建，子集负载均衡和 upstream 日志记录等主要功能。

服务使用方的好处

更丰富的群集模型

我们在

nginx

上做了一些扩展，从而增强其 upstream 模型并添加更多细节。在同时部署同一服务的多个版本时，仅仅了解实例的主机和端口是不够的。

Envoy（通过我们贡献的补丁）允许将任意元数据附加到服务实例，以及定义基于该元数据定义路由规则。这使先进的流量管理技术成为可能，例如增量发布，蓝/绿版本，无缝整体分解和生产测试。

多协议支持

NGINX支持很多协议。 Envoy 的架构可以轻松地添加对新协议的支持，并且它也提供了多种协议支持。虽然 HTTP 占据了互联网流量的很大一部分，但增加对 Redis，Mongo，Dynamo，websockets 和 gRPC 流量的可见性也是非常重要的。

动态服务发现

随着微服务，容器变得越来越流行，服务拓扑变得更加动态。配置文件中的服务器列表很快就会过时。

Envoy 使用一种最终一致的模型来进行 API 驱动的服务发现，并且能够很好地处理变化频繁的实例。

我们目前从各种平台收集数据，而 Envoy 的群集发现服务（CDS）为我们提供了比固定配置文件更自然的抽象。 Envoy 通过支持监听器发现服务（LDS）和路由发现服务（RDS）支持路由拓扑发现，从而进一步加强了这一点。最终允许从中央控制点动态重新配置大部分服务拓扑，这非常有用。

网络策略

微服务意味着网络更加依赖于服务抽象边界。随着相互依赖的服务数量日渐增长，系统100%没问题的时间会变少，整个系统经常有部分功能处于降级状态。

管理网络策略（如重试，超时和速率限制）对于在面对系统健康问题时保持顺畅的客户体验至关重要。Envoy 允许在代理（每个路由）和客户端（每个请求的基础上）配置这些策略。这可以灵活地实现（难以用

nginx

实现的）极细粒度弹性策略。

监测

Envoy 使用行业标准的请求日志，还提供与各种监测系统的集成。它还提供对 Zipkin 和 Lightstep 的原生支持，以便追踪整个请求链。

如何更快迁移

我们对迁移到 Envoy 的过程非常满意。它稳定，快速，轻便，并拥有一个伟大的社区。它的架构使其非常适合微服务，但它同样适合做边缘代理。作为基础服务，使用配置API而非静态配置文件真是太棒了。

如果你已经开始使用 Envoy，或者正在考虑迁移到 Envoy，那就可以考虑使用我们的服务。凭借广泛的服务发现和卓越的管理界面，我们可以帮助您快速，平稳地部署和运营 Envoy。

英文原文：

http://blog.turbinelabs.io/our-move-to-envoy-bfeb08aa822d

更多 Envoy 介绍：

http://www.envoyproxy.io/

相关阅读：

阿里云故障，仅是运维操作失误？

微博开源的Motan RPC最新进展：新增跨语言及服务治理支持

Java 微服务框架新选择：Spring 5

从单体应用走向微服务:一次API Gateway升级的启示

本文作者Mark McBride，由方圆翻译，转载本文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构

改变互联网的构建方式

长按二维码关注「高可用架构」公众号