北京
从几千并发用户到数万人同时在线，系统崩溃只在一瞬间。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.
