04

实时消息与 Ably：为何不自己扛全套 WebSocket

这套平台没有把“实时连接管理、频道发布、在线状态、推送设备管理”全压在业务服务上，而是借 Ably 拿到一条更轻的主链。是否值得，取决于你的复杂度与团队成本。

Ably 在这里，不只是“发消息 SDK”

从代码看，它承担了 Token 授权、频道收发、批量发布、推送设备与在线态相关能力。换句话说，这里不是“业务服务顺手连了个推送工具”，而是把实时基础设施外包给了托管服务。

🎫

Token 授权

业务服务只签权限票据，不亲自维护所有实时连接，职责更清楚。

📡

频道分发

单聊 mailbox、群聊 channel、会议 signal 都走统一实时通道，路径短、感知快。

🔔

推送配套

设备管理与批量推送能力已在同一服务栈里，减少自建消息网关成本。

🧮

业务服务减负

App 服务不必自己扛海量长连接，更多精力放在鉴权、持久化、未读与业务规则。

看数据怎么在实时层与后台层分流

真正聪明的地方不只是“用了 Ably”，而是“用了 Ably 以后，业务服务没有被绑死”。消息先被实时送达，后面再用 SQS 和消费者做持久化与派生。

📱
客户端
🛂
im-app-server
⚡
Ably
📮
SQS
🧰
Consumer
点“下一步”看实时链与后台链怎样分开

真实代码：Token 能做什么，基本写死在这一处

这段码是实时边界的钥匙孔。你要理解 Ably 在项目中的地位，看这一段就够了。

代码 

    const token = await ablyservice.createTokenRequest(userHandle, {
      capability: {
        "chat:mailbox:*": [
          "publish",
          "subscribe",
          "history",
          "presence",
          "push-subscribe",
        ],
        "chat:group:*": [
          "publish",
          "subscribe",
          "history",
          "presence",
          "push-subscribe",
        ],
        "chat:ack": ["publish"],
      },
      ttl: 60 * 60 * 1000,
    });
白话

业务服务不是直接替客户端开频道，而是签一张限权 Token。

mailbox、group、ack 被拆成不同频道类型，说明实时系统内部也在分职责。

这里不只有发和收，还有历史、在线态、推送订阅等能力位。

所以 Ably 在本架构中更像“托管式实时总线”，不是单点消息 SDK。

🧭
那有没有更好的选择

没有绝对更好，只有更适合。若你要极快起量、又不想自养连接集群，Ably 很顺手；若你已深度押注 GraphQL，可考虑 AppSync；若需求更轻，Pusher 也常见；若规模巨大且团队强，自建 WebSocket 网关也并非不可。

小测：什么时候该继续用 Ably，什么时候考虑换

一个小团队要快速上线多端 IM，且不想先维护大规模长连接集群，哪种取舍最像当前架构？

什么时候你更可能认真评估 AppSync 一类替代，而不是继续沿 Ably 路线？

若用户说“对方已收到消息，但未读数和历史列表不同步”，你第一反应应是什么？