2026 年 1 月 27 日，Cloudflare 工程团队在官方博客宣布成功将「完整的 Matrix homeserver」移植到 Workers 平台，声称消除了传统自托管的全部运维负担。这一声明在 Hacker News 迅速引发争议，批评文章「They didn't」获得超过 130 个赞同。争议的核心并非 Workers 能否运行部分 Matrix 功能，而是「完整实现」与实际架构可行性之间的差距。本文从工程视角出发，对照 Matrix 联邦协议规范与 Workers 运行时约束，验证该声明的实现边界与部署参数。
联邦协议的架构要求
理解声明的争议性，首先需要明确 Matrix 协议对 homeserver 的核心要求。Matrix 是一个去中心化的即时通讯协议，其设计围绕「联邦」展开：多个 homeserver 通过开放的 HTTP API 交换签名事件，形成统一的聊天历史与房间状态。这一架构决定了 homeserver 必须具备的能力集。
根据 Matrix 规范，联邦通信涉及三类核心数据传输单元：持久数据单元（PDU）负责在服务器间广播消息与状态变更，临时数据单元（EDU）处理一次性通知如在线状态，而查询接口则提供实时的信息快照。这三类通信均封装在事务（Transaction）中，通过 HTTPS PUT 请求在服务器间传递。每个 homeserver 必须维护与其他联邦服务器的持久连接池，跟踪待办事务队列，并能够在连接中断时重试投递。从运行时角度看，这意味着服务器需要长时间运行的进程、内存中的状态缓存、以及主动向对端推送事件的能力。
此外，联邦发现依赖 DNS SRV 记录或 .well-known/matrix/server 文件完成服务器定位，要求 homeserver 对公网暴露 443 端口并支持反向连接。当远程服务器需要推送事件时，它会主动发起 HTTPS 请求到本地服务器，这意味着本地服务器必须能够处理传入的持久连接并异步处理后台任务。这些要求共同构成了「完整 Matrix homeserver」的架构基线。
Workers 运行时的约束边界
Cloudflare Workers 是一个无状态的边缘计算平台，其运行时模型与传统服务器存在本质差异。Workers 采用请求 - 响应范式，每次 HTTP 触发执行一次函数调用，执行完毕后实例可能被回收。官方文档明确指出，Workers 不适合需要长时间运行进程的场景，CPU 时间限制在 50 毫秒到 10 秒之间，具体取决于计划类型。这与 Matrix 联邦所需的持久连接和后台任务处理形成了直接冲突。
在连接支持方面，Workers 对 WebSocket 的支持存在严格限制。标准 Workers 不允许持久 WebSocket 连接，仅在特定配置下通过 Durable Objects 才能实现双向通信。即便如此，这些连接的生命周期仍受实例调度影响，无法保证持久性。Matrix 联邦协议虽然主要依赖 HTTPS，但在事件实时性要求较高的场景下，持久连接仍是优化投递延迟的重要手段。Workers 的模型将所有通信限制为短生命周期的请求 - 响应对，服务器无法主动向远程对端推送事件。
存储层面，Workers 提供了 D1（SQLite）、KV（键值缓存）、R2（对象存储）和 Durable Objects（强一致性存储）等原语。这些确实可以映射 Matrix 的数据模型：D1 存储事件与用户，KV 处理临时令牌，R2 托管加密媒体，Durable Objects 保证关键操作的原子性。然而，存储的可用性并不等同于运行时能力的完整性。Workers 无法维护跨请求的服务器间连接状态，无法执行后台调度任务，也无法在无人请求时主动推送待办事件到远程服务器。
工程差距的量化分析
将 Matrix 联邦要求与 Workers 能力对照，可以识别出几个可量化的工程缺口。第一个缺口是联邦推送模型的不兼容性：Matrix 要求 homeserver 能够主动向远程服务器发起持久 HTTPS 连接并保持连接活跃以处理双向通信，而 Workers 仅支持被动请求响应。工程上，这意味着当远程服务器向本地 Workers 发送联邦请求时，请求可以到达；但本地 Workers 无法主动建立并维护到远程服务器的持久连接池来推送出站事件。
第二个缺口是后台任务的缺失。Matrix 联邦需要处理连接失败后的重试队列、待办事务的定时重试、以及远程服务器的在线状态检测。这些任务需要独立于用户请求的后台调度能力，而 Workers 的事件驱动模型不允许这种执行模式。任何重试逻辑都必须在单次请求调用内完成，这限制了可实现的联邦可靠性级别。
第三个缺口是 DNS 与 SRV 发现机制的限制。Matrix 联邦依赖 DNS SRV 记录进行服务器发现，而 Workers 的自定义域名配置虽然在 2024 年后支持 SRV 记录，但运行时不负责维护这些记录的实时查询状态。远程服务器在尝试连接时可能遇到记录更新延迟或配置错误，而 Workers 无法主动验证或更新这些元数据。
基于这些差距，可以给出部署决策的边界参数：如果用例仅涉及单服务器内部的消息传递与加密存储，Workers 上的 Matrix 实现可以满足需求，延迟可控制在 20-50 毫秒（全球边缘分布），成本低于每月 1 美元（空闲状态）或 3-10 美元（活跃使用）。但如果需要与其他 Matrix 服务器联邦通信，参与公开或私有的联邦网络，则当前的 Workers 架构无法满足协议要求。强行使其加入联邦将导致事件丢失率上升、状态同步延迟增加、以及潜在的联邦安全策略违规。
部署前的评估清单
对于考虑在 Workers 上部署 Matrix 的开发者，以下检查项可帮助评估用例匹配度。首先确认是否需要联邦：如果所有用户都在同一 Workers 实例注册且不与其他服务器交换消息，则架构兼容；如果需要加入 Matrix 联邦网络，则当前实现存在能力缺口。其次评估消息频率与存储增长：D1 的写入限额与 KV 的请求频率限制会影响大规模部署的成本模型，官方建议的 25 张表覆盖完整数据模型，但长期运行时的数据库迁移与模式变更需要额外考虑。
加密密钥管理是另一个关键点。虽然 Workers 可以处理 Megolm 密文的存储与分发，但私钥必须在用户设备上生成且永不离开设备，这对客户端兼容性提出了要求。Element 等主流客户端已支持此模型，但自实现客户端需要确保遵循相同的密钥流规范。最后，安全团队应验证 OAuth 实现是否符合 Matrix 规范中的 PKCE 流程与令牌轮换要求，避免实现中的令牌固定或过期策略不当导致的安全风险。
结论
Cloudflare 的 Workers Matrix 实现展示了将复杂有状态协议映射到无状态边缘平台的工程能力，证明了 D1、KV、R2 与 Durable Objects 组合在消息存储、缓存与原子操作上的可行性。然而，「完整 Matrix homeserver」的声明在联邦协议层面存在架构差距：主动推送、持久连接池与后台任务调度等能力在 Workers 模型中无法实现。这并非代码质量问题，而是平台约束与协议设计之间的根本不匹配。
对于寻找低运维成本 Matrix 部署方案的个人或团队，Workers 实现可以满足封闭社群的通信需求，享有全球低延迟与自动扩展的优势。但任何需要加入公开联邦网络的场景，都应等待架构演进或选择传统的 Synapse/Conduit 部署。技术声明的准确性对建立信任至关重要，尤其是在安全通信这类对可靠性高度敏感的领域。
参考资料
- Cloudflare Blog: Building a serverless, post-quantum Matrix homeserver (2026-01-27)
- Hacker News Discussion: Cloudflare claimed they implemented Matrix on Cloudflare workers. They didn't (2026-01-27)