随着对同步引擎和实时功能的需求不断增长，websocket 已成为现代应用程序的关键组件。在 compose，websocket 构成了我们服务的支柱，为我们的后端 sdk 提供支持，使开发人员能够仅使用后端代码来交付低延迟的交互式应用程序。
但是，事实证明，扩展 websocket 比我们预期的要复杂得多。以下是我们一路走来学到的一些最重要的经验教训。
优雅地处理部署
用户永远不应该注意到部署何时发生，因此 websocket 连接需要在部署之间保持不变。这是一个微妙的过程，需要强大的重连逻辑来处理意外问题。在 compose，我们通过以下步骤实现了近乎零的停机时间：
启动新服务器。
一旦新服务器健康，旧服务器开始返回 503 service unavailable 响应来进行健康检查。
连续 4 次 503 响应后，负载均衡器声明服务器不健康，并从池中删除旧服务器。负载均衡器健康状况检查每 5 秒一次，因此此过程最多需要 25 秒。
旧服务器发送自定义 websocket 关闭消息，指示客户端以随机间隔延迟重新连接，以避免重新连接激增。
- 自定义关闭消息可让客户端在客户端断开连接的约 10 秒期间向用户显示更准确的消息。
- 随机延迟有助于防止所有客户端立即重新连接的雷群问题。客户端还将与部署相关的重新连接的指数退避加倍，以解决不可预见的问题。
- 关闭消息延迟 20 秒，以考虑负载均衡器转移流量所需的时间。
一旦所有客户端断开连接，旧服务器就会完全关闭。
如果您使用 render 或 railway 等托管服务，您应该特别注意客户端连接在部署期间会顺利传输。
许多标榜零停机部署的托管服务将等到所有未完成的请求都得到处理后再关闭服务器。由于 websocket 连接是持久的，这可能会导致旧服务器在部署后活跃几分钟甚至几小时，直到托管服务强制终止进程。
建立一致的消息模式
虽然 http 带有内置路由约定（get /用户、post /公司、put /设置），但 websocket 要求开发人员定义自己的架构来组织消息。
在 compose 中，每个 websocket 消息都以固定的 2 字节类型前缀开头，用于对消息进行分类。
它节省空间（仅 2 个字节），同时仍可扩展到 65,536 种不同类型。
Scrapfly SDK TypeScript下载使用 Scrapfly SDK（scrapfly-sdk）在 TypeScript 或 JavaScript 中进行网页抓取，用于用户请求抓取 URL、绕过反爬虫防护、渲染页面等场景。
它使客户端能够可靠地从消息中分割类型前缀，而不影响其余数据，因为前缀始终为 2 个字节。
它为我们提供了一种通过版本控制消息类型来升级 api 的简单方法。
const message_type_to_header = {
render_ui: "aa",
update_ui: "ab",
show_loading: "ac",
render_ui_v2: "ad",
/* ... */
}
此外，我们使用分隔符来分隔消息中的不同字段，这比 json 编码/解码速度更快，而且内存效率更高。
const DELIMITER = "|";
function createDelimitedMessage(type: string, args: any[]) {
return [MESSAGE_TYPE_TO_HEADER[type], ...args].join(DELIMITER);
}
function parseDelimitedMessage(message: string) {
const [type, ...args] = message.split(DELIMITER);
return { type, args };
}
我们很幸运，我们的后端和前端都是用 typescript 编写的，这使我们能够在两者之间共享消息模式并确保两者都不会不同步。
通过心跳检测静默断开连接
连接可能会在不触发关闭事件的情况下意外断开，从而导致客户端认为它们已连接但实际上并未连接的情况。为了防止连接失效，实现强大的心跳机制至关重要。
我们在客户端和服务器之间定期发送 ping/pong 消息，并在一段时间内未收到心跳的情况下重新连接。
我们的服务器每 30 秒发送一条 ping 消息，并期待 pong 响应。如果客户端没有每 45 秒收到一次 ping，它会立即断开连接并尝试重新连接。同样，服务器会在 45 秒内关闭错过 pong 响应的连接。
通过监控两端的心跳，我们检测并处理客户端网络看似正常但服务器从未收到响应的罕见情况。
有 http 后备
websocket 连接可能会被意外阻止，尤其是在限制性公共网络上。为了缓解此类问题，compose 使用服务器发送事件 (sse) 作为接收更新的后备，而 http 请求则处理客户端到服务器的通信。
由于 sse 基于 http，因此被阻止的可能性要小得多，从而在受限环境中提供了可靠的替代方案。此外，它仍然实现了相当低的延迟，特别是与短轮询解决方案相比。
结论性想法
还有很多关于扩展 websocket 的内容，我们在此没有介绍。例如：
- 缺乏标准工具：虽然大多数框架都包含用于速率限制、数据验证和错误处理的内置工具，但您通常必须为 websocket 自行实现这些功能。
- 无法缓存响应：边缘网络可以轻松缓存靠近用户的 http 响应，但没有标准方法可以使用 websocket 来实现此目的。
- 每条消息身份验证：通过在处理每条消息之前确保每条消息对该用户有效来防止滥用。
但无论复杂性如何，用户都希望现代应用程序能够快速、实时和协作。而且，到目前为止，没有比 websocket 更好的方法来实现这一目标。
在 compose 中，websocket 为整个平台提供支持 - 从数据库一直到主 ui 线程。通过我们的 sdk，开发人员可以从其后端逻辑生成完整的 web 应用程序。确保这些应用程序快速且大规模性能需要 websocket。如果您有兴趣了解更多信息，请查看我们的文档。安装 sdk 并构建您的第一个应用程序只需不到 5 分钟。
