从几千并发用户到数万人同时在线,系统崩溃只在一瞬间。WebSocket连接风暴、尾延迟飙升、应用层里大量临时拼凑的记账代码——这些在测试环境看似微不足道的问题,在生产环境变成了致命伤。
这是一家多租户SaaS公司的真实经历。当一个大客户启动数千个长时推理会话,多个AI代理实时交换消息时,表面平静的系统开始显露裂痕。
![]()
首先是连接数突破了粘性路由的假设,断连频繁发生。其次是消息顺序保证在重试机制下变得不可靠。更棘手的是,编排状态——谁在等待哪个代理的响应——全部存放在应用内存里,重启即丢失。运营复杂度随之爆炸:自定义背压、租户级限流、重试逻辑遍布代码库。
一个常被忽视的真相:基础设施开销才是真正的瓶颈,而非原始算力。
团队最初尝试了三种方案。第一种是托管消息代理配合应用内会话映射,原型搭建快、基础设施少,但跨实例无法恢复会话,顺序问题频发,每条消息都要处理重试。第二种是粘性WebSocket路由,把会话状态留在本地以避免序列化开销,但节点替换时失效、拖累自动扩缩容、让部署充满风险。第三种是用数据库事务加轮询实现编排,状态持久化了,延迟却上去了,数据库成本高昂,且不符合实时语义。
单独看每个选择都合理。但在生产环境中,它们的交互产生了难以调试的边缘情况。
最终的架构转向彻底抛弃了应用内的临时编排,改用事件驱动的编排层来协调实时消息、AI管道和WebSocket可靠投递。核心改动包括:按租户和关注域划分主题的集中式事件流;消费编排事件、仅持久化最小进度标记的有状态工作节点;只负责连接生命周期和消息投递的轻量WebSocket网关;以及事件摄取、编排、执行、投递四层之间的清晰隔离。
这一改动砍掉了一层原本计划自建的模块,消除了大量横切重试逻辑。
具体生效的决策有两项。一是按租户加会话ID分区,既保证所需场景的顺序性,又分散负载,防止同一主题分区内的噪声邻居。二是采用幂等的小型事件,每个事件描述一个动作并包含单调时间戳。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.