实时协作设计工具的核心难题，是让多个用户在同一个画布上操作时，彼此的修改能快速、准确地同步。Figma之所以流畅，靠的不是简单地广播消息，而是一套精心设计的架构：前端通过WebSocket与服务端保持长连接，所有编辑操作先发到服务器，由服务器基于OT算法做合并与排序，再分发给所有在线客户端。想在云服务器上自己搭一套类似的服务，光写业务代码不够，服务器层面的配置往往才是决定稳定性上限的关键。
一、为什么实时协作必须用WebSocket而不是HTTP轮询
HTTP是请求-响应模型，客户端不主动问，服务器就没法推数据。早期一些在线白板工具用轮询实现同步，也就是每隔一两秒向服务器问一次"有没有新操作"。这种做法在小规模场景勉强能用，一旦并发用户上来，问题立刻暴露：延迟高、请求量大、服务器空转严重。
WebSocket则不同。它在握手阶段借助HTTP升级协议，之后客户端与服务器之间建立一条全双工的长连接，任何一方都可以随时推送数据。对于设计协作这种"操作密集、消息碎片化"的场景，WebSocket的优势非常明显：一个拖拽动作可能被拆成几十个微小的位置更新事件，长连接可以让这些事件毫秒级到达其他人的屏幕上。
还有一个容易被忽略的点：WebSocket的帧头开销极小，通常只有2到14字节，而HTTP每次请求都要携带完整的头部信息，动辄几百字节。对于高频小消息，这个差距在带宽和解析成本上都会被成倍放大。
二、云服务器上的WebSocket服务配置
假设你在云服务器上跑一个Node.js服务（比如用ws或Socket.IO库），直接监听某个端口虽然能跑通，但生产环境强烈建议前面挂一层Nginx做反向代理。Nginx配置中有几个参数必须注意，否则连接会莫名其妙断掉。
首先是升级头的透传。Nginx默认不认识WebSocket的Upgrade请求，必须在proxy配置里显式设置：
proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade";
其次是超时时间。Nginx默认的proxy_read_timeout是60秒，如果这段时间内没有任何数据传输，连接就会被掐断。协作编辑虽然消息频繁，但用户停下来思考的时间可能超过60秒。建议把proxy_read_timeout和proxy_send_timeout都调到300秒以上，同时在应用层实现心跳机制（比如每25秒发一次ping帧），双保险保活。
端口规划上，建议WebSocket服务只监听内网或本机端口（如127.0.0.1:3001），由Nginx统一对外暴露443端口并配置SSL证书。这样既能复用HTTPS证书，也避免了云厂商安全组开放一堆杂乱端口。
三、OT算法的核心逻辑与服务器端实现要点
OT全称Operational Transformation，即操作变换。它的核心思想是：客户端不直接同步文档内容，而是同步"操作"。当两个用户同时编辑，操作到达服务器的顺序可能和产生顺序不一致，OT算法通过变换函数调整这些操作，使它们无论按什么顺序应用，最终结果都一致。
举个例子，用户A在第10个位置插入了一个字符，用户B同时在第20个位置删除了一段文字。如果B的操作先被服务器接受，那么A的插入位置就需要前移或后移。这个"移动"的计算就是OT的核心。对于设计类应用，操作类型会更丰富：位置移动、缩放、旋转、图层顺序调整、文本编辑等，每种操作组合都要定义对应的变换规则。
p在服务器端实现OT，通常需要维护三个关键结构：- 操作队列：每个文档对应一个按序号排列的操作日志，客户端提交操作时必须携带本地的版本号，服务器据此判断该操作基于哪个历史状态。
- 版本向量或单调递增的revision号：服务器每接受一个操作就递增revision，客户端收到确认后同步前进。版本落后太多的客户端，需要先拉取差异操作再提交，否则无法正确变换。
- 周期性快照：操作日志无限增长会拖慢新用户加入时的初始化速度，一般每隔几百或几千个操作生成一次文档快照，快照之后的日志才需要回放。
对于设计文档这种包含大量矢量数据的内容，还有个实用技巧：把画布结构（JSON树）和二进制资源（位图、字体）分开存储。OT只处理结构化的操作，资源用内容寻址（哈希值做key）的方式存对象存储，能大幅降低消息体积和合并复杂度。
四、性能调优与容量规划
一台普通配置的云主机（比如4核8G）能承载多少并发协作连接？经验上，如果单个连接的平均消息频率在每秒10条以内，Node.js单进程撑5000到10000个连接问题不大。但要留意两个瓶颈：一是内存，每个WebSocket连接本身占用不大，但每个活跃文档的操作缓冲、快照缓存会吃内存，建议按"每文档预留1到2MB"估算；二是CPU，OT变换是纯计算，复杂场景下高频率编辑会打满单核，可以考虑按文档ID做一致性哈希分片，把不同文档路由到不同进程或不同机器。
系统层面也要调整文件描述符上限。Linux默认的open files限制通常是1024，对长连接服务远远不够。修改/etc/security/limits.conf或systemd的LimitNOFILE参数，把上限提到65535以上。同时检查内核参数net.core.somaxconn和 Tcp 相关的端口回收配置，避免高并发下出现连接异常。
五、常见踩坑与应对
第一个坑是断线重连后的状态恢复。客户端重连时必须带上自己最后的revision号，服务器把缺失的操作批量补发。如果revision差距太大超过快照点，直接下发最新快照加上后续日志，不要傻乎乎地全量回放。
第二个坑是Nginx缓冲。有些配置默认开启了proxy_buffering，会导致小消息被攒着不转发，协作画面出现卡顿。对WebSocket的location明确设置proxy_buffering off可以解决。
第三个坑是多实例部署时的粘性会话。如果负载均衡层用了多台后端，同一个文档的连接必须路由到同一台机器（按文档ID做哈希），否则操作日志分裂，数据一致性就彻底乱套了。
总的来说，在云服务器上搭建Figma式的协作服务，架构上抓住两点就够了：传输层用WebSocket配好代理和保活，数据层用OT保证操作收敛。剩下的工作主要是稳定性打磨——监控连接数、消息延迟、操作队列长度这三项指标，问题基本都能在用户感知之前被发现。