Envoy如何打败Linkerd成为L7负载平衡器的最佳选择？

Posted 2020-12-28 linbo3168

 

本文转自：http://www.servicemesh.cn/?/article/41

作者：MIKE WHITE

翻译：姚炳雄

原文：Using Envoy to Load Balance gRPC Traffic


针对 Bugsnag（一款bug自动检测工具），我们最近启动了一个专门用来跟踪软件发布健康状况的发布仪表板项目。 这是个大任务，当我们在构建后台时，特别关注了它的性能。其中的关键领域之一是和后端服务调用相关的延迟，在最后，我们决定用 Google 的超级快速的 gRPC 框架替换REST。


为了成功迁移到 gRPC，需要重新思考我们的负载均衡策略，以确保它很好地支持 gRPC 流量。 这篇博文概述了我们如何最终达成目标，去将 Lyft 功能丰富的 Envoy Proxy 添加到堆栈以及它又是如何来适应 Bugsnag 架构的。



Bugsnag体系结构的背景

在背后，Bugsnag 有一个微服务管道，负责处理从客户那里收到的错误信息，这些错误信息稍后展示在仪表板上。 这条管道目前每天处理数以亿计的事件。为了支持新的发布仪表板，我们需要扩展管道接收用户会话信息，这意味着流量将大幅增加。性能将成为是这个项目成功的关键，也是我们采用gRPC框架的主要原因之一。


部署方面，Bugsnag 的微服务是通过 Kubernetes 以 Docker 容器方式部署在云上。 Kubernetes 通过它的 kube-proxy 建立了负载均衡，可以很好地处理 HTTP / 1.1 流量，但是当你把 HTTP / 2 请求也扔进去混合到一起时，事情会变得很有意思。




HTTP / 2 – 一个负载均衡头痛的难题

gRPC 使用了性能加速的HTTP / 2协议。 HTTP / 2的实现比起以前的版本，在诸多降低延迟的方法中，一种利用了单一的长 TCP 连接（single long-lived TCP connection），并在该连接上能交叉传递请求/响应。 这给4层（L4）负载均衡器带来了问题，因为它们的操作在太低的层上，以致无法根据它接收到的流量类型做出路由决策。 因此，一个L4负载平衡器试着负载平衡HTTP / 2流量，必然会打开一个单一长TCP连接，并将所有连续的流量都路由到这个单一长TCP连接，这实际上是取消了负载平衡。

Kubernetes 的 kube-proxy 本质上是一个L4负载平衡器，所以我们不能依靠它来负载平衡微服务之间的gRPC调用。



为什么不让客户做这项工作？

我们探索的其中一个选项是使用 gRPC 客户端负载均衡器，它被打包在gRPC客户端库中。 这样，每个客户端微服务可以执行自己的负载平衡。 然而，由此产生的客户端最终是脆弱的，并需要大量的客户化代码来提供所有形式的弹性、度量或日志记录，所有这些需要重复几次在管道中使用每种不同的语言。


我们真正需要的是更智能的负载均衡器。



选择更智能的负载平衡器

我们需要一个L7负载均衡器，因为它们作用在应用层，能检测流量，以便做出路由决策。 最重要的是，他们可以支持HTTP / 2协议。


对于L7负载平衡器的选择，包括 nginx 和 HAProxy 在内，有许多可选的产品。但这其中的大多数都因为过于厚重而不易采纳进微服务架构。 我们缩小范围，选择了两个关键的竞争者 —— Envoy 和 Linkerd。两者都是秉承微服务体系结构理念开发的，都支持gRPC。


虽然这两个代理都有很多不错的功能，但最根本的决定因素取决于代理的足迹。这样赢家就很明显了。 Envo 非常小，用 C ++ 11编写，不像用 Java 编写用于企业级的 Linkerd 那么重。


一旦决定使用 Envoy，开始深入到它的功能集中，会发现有很多想要的东西。




Envoy凭什么表现这么好？

Envoy 由 Lyft 编写和开源，是多年来与微服务体系结构中常见的复杂路由问题作斗争的直接结果。 它本质上是为了适应我们的问题而设计的，

• 一流的双向支持HTTP / 2和SSL
• 具备优秀的度量指标并高度透明
• 成熟的文档集
• 不依赖于任何给定的语言

最后一个，也是最重要的一个，它与Bugsnag的polyglot微服务架构融为一体。




Envoy进入基础设施

在 Kubernetes 中，一个或多个容器组成一组称为 pod。Pod 能被复制多个，以提供弹性扩展，这些 pod 被包装抽象成服务，该服务拥有固定的IP，通过该服务可以访问底层的 pod。从 Kubernetes 1.2开始，当访问服务IP时，kubernetes 会随机返回后端的某个pod。也可以将服务重新配置为无人值守（headless），以便服务IP不再返回可用的pod IP整个列表，而是允许执行自己的服务发现。


Envoy 被设计成 Sidecar Container 方式运行，与客户端容器并排放置，以模块化方式来补充其功能。在 Kubernetes 中，这转化为在同一个 pod 中运行客户的容器和 Envoy 容器。我们将我们的服务配置为无人值守（headless）模式以供 Envoy 来做服务发现的端点。而且，依赖于Envoy大量的度量数据的输出，我们能够轻松观察到持续的gRPC调用的轮询调度的负载均衡，来确认其按预期工作。


当我们选择为每个gRPC客户端运行一个 Envoy 边车，像 Lyft 公司为所有微服务都运行一个Envoy sidecar，形成服务网格。这种方法非常强大，可以在域级别调整流量参数，这也是我们想在Bugsnag上能看到的。



可选方案


虽然Envoy能够满足需求，但还是有一些值得一提的替代方案。其中一些是我们探讨的，但是他们或者太不成熟，或者不太适合当时的架构：


· Istio - IBM，Google 和 Lyft 联合开发，形成了一个完整的微服务负载均衡解决方案。Envoy 作为核心，在 Kubernete s平台上“开箱即用”方式运行。


· Ribbon - 来自 Netflix 的开源 IPC 库，这家公司已经被证明是微服务相关 DevOps 工具的重量级公司。


· Kubernetes Ingress controllers - 虽然此功能依赖于Beta Kuberenetes资源，但它代表了在 Kuberenete s中实现L7负载均衡的可能性。


总的来说，Envoy 给我们留下了深刻的印象，在后续的Bugsnag的开发和拓展中，我们将继续探索其特色。有一件事是肯定的，现在这方面是 DevOps 的一个热点，我们非常关注下一步它将如何发展。


Bugsnag会自动监视应用程序是否存在有害错误，并告警，可视化到软件内部。您可以将我们看成软件质量的中控台。免费试用14天的Bugsnag，包括用于跟踪发布健康状况的发布仪表板。


原文地址：https://blog.bugsnag.com/envoy/