Euro-Office 实时协作架构：CRDT 冲突解决与 WebRTC 同步的工程实践

Euro-Office 作为 ONLYOFFICE 的 AGPLv3 分支，近期由 IONOS、Nextcloud、XWiki 等欧洲厂商联合推出，定位为 "主权办公套件"—— 强调数据主权、代码透明与供应链可信。与独立运行的传统办公软件不同，Euro-Office 采用嵌入式架构设计，作为文档编辑组件集成至文件共享、项目管理或 Wiki 平台中，支持 DOCX、XLSX、PPTX 及 ODF 等格式的实时协作编辑。本文从其实时协作技术需求出发，探讨浏览器端文档编辑中 CRDT 冲突解决与 WebRTC/WebSocket 同步架构的工程实现要点。

CRDT：并发编辑的数学基础

多人实时协作编辑的核心挑战在于冲突解决。当两位用户同时修改文档的同一位置时，系统必须保证最终一致性 —— 即所有协作者最终看到相同的内容，且修改不丢失。CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）为此提供了数学保证。

CRDT 的核心特性在于交换律、结合律与幂等性。以文本编辑为例，每个字符插入操作被建模为带有唯一标识符和位置引用的操作日志。当两个用户分别插入字符 A 和 B 到同一位置时，CRDT 通过预定义的顺序规则（如基于用户 ID 或时间戳的字典序）确定最终顺序，而非简单的时间戳覆盖。这种设计避免了传统 OT（Operational Transformation）算法中复杂的转换逻辑，使实现更为简洁。

在浏览器端实现文档 CRDT 时，需关注以下工程参数：

• 操作粒度：字符级 CRDT 精度高但内存开销大，建议采用词组或段落级作为最小操作单元，平衡精度与性能
• 状态压缩：文档长期编辑会产生大量操作日志，需定期执行 ** 状态快照（snapshot）** 与日志截断，建议每 500-1000 次操作或 5 分钟触发一次压缩
• 内存阈值：单文档客户端内存占用建议控制在 50MB 以内，超过阈值应触发分页加载或历史归档

实时同步架构：WebRTC P2P vs WebSocket 中心化

Euro-Office 的实时协作需要低延迟、高可靠的通信通道。当前主流方案分为两类：WebRTC P2P（点对点）与WebSocket 中心化。

WebRTC P2P 架构

WebRTC 允许浏览器间直接建立连接，数据不经过服务器中转，延迟可控制在 50ms 以内。其架构包含三个关键组件：

1. 信令服务器（Signaling Server）：负责协调连接建立，交换 SDP（Session Description Protocol）与 ICE（Interactive Connectivity Establishment）候选地址。信令服务器不传输实际文档数据，负载极低
2. STUN/TURN 服务器：处理 NAT 穿透，建议部署 TURN 服务器作为中继 fallback，配置比例约为 15-20% 的连接需要 TURN 中继
3. 数据通道（DataChannel）：用于传输 CRDT 操作消息，建议启用有序传输（ordered: true）与可靠传输模式，避免文档状态错乱

P2P 架构的优势在于去中心化与低延迟，适合对数据主权要求极高的场景 —— 文档内容仅在协作者设备间流动，服务器无法访问明文。然而，其挑战同样明显：

• 在线状态管理：需额外实现 presence 服务，追踪用户在线 / 离线状态
• 历史消息同步：新加入用户需从其他在线节点或持久化服务拉取完整文档状态
• 网络分区处理：当协作者网络隔离时，需设计合并策略与冲突提示 UX

WebSocket 中心化架构

WebSocket 通过中央服务器转发所有操作，实现简单且易于调试。Euro-Office 当前采用此方案，Document Server 作为协调中心：

• 操作广播：服务器接收客户端 CRDT 操作后，向所有在线协作者广播
• 持久化保证：文档状态由服务器统一存储，客户端离线后可从服务器恢复
• 权限控制：中央服务器天然支持细粒度权限校验（只读、评论、编辑）

中心化架构的延迟通常在 100-300ms（取决于服务器地理位置），对于文档编辑场景可接受。但其单点故障风险与服务器带宽成本需纳入考量。

混合架构的工程实践

生产环境中，纯 P2P 或纯中心化各有局限。推荐采用分层混合架构：

┌─────────────────────────────────────────────────────────┐
│                    协作会话层                            │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │ Client A │──│ Client B │──│ Client C │  (WebRTC Mesh) │
│  └──────────┘  └──────────┘  └──────────┘              │
│       │              │              │                   │
│       └──────────────┼──────────────┘                   │
│                      ▼                                  │
│              ┌──────────────┐                          │
│              │  Signaling   │                          │
│              │   Server     │                          │
│              └──────────────┘                          │
│                      │                                  │
│       ┌──────────────┼──────────────┐                  │
│       ▼              ▼              ▼                  │
│  ┌──────────┐  ┌──────────┐  ┌──────────┐              │
│  │Document  │  │ Presence │  │  History │              │
│  │ Server   │  │ Service  │  │  Store   │              │
│  └──────────┘  └──────────┘  └──────────┘              │
└─────────────────────────────────────────────────────────┘

在此架构中：

• 活跃协作者（2-5 人）通过 WebRTC DataChannel 直连，享受低延迟编辑体验
• 信令与协调仍由中央服务器处理，简化连接管理
• 持久化与历史由 Document Server 负责，保证数据不丢失
• 大规模协作（>10 人）降级为 WebSocket 广播，避免 P2P Mesh 连接数爆炸（n (n-1)/2 条连接）

可落地的监控与降级策略

实时协作系统需建立完善的监控体系：

降级策略是保障用户体验的关键。当 WebRTC 连接建立失败或不稳定时，应无缝切换至 WebSocket 通道，用户无感知。建议实现连接质量评分机制，根据 RTT、丢包率动态选择最优传输路径。

选型建议与实施 checklist

基于 Euro-Office 的技术路线与开源生态，给出以下选型建议：

适合 CRDT + WebRTC 的场景：

• 2-5 人小团队实时协作
• 对数据主权要求极高（文档内容不出本地网络）
• 低延迟敏感型应用（如代码协作、设计稿评审）

适合 WebSocket 中心化的场景：

• 大规模协作（>10 人同时编辑）
• 需要完善权限审计与版本历史
• 现有基础设施已具备可靠的中央服务器

实施 checklist：

• 选择 CRDT 库（Yjs、Automerge 或自研）
• 部署信令服务器（建议 Node.js + Socket.io 或自研 WebSocket）
• 配置 STUN/TURN 服务器（coturn 开源方案）
• 实现操作防抖与批量发送（建议 50ms 窗口）
• 建立连接健康检查与自动降级机制
• 设计离线编辑与重连合并 UX

Euro-Office 的出现为开源办公套件提供了新的选择，其基于 AGPLv3 的透明治理模式与欧洲厂商的联合背书，使其成为关注数据主权企业的候选方案。在实时协作技术层面，CRDT 与 WebRTC 的组合为浏览器端文档编辑提供了低延迟、去中心化的技术路径，但需根据实际场景权衡架构复杂度与运维成本。

参考来源

• Euro-Office GitHub 组织主页与 DocumentServer 仓库
• CRDT 协作编辑技术调研（YouTube 技术演讲与开源项目实践）

web