摘要

  • 8 月 19 日 06:59 UTC，Cloudflare 开始调查香港区域 “Durable Objects” 过载错误升高的问题；07:06 宣布已实施修复，07:20 将事件标记为已解决，记录窗口约 21 分钟。
  • 组件记录只把 “Durable Objects” 从正常改为性能下降。香港节点、RealtimeKit 与 Realtime SFU 始终显示正常，尽管事件说明称这些依赖产品的用户也可能遇到过载错误。

香港节点是绿色，“Durable Objects” 却被标为性能下降。这两条状态在 8 月 19 日同时成立。

Cloudflare 的事件记录显示，调查从 06:59:19 UTC 开始。公司称，香港区域可能有多名客户受到影响；使用 “Durable Objects”，以及 RealtimeKit、Realtime SFU 等依赖产品时，可能看到更多过载错误。07:06:33，Cloudflare 表示已实施修复并开始观察；07:20:23，事件结束。

从系统记录的开始时间到结束时间约为 21 分钟，影响等级为 minor。但公开信息没有说明根因、修复内容、受影响客户数、请求错误率、对象 ID 或命名空间，也没有给出数据完整性结论。可以确认的是短时区域性降级，不能扩写成香港全站宕机。

状态组件的变化把报道重点从“持续多久”推进到“究竟什么在出错”。“Durable Objects” 从 operational 变为 degraded_performance。同一份数据里，香港 HKG 节点、RealtimeKit 和 Realtime SFU 的旧状态与新状态都是 operational。事件正文却明确提醒，后两类产品的用户可能收到过载错误。

这不是简单的颜色矛盾。节点状态描述较宽的基础设施边界，产品错误描述具体操作路径。一个位置仍能收发流量，不代表依赖状态协调的每次调用都能完成。绿色地图能说明区域没有整体下线，却不能为每个上层服务提供端到端证明。

“Durable Objects” 的设计让这一区别更加重要。Cloudflare 的产品文档称，每个对象把计算与私有、事务性、强一致存储放在一起，并拥有全球唯一名称。多个客户端可以把同一对象当作协调点，维护聊天室、协作文档、会话、计数器或 WebSocket 连接的共享状态。

单个对象在一个位置、一个线程上执行。许多不同对象可以分散到 Cloudflare 网络并横向扩展，但同一个逻辑对象不是可以随意投向另一个健康边缘节点的无状态请求。若拥有状态的实例路径返回过载错误，“换一个入口”并不会自动复制它的顺序与一致性。

“过载”也不能被当作根因名称。Cloudflare 的故障排查文档列出多种过载情况：排队请求过多、排队数据过大、最早请求等待过久，或短时间内同一对象收到极端数量的调用。香港事件没有指出具体类型，更没有说客户流量、对象拆分或重试造成了这次多客户事件。

不过，文档给出了避免扩大故障的方法。Cloudflare 在错误处理指南中建议，不要立即重试带有 .overloaded 标记的异常，因为新增请求会进一步提高过载与错误率。这是通用规则，并不证明本次每条错误都带有该标记。应用必须先识别错误，再决定指数退避、拒绝写入或切换到受限模式。

Realtime 侧还需要拆开控制面与媒体面。Cloudflare 把 RealtimeKit 定义为直播音视频 SDK 与 API，并说明它构建在负责音视频路由的 Realtime SFU 之上。事件没有透露出错的是会议创建、参与者状态、信令、轨道管理还是媒体转发，也没有证据表明通话终止、录制丢失或所有会议失败。

客户自己的证据可以缩小这一空白。Cloudflare 提供按命名空间和请求查看的 “Durable Objects” 指标，并允许用对象 ID 或名称筛选。把 06:59 至 07:20 的调用错误、延迟、对象集中度和业务失败放到同一时间线上，才可能判断影响是广泛的还是集中在少数协调单元。

本事件也不能与当天稍晚开始的 HKG 互联维护相连。已封存来源没有给出任何因果关系。相同城市代码与日期不等于相同机房、设备、线路或变更。

21 分钟的恢复速度限制了已知影响，却没有消除架构问题：当强一致协调点不可用时，业务准备牺牲什么？更多对象分片可以降低单点热点，受控退避可以避免放大，幂等设计可以安全重试，只读或暂停部分功能可以保住核心路径。但任何选择都要明确哪些状态可以延迟、哪些写入不能重复。

因此，下一项真正有价值的证据不是“香港在线”或“香港离线”的二选一，而是 Cloudflare 对根因、过载模式、影响产品和修复措施的说明，再与客户对象级监测相互印证。当前事实更窄也更可靠：有状态产品降级约 21 分钟，而绿色节点状态没有覆盖这条应用链路。

来源