基于微服务架构的在线协同编辑系统：OT算法与WebSocket实战

简介：这份资源是面向计算机专业毕业生与全栈开发学习者的微服务在线协同编辑系统完整源码，可作为毕业设计、课程设计或微服务入门实战的参考方案。项目采用微服务架构，前端基于 Vue 与 TypeScript 构建交互界面，后端以 Java 实现核心业务逻辑，并配套 Dockerfile、yml 与 conf 等部署配置，便于理解服务拆分、接口协作与容器化部署的整体思路。压缩包共 253 个文件，涵盖 82 个 Java 源文件、32 个 Vue 组件、22 个 TypeScript 与 17 个 JavaScript 脚本，另有 xml、json、sql 及图片样式资源，整体约 2.9MB，目录结构清晰，按模块划分便于检索。源码经过本地编译验证，按文档配置环境后即可运行，难度适中，适合需要完整项目案例、排错思路与工程结构参考的读者。目前已有 195 人学习关注。

1. 微服务架构下的在线协同编辑系统：一个毕设项目为什么值得认真做

如果你正在找一份能撑起毕设答辩、又能写进简历的完整项目，基于微服务架构的在线协同编辑系统源码是一个被低估的方向。它不像电商秒杀那样烂大街，也不像纯 CRUD 管理系统那样一眼看穿技术含量。协同编辑背后涉及实时通信、操作冲突消解、服务拆分与数据一致性，这几个点随便拎一个出来都能在答辩时讲十分钟。我见过太多毕设项目把"微服务"三个字贴在单体应用上，拆了两三个模块就敢叫微服务架构，答辩老师一问服务间怎么通信、数据怎么同步就露馅。这个标题里的在线协同编辑系统，核心难点在于多人同时编辑同一份文档时，如何保证每个人的操作不丢失、不乱序、不覆盖。适合有一定 Java 或 Python 基础、想通过一个完整项目把微服务架构和实时协同两个方向串起来的同学。接下来我会从架构拆分、协同算法选型、源码落地步骤到踩坑排查，把这条路走通。

2. 微服务拆分与协同编辑的技术选型：为什么不能只拆三个服务

2.1 协同编辑系统的服务边界怎么划

很多人拿到这个题目第一反应是拆成用户服务、文档服务、编辑服务三个模块就完事。这种拆法在答辩时会被追问：编辑服务挂了，用户的编辑操作丢不丢？文档服务的数据和编辑服务的操作日志怎么对齐？我一般会按职责边界拆成五个服务：用户认证服务、文档管理服务、协同编辑服务、操作日志服务、通知服务。用户认证服务负责登录注册和 token 签发，文档管理服务负责文档的增删改查和权限控制，协同编辑服务是核心，负责接收编辑操作、做冲突消解、广播给其他在线用户，操作日志服务负责持久化每一次编辑操作用于回溯和版本恢复，通知服务负责在线状态和消息推送。

这样拆的好处是每个服务的职责单一，协同编辑服务可以独立扩容，操作日志服务可以用顺序写入优化性能。坏处是服务间通信变多，需要引入消息队列来解耦。常见做法是用 WebSocket 维持客户端和协同编辑服务的长连接，编辑操作通过消息队列异步写入操作日志服务，文档管理服务通过 RPC 调用协同编辑服务获取最新文档状态。

服务拆分的粒度没有标准答案，但有一条原则：如果两个模块的数据一致性要求极高、事务边界重叠，就不要拆开。协同编辑服务和操作日志服务之间就是这种关系，所以操作日志的写入要用最终一致性方案，不能强求实时同步。

2.2 协同算法选型：OT 还是 CRDT

这是整个项目最核心的技术决策。OT（Operational Transformation）和 CRDT（Conflict-free Replicated Data Type）是两种主流方案。OT 的思路是每个编辑操作在应用到本地之前，先根据并发操作做变换，保证最终一致。CRDT 的思路是设计一种数据结构，使得任意顺序应用操作都能得到相同结果。

OT 的优点是成熟、有大量开源实现参考，缺点是变换函数的正确性很难保证，尤其是多用户多操作并发时，变换矩阵会变得极其复杂。CRDT 的优点是天然支持分布式、不需要中心服务器做变换，缺点是数据结构复杂、内存占用高、实现门槛不低。

对于毕设项目，我建议选 OT。原因很实际：OT 有成熟的参考实现可以对照，调试时能一步步跟踪变换过程，答辩时也容易讲清楚。CRDT 虽然理论上更优雅，但自己从零实现一个正确的 CRDT 数据结构，工作量远超毕设周期。

