WAX技术指南第14期：怎样在WAX负载均衡器上配置Websocket支持

我们的WAX 技术指南第#5、#6和#13期，探讨了构建、配置和优化可靠的 WAX 负载均衡器的主题。在过去的几个月里，社区的一些成员反馈引起了我的注意，那就是另一个具体的反向代理用例。

Atomic API 和 Hyperion 等 WAX 网络提供的服务非常依赖弹性状态历史服务，也称为状态历史协议 (SHIP) 节点。WAX 技术指南#7中有更多详细信息。与其他 WAX 软件 HTTP API 不同，State-History 使用称为 websocket 的双向通信协议，HAProxy 也支持该协议。

第 14 期 WAX 技术指南将向您展示如何配置 HAProxy 以支持多个状态历史节点之间的 websocket 弹性和负载平衡。

Websockets 通过 WAX 软件状态历史服务使用的单个 TCP 连接在客户端和服务器之间创建全双工连接。为了提供此 SHIP 服务的负载平衡和冗余，需要支持 websockets 的反向代理。

HAProxy 具有非常巧妙的自动化能力，可以使用 Connection: Upgrade 和 Upgrade: websocket HTTP headers 将现有的 HTTP 连接升级到 TCP websocket。 它也可以配置为简单地识别将直接指向 websocket 服务器或 SHIP 的特定 URL。

一旦建立了 websocket TCP 通道连接，它将保持连接状态，直到其中一个节点终止或达到会话超时为止。下面是我从 HAProxy 借用的图表来表示设置流程。

（Websocket流程及各阶段超时）

您可以在 HAProxy 网站上阅读有关使用HAProxy进行Websockets负载平衡的更多信息：https://www.haproxy.com/blog/websockets-load-balancing-with-haproxy/

在我的研究中，我还读到了一篇关于解决 Websocket/HAProxy 超时问题的好文章，您在使用状态历史节点时可能会有所不同，但配置特定的通道超时可能会有好处。我们在 HAProxy 默认设置部分设置为 35 秒，如下所示。

在此示例中，HAProxy 将被配置为识别 websocket 连接+升级标头并将这些请求平衡到一组 WAX 状态历史节点。

请务必查看WAX技术指南第5期，了解有关如何完整构建和配置 HAProxy 的详细信息。

所有 HAProxy 配置都可以在 haproxy.cfg 中找到

在此示例中，目标是：

按照以下示例配置新的  haproxy.cfg  中的每个部分：

配置一个名为 wax_acl 的访问列表来识别对您的 URL 的正常 HTTP 请求，在本例中为 wax.eosphere.io。然后配置两个访问列表，一个用于识别连接升级请求 wax_con_upg_acl，另一个用于识别对 websocket 请求 wax_ws_upg_acl 的升级。

将上述访问列表绑定到后端服务器组，指定 websocket 和普通 HTTP API 的服务器组。在本示例中，配置了以下内容。

如果您已将 HAProxy 配置为在端口 :443 上接受 HTTPS 并提供 SSL 卸载（有关详细信息，请参阅WAX技术指南第5期），您的反向代理将接受 wss: 以及 ws: 连接。是不是比你想象的容易？

配置后端服务器组以匹配您的基础架构并为每个服务器组应用特定策略，在本例中为 HTTP API 服务器和 websocket SHIP 服务器。

下面的配置提供了与上述配置相匹配的示例服务器和策略。特别是 wax_ship_servers 配置为检查是否可用（它们将被标记为关闭并且如果不可用则不使用）并指定最多 200 个连接。

balance leastconn 用于此示例中的 SHIP 服务器，因为从我们的角度来看，它似乎是平衡持久连接的更好方法。

此外，还可以通过针对网络的 headblock 查询后端状态历史服务器的状态来监视/检查后端状态历史服务器的健康状况。社区开发了两种解决方案用于 HAProxy 检查。

当然，您可以通过多种方式为 WAX 服务设置 websocket 负载平衡和弹性，本文中的示例是我们最近在 EOSphere 上的配置方式。在我使用 Atomic API 和 Hyperion 进行的测试中值得注意的一点是，如果 SHIP 节点不在 LAN 上，索引性能可能会降低。所以一定要让你的 SHIP 节点靠近。

关注我们

👇👇