Uber 实时聊天架构的演进

Uber 将其基于 WAMP 协议的旧架构替换为一种利用 GraphQL 订阅的新解决方案。这一变革的主要驱动力包括可靠性、可扩展性、可观测性/可调试性方面的挑战，以及技术债务阻碍了团队维护现有解决方案的能力。

背景与挑战

Uber 拥有庞大的用户群体，分为多种角色（乘客、司机、食客、快递员和商家）。公司支持实时（电话、聊天）和非实时（应用内消息）支持渠道。历史数据显示，2019 年至 2023 年初，仅有 1% 的客户互动通过实时聊天渠道处理，而 58% 通过应用内消息（非实时）处理。

Uber 的 Staff 软件工程师 Avijit Singh 强调了实时支持渠道的重要性，指出它在提供高质量客户支持的同时，能够有效降低每次联系的成本（CPC），并提高自动化率、员工效率（客服可以同时处理多个聊天）和首次接触解决率（FCR）。

公司希望将至少 40% 的客户互动转移到实时聊天支持，但现有架构存在诸多问题，包括 46% 的消息未能及时送达、缺乏可观测性和健康监控、吞吐量极低（10 tps）以及无法水平扩展。此外，WAMP 协议和库已被弃用，导致洞察和调试困难，且升级路径复杂。

新架构的设计目标

团队的目标是创建一个新架构，能够初步扩展到处理 40% 的总体联系量，并在一年内扩展到 80%。该架构从一开始就支持可观测性和可调试性，倾向于无状态服务，并实现超过 95.5% 的消息送达成功率。

新架构的组成

新架构包括客服使用的前端 UI 和几个后端微服务。其中，Chat Channel Manager、Contact Service 和 Router 负责接收联系并将其分配给可用的客服。Agent State Service 负责跟踪客服的活跃联系会话。服务使用 Apache Kafka 发布事件/通知，支持路由和客服状态跟踪之间的同步。

解决方案的核心是 GraphQL 订阅服务，它使用 WebSockets 支持双向通信。UI 通过 graphql-ws 库与服务器集成。团队实施了多项以提高可靠性为导向的增强功能，包括自动重新连接以恢复中断的聊天会话，以及客服浏览器与聊天服务之间的心跳机制。

测试与成果

工程师在生产上线前进行了全面的负载测试，验证了新解决方案能够在单台服务器上支持约 10,000 个连接，并支持水平扩展。团队还投入了大量精力增强可观测性工具，以提供对系统性能和服务水平协议（SLA）的全面洞察。新架构上线后，实时聊天渠道处理了 36% 的总体联系量，消息送达的可靠性大幅提高（错误率从 46% 降至 0.45%）。

相关新闻

InfoQ 最近报道，The Guardian 也在其新闻编辑室协作和资产共享工具 Pinboard 中使用了 GraphQL。