他们将生产环境从nginx迁移到envoy，缘由居然是……

导读：随着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。

 

英文原文：

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

 

更多 Envoy 介绍：

https://www.envoyproxy.io/