配置Envoy代理让Monzo运行更快

我们的架构核心系统是RPC，微服务可以通过网络进行可靠以及容错的通讯。RPC系统包含几个重要指标

- 高性能：通讯应该尽量快；RPC应该支持最小延迟并且减小试错次数

- 可扩展性：我们的用户规模要求支撑每秒上万次请求。

- 弹性：面对系统不稳定（服务宕机，bugs，网络故障），应该支持容错性恢复

- 可监控的：面对每天海量的数据，RPC系统应该支持服务数据度量和监控。

2016年，我们发布了一篇关于融合用Linkerd 1.0搭建银行业务后端的博客，当时service mesh生态系统还相对不成熟。从那以后，许多新项目整合进来，现在是重新评估这一组件的时候了。

service mesh

我们的微服务业务通过HTTP服务每秒产生上万次RPC调用，为了实现分布式容错系统，需要服务发现、自动重试、错误预算、负载均衡和中断循环的手段。

同时我们还系统支持各种编程语言。因为尽管大部分微服务都是用 Go 完成，但是还有一些团队选择其他语言（例如，数据团队处理机器学习服务时会采用Python）

用每种语言实现复杂功能对采用新功能时是一个巨大的障碍。另外改变RPC调用意味着重新部署所有服务。

我们做出的一个关键性决定就是尽量保持这种复杂逻辑，用Linkerd提供尽量对服务透明的功能。

Linkerd作为k8s的守护进程集，每个服务都会同本机上运行的Linkerd通讯。

迁移到Envoy

如果不给Linkerd更多处理能力就无法处理负载，迫使我们不得不扩展架构。因为业务发展，RPC架构的资源也不能持久支撑业务。即使在正常负载情况下，Linkerd也是99%以上延迟的主要贡献者。

我们开始考察其它替代产品，例如Linkerd 2.0， Istio和Envoy。最终选择了Envoy，这是因为Envoy提供高性能，相对成熟，被大项目广泛采用的特点。

Envoy是Lyft开源的高性能service mesh工具，用C++写成，因此不会有垃圾回收或者编译暂停等问题。Istio和Ambassador都采用Envoy做底层的代理系统。

Envoy不内置任何k8s组件，我们自己开发小型控制面板，可以监控k8s架构中的改变（例如由于新pod造成服务端点的修改），以及通过CDS API将改变推送给Envoy，以便知道新服务。

我们用自己开发的测试 工具 在原来Linkerd系统和Envoy系统上做了对比测试。

在所有测试中，Envoy都比Linkerd1.0表现更佳，而且需要更少的处理能力和内存资源。

也有一些不足之处，例如负载均衡的延迟和基于服务的错误预算。最终这些因素并没有成为障碍因为我们决定未来将这些功能加入其中。

我们想做到对服务透明的切换，因此希望支持回滚的功能。

像Linkerd一样，我们设置了Envoy通过HTTP接收并路由请求，并纳入了k8s守护进程集。通过几个月压力测试，一旦要切换到生产系统，可以切换到某个时间点然后修复最后出现的问题。

可监控

Linkerd有很棒的控制面板，但是跟Prometheus的监控系统整合的不好。我们将Envoy投产之前，非常注意跟Prometheus的整合。

我们将对Prometheus的支持回馈到Envoy社区，使得我们有了很多内容丰富的面板支持。

通过数据分析，我们对切换工作充满了自信。

应用与后台沟通时，经过edge层进入微服务区获得服务。切换到Envoy后，在Edge层看到了很大的延迟降低，跟测试结果很类似，也给使用Monzo提供了更快的体验。

作为边车的Envoy

我们希望将Envoy作为微服务容器的边车，也就意味着不需要与Envoy主机通讯而只跟本地Envoy通讯即可。

通过边车模式，我们设置Envoy支持Ingress和Egress。进来的请求通过本地Envoy，确认压力是合法的。出去的请求（Egress）通过边车Envoy路由到跟以前一样正确的地方。

采用边车的优点是可以定义网络隔绝规则。之前，因为压力从共享的Envoy来，因此不能锁定敏感微服务只对某些特定IP的pod提供网络层服务。服务必须自己判断访问请求是否合法。

将Envoy移入同一个pod命名空间后，可以在Pod里加入Calico网络策略规则，为每个微服务创建合适的防火墙策略。本例中，ingress进入的微服务访问流量只能从特定的子网进入，为防止非法访问提供了额外的安全保护。

另外比较Linkerd，Envoy只需要很少的系统资源和内存，目前Envoy边车支撑我们日益扩大的访问压力。

收获

迁移到Envoy是一个很大的成功。我们不需要重建已有的服务而能获得更佳的体验，尤其是在减少资源消耗和减少延迟方面，毋庸置疑，Envoy可以支撑我们未来的业务发展。

我们也非常感谢Envoy社区的帮助和支持，我们也希望能够继续回馈社区。