选 OT 之后，具体用哪种变换策略？常见的有 OT 的 Jupiter 模型和 COT 模型。Jupiter 模型是中心化的，所有操作经过服务器排序后再广播，实现简单，适合毕设。COT 模型是去中心化的，适合 P2P 场景，但实现复杂度高。我一般会选 Jupiter 模型，服务器作为唯一的操作排序中心，客户端只负责发送操作和接收变换后的操作。

2.3 技术栈组合与版本选择

后端用 Spring Boot + Spring Cloud 做微服务基础框架，服务注册和发现用 Nacos，消息队列用 RabbitMQ 或 RocketMQ，缓存用 Redis 存在线用户状态和文档锁，数据库用 MySQL 存文档元数据和操作日志。实时通信层用 Netty 或 Spring WebSocket，如果团队 Java 基础一般，直接用 Spring WebSocket 更快出活。

前端用 Vue 或 React 都行，编辑器组件选 Quill 或 ProseMirror。Quill 的 API 更友好，文档全，适合快速集成。ProseMirror 更灵活但学习曲线陡。毕设项目建议用 Quill，把精力放在协同逻辑上而不是编辑器本身的定制上。

这里有一个容易翻车的点：Spring Cloud 的版本和 Spring Boot 版本必须严格对应。比如 Spring Cloud 2022.0.x 对应 Spring Boot 3.0.x，Spring Cloud 2021.0.x 对应 Spring Boot 2.6.x。版本不匹配会在启动时直接报错，而且报错信息往往指向不相关的类，排查起来很痛苦。我一般会在 pom.xml 里用 dependencyManagement 统一管理版本，避免子模块各自引入不同版本。

3. 从零跑通协同编辑核心链路：操作变换与 WebSocket 广播

3.1 操作定义与变换函数实现

协同编辑的核心是定义操作的数据结构和变换函数。一个编辑操作至少包含：操作类型（插入或删除）、位置索引、内容、客户端 ID、版本号。下面是一个简化的 Python 实现，用来演示 OT 变换的核心逻辑。

class Operation: def __init__(self, op_type, position, content, client_id, version): self.op_type = op_type # 'insert' or 'delete' self.position = position self.content = content self.client_id = client_id self.version = version def transform(op_a, op_b): """ 将 op_a 针对 op_b 做变换，返回变换后的 op_a 假设 op_b 已经先于 op_a 应用 """ if op_a.op_type == 'insert' and op_b.op_type == 'insert': if op_b.position < op_a.position: op_a.position += len(op_b.content) elif op_b.position == op_a.position: # 位置相同，按 client_id 排序保证一致性 if op_b.client_id < op_a.client_id: op_a.position += len(op_b.content) elif op_a.op_type == 'insert' and op_b.op_type == 'delete': if op_b.position < op_a.position: op_a.position -= len(op_b.content) elif op_a.op_type == 'delete' and op_b.op_type == 'insert': if op_b.position <= op_a.position: op_a.position += len(op_b.content) elif op_a.op_type == 'delete' and op_b.op_type == 'delete': if op_b.position < op_a.position: op_a.position -= len(op_b.content) return op_a

这段代码的逻辑是：当两个操作并发时，根据操作类型和位置关系调整 op_a 的位置索引。插入操作遇到插入操作时，如果位置相同，用 client_id 做确定性排序，保证所有客户端变换结果一致。删除操作遇到插入操作时，如果插入位置在删除位置之前，删除位置要后移。参数说明：position 是字符索引，content 是插入的文本或删除的文本长度，client_id 是客户端唯一标识，version 是操作基于的文档版本号。

实际项目中变换函数会比这复杂得多，需要处理操作嵌套、批量操作、撤销重做等场景。但毕设项目把基础变换逻辑跑通，再在此基础上扩展，就足够撑起技术深度了。

3.2 WebSocket 服务端与客户端的最小实现

服务端用 Spring WebSocket 接收编辑操作，做变换后广播给同一文档的其他在线用户。下面是一个简化的服务端处理逻辑。

