Slack：将百万并发的Websockets迁移到Envoy代理
点击上方 “ 常柱 ” ，马上关注
Slack拥有分布在全球的客户群，在高峰时期有数百万同时在线连接的用户。用户之间的大部分交流都涉及向彼此发送大量的消息。
在Slack的历史中，我们使用HAProxy作为所有接入流量的负载均衡器。今天，我们将讨论我们在HAProxy上面临的一些问题，我们如何通过Envoy代理来解决这些问题，和迁移过程中的具体步骤，以及迁移后的效果是什么。
就让我们来一探究竟吧!
Slack的Websocket
为了即时的传递消息，我们使用了Websocket通讯协议，这是一种双向通信连接，它负责让你看到“几个人在打字……”，然后是他们输入的东西，传输速度快到如光速一样。
Websocket连接被聚合到一个名为“wss”(Websocket服务)的系统中，并通过ws-primary.slack.com和ws-backup.slack.com提供网络请求(这不是一个网站，如果你要访问，只会得到一个HTTP 404 的反馈)。
Websocket 连接以常规的HTTPS连接开始，然后客户端发出协议切换请求，将连接升级为 Websocket。在Slack，我们有不同的 Websocket 服务，专门用于消息、在线联系人(列出哪些联系人在线)和其他的服务。其中一个Websocket 端点是专门为需要与Slack交互的应用程序设计的(因为应用程序也需要实时通信)。
在过去，我们在多个AWS区域有一组专门用于Websocket的HAProxy实例，用于终止靠近用户的Websocket连接，并将请求转发给相应的后端服务。
迁移动机
自从Slack诞生以来，我们就一直在使用HAproxy，并且知道如何大规模地应用它，但因为一些运营上的挑战，使我们不得不考虑使用可能的替代方案，比如Envoy Proxy。
热重启（Hot Restarts）
在Slack，后端服务端点列表发生变化是一件很常见的事情（由于实例被添加或循环使用）。HAProxy 提供了两种方法来更新其配置，以适应端点列表的变化：
•一种是使用HAProxy Runtime API；•另一种方法，我们用于 Websockets 负载均衡器（LB），是将后读入到HAProxy的配置文件中，然后重新装载HAProxy。
每次重载HAProxy，都会创建一组新的进程来处理新的传入连接。我们会让旧进程持续运行很多小时，以让长寿命的Websocket 连接耗尽，避免用户频繁断开连接。然而，我们不能有太多的HAProxy进程运行时都带有自己的“当时”配置副本：我们希望实例能更快地收敛到新版本的配置上来。我们必须定期回收旧的HAProxy进程，并限制HAProxy重新加载的频率，以防止基础后端出现混乱。
无论我们使用哪种方法，都需要一些额外的基础设施来管理HAProxy的重新加载。
Envoy允许我们使用动态配置的集群和端点，这意味着如果端点列表发生变化，则不需要重新加载。如果代码或配置确实发生了变化，Envoy有能力在不中断任何连接的情况下热启动自己。Envoy通过inotify监视文件系统配置以获取更新。Envoy还能在热重启时将统计数据从父进程复制到子进程，因此仪表和计数器不会被重置。
所有这些都大大减少了Envoy的运营开销，并且不需要其他服务来管理配置更改或重新启动。
负载均衡功能
另外，Envoy提供了几种先进的负载均衡功能，例如：
•内置支持区域感知路由；•通过异常值检测进行被动的健康检查；•紧急路由：Envoy通常只将流量路由到运行状况良好的后端，但是，如果运行状况良好的主机的百分比降至阈值以下，则可以将其配置为将流量发送到所有运行状况良好或不健康的后端。
由于上述原因，我们决定在2019年从 Websockets 堆栈开始将入口负载均衡层从 HAproxy 迁移到 Envoy Proxy。
迁移的主要目标是提高可操作性，使用 Envoy 提供的新功能以及更加标准化。通过在整个 Slack 上从 HAProxy 迁移到Envoy，我们将不需要团队了解两个软件的特殊差异，维护两种不同的配置，管理两个构建和发布管道等等。
当时，我们已经在 Service Mesh 中使用 Envoy Proxy 作为数据平面（data plane）。我们还有内部经验丰富的 Envoy 的开发人员，因此我们随时可以获取 Envoy 的专业知识。
生成Envoy配置
迁移的第一步是检查我们现有的 Websocket 层配置，并生成等效的 Envoy 的配置。在迁移过程中，管理 Envoy 配置是我们面临的最大挑战之一。Envoy 具有丰富的功能集，其配置与HAProxy的配置完全不同。Envoy 的配置主要涉及四个概念：
•监听器（Listeners），用于接收请求，aka TCP套接字，SSL套接字或Unix域套接字；•集群（Clusters），代表我们向其发送请求的内部服务，例如消息服务器和状态服务器；•路由（Routes），将监听器和集群粘合在一起•过滤器（Filters），对请求进行加工操作
Slack的配置管理主要是通过 Chef 来完成的。当开始使用 Envoy 时，我们将 Envoy 配置部署为 Chef 模板文件，但管理起来变得繁琐且容易出错。为了解决此问题，我们构建了 Chef 库和自定义资源来生成 Envoy 配置。
在 Chef 内部，配置是一个 Singleton，模拟了每个主机只有一个 Envoy 配置。所有的 Chef 资源都在该 Singleton 上运行，添加了监听器，路由或集群。在chef运行结束时，envoy.yaml会被生成、验证，然后安装：我们永远不会编写中间配置，因为它们可能是无效的。
下面这个例子展示了我们如何创建一个HTTP监听器和两个路由，将流量路由到两个动态集群。
在 Envoy 中复制我们复杂的 HAProxy 的配置需要一些努力。大部分所需的功能在 Envoy 中都已经有了，所以只需要在 chef 库中添加对它的支持就可以了。同时，我们实现了一些缺失的 Envoy 功能（一些是在上游贡献的，有些是在内部作为扩展进行维护的）。
测试和验证
测试新的 Envoy Websockets 层是一个反复迭代的过程。我们经常用手工编码的 Envoy 配置做原型设计，并在一台开发机器上进行本地测试，每台机器都有一个监听器、路由和集群。一旦手工编码的改动成功，就会被移到 chef 库中。
HTTP路由通过curl来做测试：
•特定的基于标头和cookie的路由到特定的后端•基于路径，前缀和查询参数的路由到特定后端•SSL证书
当事情没有按照预期进行时，我们在本地的机器上使用了 Envoy 调试日志记录：调试日志可以清楚地解释为什么Envoy 选择将一个特定的请求路由到一个特定的集群。Envoy调试日志非常有用，但也很冗长和昂贵（你真的不希望在你的生产环境中启用）。调试日志可以通过Curl启用，如下图所示。
curl -X POST http://localhost:<envoy_admin_port>/logging?level=debugEnvoy 管理界面在初始调试中也很有用，尤其是以下端点：
•/clusters： 显示所有配置的集群，包括每个集群中所有上游主机的信息，以及每个主机的统计数据。•/certs： 以JSON格式显示所有已加载的TLS证书，包括文件名，序列号，主题备用名称和到期日。•/listeners： 显示所有配置的监听器及其名称和地址。
我们的Chef库在运行Envoy时使用-mode validate的命令行选项作为验证步骤，以防止安装无效的配置。这也可以手动完成。
也可以手动完成：
sudo /path/to/envoy/binary -c </path/to/envoy.yaml> --mode validateEnvoy 提供 JSON 格式的监听器日志。我们将这些日志提取到我们的日志记录管道中（当然是在对日志进行PII处理后），这通常对调试是很有帮助的。
一旦对开发环境中的配置有了信心，我们就可以在生产环境中进行更多的测试了。
投入生产
为了将迁移过程中的风险降到最低，我们建立了一个新的 Envoy websocket 协议栈，其配置与现有的 HAProxy 层完全一致。这意味着我们可以将流量逐步、可控地转移到新的Envoy协议栈中，并且在必要时可以快速切换回HAProxy。缺点是我们的AWS成本增加，因为我们在迁移过程中使用了双倍的资源，但我们愿意花时间和资源为客户透明地进行这种迁移。
我们通过 NS1 管理我们的 DNS 记录wss-primary.slack.com和wss-backup.slack.com。我们使用加权路由将流量从 haproxy-wss 转移到 envoy-wss 的 NLB DNS记录上。第一批区域分别按10%、25%、50%、75%和100%的步骤推进。最后的区域完成得更快（25%、50%、75%、100%只用了两天时间，而之前的一个区域用了一周时间），因为我们对新的 Envoy 层和迁移过程有信心。
尽管迁移过程顺利且无故障，但还是出现了一些小问题，例如超时值和头文件的差异。在迁移过程中，我们进行了多次还原、修复和再次推进。
经过漫长而激动人心的6个月，迁移工作已经完成，整个HAProxy Websocket 协议栈在全球范围内被 Envoy Proxy 所取代，对客户的影响为零。
好的和坏的
迁移过程本身是比较平淡无奇的，也是比较无聊的。无聊是件好事：刺激意味着事情会被打断，无聊意味着事情会顺利的继续下去。
我们发现，旧的 HAProxy 配置随着时间的推移而有机地增长。它在很大程度上是由 HAProxy 使用的模型形成的：一个包括所有监听器的大型配置。Envoy 的配置模型使用的范围比 HAProxy 的模型定义得多。一旦输入一个监听器，只有该监听器内的规则适用于请求。一旦输入一个路由，只有该路由上的规则适用。这使得将规则与相关请求关联起来变得更加的容易。
从旧的 HAProxy 配置中提取出重要的内容需要花费很多时间，这实际上是技术债务。通常很难弄清楚为什么要制定某个规则，哪些是有意的，哪些是无意的，以及其他服务依赖什么行为。例如，有些服务本来只应该在两个虚拟主机（vhosts）中的一个之下，但实际上在 HAProxy 中两个vhosts下都可以使用。我们必须复制这个错误，因为现有的代码依赖于该行为。
我们忽略了 HAProxy 堆栈中一些微妙的东西。有时这些都是很重要的，我们破坏了 Slack 的每日活跃用户（DAU）指标（糟糕！）。还有很多小问题需要修复。负载均衡器的行为很复杂，除了时间和调试之外，没有其他更好的办法解决这类问题。
我们在没有针对负载均衡器配置的测试框架的情况下开始迁移。我们没有使用自动测试来验证将测试URL路由到正确的端点以及与请求和响应标头相关的行为，而是使用 HAProxy 配置。测试在迁移期间很帮助的，因为它们可以提供有关预期行为原因的大量上下文信息。因为我们缺乏测试，所以我们经常不得不与服务所有者联系，以查明他们所依赖的行为。
我们构建的 Chef 资源有意地只支持 Envoy 功能的一个子集。这使得我们的库更加简单，我们只需要考虑我们实际使用的功能。缺点是，每次我们想要使用新的 Envoy 功能时，我们都必须在 Chef 库中添加对它们的支持。例如，SNI(https)监听器是在开发的中途编写的，当时我们认为这比为现有的监听器添加支持更简单。然而，当涉及到 vhost 支持时，我们已经开发和使用了大量的代码，以至于重构整个公司其他地方正在使用的资源会花费很长时间。我们 Chef 库中的 vhost 支持是一个hack（我们会很快将它修复）。
为了更安全地更改 Envoy 资源 的 Chef 库，换句话说，为了确保我们没有破坏其他使用我们库的团队，我们引入了一套全面的测试，生成这些团队的整个配置。这样就可以很容易地判断出当我们更新 Envoy Chef资源时，我们所有生成的 Envoy 配置会（或不会）受到怎样的影响。
在这次迁移中（和其他迁移一样），其中一个关键的问题就是沟通。我们努力让每个人都知道我们正在做的改变，并与之保持一致。我们的客户体验（CE）团队是一个很好的合作伙伴，他们能够监控收到的工单，以发现任何可能表明用户因这次迁移而受到影响的情况。
下一步
尽管偶尔会遇到一些小挫折，但 Envoy Websocket 迁移还是非常成功的。我们又将另一个关键的 Slack 服务，我们的软件客户端指标提取管道（与其他入口负载均衡器隔离）迁移到了 Envoy Proxy。我们即将完成将 Web 和 API 流量的内部负载均衡器迁移到 Envoy 上。这个史诗般的迁移的最后一部分是将我们的（常规的、非 Websocket的）HTTP协议栈从 HAProxy 迁移到 Envoy，这也正在进行中。
我们现在即将实现我们的最终目标，即为我们的入口负载均衡器和服务网状数据平面实现 Envoy Proxy 的标准化，这将大大降低团队的认知负担和操作复杂性，并使 Envoy 的高级功能在整个负载均衡基础设施中可用。自从迁移到 Envoy 后，我们的负载已经大大超过了之前的峰值，但没有出现任何的问题。
原文：https://slack.engineering/migrating-millions-of-concurrent-websockets-to-envoy/
作者：Ariane van der Steldt & Radha Kumari
推荐阅读：
顺手来个在看和转发吧