@ServerEndpoint("/ws/editor/{docId}/{clientId}") public class EditorEndpoint { private static Map<String, Set<Session>> docSessions = new ConcurrentHashMap<>(); private static Map<String, List<Operation>> docHistory = new ConcurrentHashMap<>(); @OnOpen public void onOpen(Session session, @PathParam("docId") String docId, @PathParam("clientId") String clientId) { docSessions.computeIfAbsent(docId, k -> ConcurrentHashMap.newKeySet()).add(session); // 发送当前文档历史操作，让新客户端追平状态 List<Operation> history = docHistory.getOrDefault(docId, new ArrayList<>()); session.getAsyncRemote().sendText(JSON.toJSONString(history)); } @OnMessage public void onMessage(String message, @PathParam("docId") String docId, @PathParam("clientId") String clientId) { Operation incoming = JSON.parseObject(message, Operation.class); List<Operation> history = docHistory.computeIfAbsent(docId, k -> new ArrayList<>()); // 对历史操作做变换 Operation transformed = incoming; for (Operation op : history) { if (op.clientId.equals(clientId)) continue; transformed = transform(transformed, op); } history.add(transformed); // 广播给所有客户端 String broadcast = JSON.toJSONString(transformed); for (Session s : docSessions.getOrDefault(docId, Collections.emptySet())) { s.getAsyncRemote().sendText(broadcast); } } }

这段代码的关键点是：新客户端加入时先拉取历史操作追平状态，收到编辑操作后对历史操作做变换，变换后的操作加入历史并广播。参数说明：docId 是文档唯一标识，clientId 是客户端标识，history 是该文档的所有操作序列。注意这里用 ConcurrentHashMap 保证并发安全，实际项目中还需要加锁或使用消息队列来保证操作顺序。

客户端收到广播后，需要判断这个操作是否是自己发出的。如果是自己发出的，跳过；如果不是，对本地待发送的操作做变换后再应用。这个逻辑在客户端 SDK 里实现，前端只需要调用 applyOperation 方法更新编辑器内容。

3.3 服务间通信与操作日志持久化

协同编辑服务处理完操作后，需要异步写入操作日志服务。用 RabbitMQ 做解耦，协同编辑服务作为生产者发送操作消息，操作日志服务作为消费者批量写入数据库。

# application.yml 中 RabbitMQ 配置 spring: rabbitmq: host: localhost port: 5672 username: guest password: guest publisher-confirm-type: correlated publisher-returns: true listener: simple: acknowledge-mode: manual prefetch: 50

配置说明：publisher-confirm-type 设为 correlated 开启发布确认，确保消息到达 Broker；acknowledge-mode 设为 manual 手动确认，防止消息丢失；prefetch 设为 50 控制每次拉取的消息数量，避免消费者过载。操作日志服务消费消息后批量插入 MySQL，用 INSERT INTO operation_log (doc_id, client_id, op_type, position, content, version, create_time) VALUES (...) 批量写入，每 100 条或每 500 毫秒刷一次盘。

这里有一个血泪经验：操作日志表一定要建联合索引 (doc_id, version)，否则文档操作多了之后查询历史操作会全表扫描，接口响应时间从毫秒级涨到秒级。我见过一个项目因为没建这个索引，文档编辑到几千次操作后，新用户加入时拉取历史操作直接超时。

4. 避坑与排查：协同编辑系统最容易翻车的五个地方

4.1 操作乱序导致文档内容错乱

现象：多个用户同时编辑时，偶尔出现某段文字重复或丢失，刷新后恢复正常。原因：WebSocket 消息到达顺序和发送顺序不一致，服务端没有做全局排序。解决：在协同编辑服务中引入版本号机制，每个操作必须携带基于的文档版本号，服务端按版本号排序后再做变换。如果收到的操作版本号小于当前版本，说明是延迟消息，需要重新变换后再应用。

4.2 服务注册失败导致 RPC 调用超时

现象：启动时 Nacos 注册成功，但运行一段时间后服务列表为空，RPC 调用报 No provider available。原因：服务实例的心跳续约失败，常见于服务器时间不同步或网络抖动。解决：检查服务器 NTP 时间同步，在 Nacos 配置中适当调大心跳超时时间，同时在 RPC 调用端配置重试和熔断策略。我一般会在 Sentinel 或 Resilience4j 里配置失败重试三次、熔断时间窗口 10 秒。

4.3 编辑器光标位置在远程操作后跳变

现象：用户 A 正在输入时，用户 B 的编辑操作同步过来，A 的光标位置突然跳到文档开头或末尾。原因：远程操作应用后没有重新计算本地光标位置。解决：在应用远程操作前记录光标位置，应用后根据操作类型和位置偏移量重新计算光标位置。Quill 编辑器可以用 quill.setSelection(index, length) 恢复光标，ProseMirror 需要用其 Transaction 机制处理。

4.4 操作日志表数据量膨胀导致查询变慢

现象：项目运行几周后，操作日志表达到千万行级别，查询历史操作越来越慢。原因：没有做冷热数据分离，所有操作日志都存在一张表里。解决：按时间分表，最近 7 天的操作存热表，超过 7 天的归档到冷表。查询时先查热表，查不到再查冷表。另一个方案是用 Redis 缓存最近的操作序列，只把超过一定数量的旧操作持久化到 MySQL。

4.5 微服务间循环依赖导致启动失败

现象：项目启动时报 BeanCurrentlyInCreationException 或循环依赖错误。原因：文档管理服务调用了协同编辑服务，协同编辑服务又回调了文档管理服务。解决：引入事件驱动架构，用消息队列解耦。文档管理服务发布文档创建事件，协同编辑服务订阅事件后初始化文档状态，避免直接 RPC 调用。如果必须同步调用，把公共逻辑抽到第三个服务或公共模块中。

5. 进阶技巧：用操作日志做版本回滚与协同性能验证

5.1 基于操作日志的版本回滚实现

操作日志不只是用来追溯，还可以用来做版本回滚。思路是：每个操作都有版本号，回滚到某个版本时，从操作日志中查出该版本之后的所有操作，生成反向操作依次应用。反向操作的生成规则：插入操作的反向是删除，删除操作的反向是插入，位置和内容从原操作中提取。

def generate_reverse_operations(operations, target_version): """ 生成从当前版本回滚到 target_version 的反向操作序列 """ reverse_ops = [] for op in reversed(operations): if op.version <= target_version: break if op.op_type == 'insert': reverse_ops.append(Operation('delete', op.position, op.content, op.client_id, op.version)) elif op.op_type == 'delete': reverse_ops.append(Operation('insert', op.position, op.content, op.client_id, op.version)) return reverse_ops

这段代码的逻辑是倒序遍历操作日志，遇到版本号小于等于目标版本的操作就停止，对每个操作生成反向操作。参数说明：operations 是按版本号排序的操作列表，target_version 是回滚目标版本。实际使用时，反向操作生成后需要依次应用并广播给所有在线客户端，同时更新文档版本号。

这个功能在答辩时是一个很好的加分项，因为它展示了操作日志的完整价值闭环：记录、追溯、回滚。而且实现难度不高，在已有操作日志基础上加一个接口就能跑通。

5.2 协同性能的验证方法与关键指标

做完功能之后，怎么验证协同性能？我一般会从三个维度测：并发用户数、操作延迟、操作丢失率。并发用户数用 JMeter 或 Locust 模拟，每个虚拟用户建立 WebSocket 连接并随机发送编辑操作。操作延迟从客户端发送操作到收到广播的时间差计算，P99 延迟控制在 200 毫秒以内算合格。操作丢失率通过对比客户端发送的操作总数和服务端记录的操作总数来计算，正常情况应该为 0。

测试时注意一点：并发用户数不是越高越好，要结合服务器配置看。单台 4 核 8G 的服务器，协同编辑服务跑 50 个并发 WebSocket 连接是合理的，超过这个数需要加实例做水平扩展。水平扩展时要注意 WebSocket 的会话粘性问题，用 Nginx 的 ip_hash 或 Redis 做会话共享。

5.3 一个容易被忽略的细节：客户端重连后的状态同步

WebSocket 断线重连是必现场景，但很多毕设项目只做了重连，没做重连后的状态同步。客户端重连后，本地文档内容可能已经落后于服务端，需要先拉取断线期间的操作日志，应用后再继续编辑。实现方式是在客户端维护一个 lastVersion 字段，重连时带上这个版本号，服务端返回该版本之后的所有操作。

// 客户端重连逻辑 function reconnect() { const ws = new WebSocket(`/ws/editor/${docId}/${clientId}?lastVersion=${lastVersion}`); ws.onmessage = (event) => { const data = JSON.parse(event.data); if (data.type === 'history') { // 应用断线期间的操作 data.operations.forEach(op => applyOperation(op)); lastVersion = data.currentVersion; } else { applyOperation(data); lastVersion = data.version; } }; }

这段代码的关键是重连时带上 lastVersion 参数，服务端根据这个参数返回缺失的操作。参数说明：lastVersion 是客户端最后应用的版本号，服务端返回该版本之后的所有操作和当前版本号。这个细节在答辩时如果被问到断线重连怎么处理，能答上来就是加分项。

我自己做这类项目最大的教训是：不要一上来就追求功能大而全，先把协同编辑的核心链路跑通，两个人能同时编辑一份文档且内容不乱，再往上加用户认证、权限控制、版本回滚。核心链路跑通了，后面都是锦上添花；核心链路有问题，功能再多也撑不住答辩时的追问。希望帮到你。

本文还有配套的精品资源，点击获取