Excalidraw镜像内置负载均衡，支持高并发访问-深圳市維司達科技有限公司

Excalidraw镜像内置负载均衡，支持高并发访问

在现代远程协作场景中，一个看似简单的白板工具，往往成为团队沟通效率的“咽喉要道”。当十几个人同时在一个 Excalidraw 页面上画流程图、拖动元素、实时评论时，背后的系统压力远比表面看起来复杂得多。尤其是随着 AI 生成功能的引入——用户只需输入“画一个微服务架构图”，系统便自动生成拓扑结构——这种高频交互进一步加剧了服务端的负载。

传统的单实例部署模式很快就会暴露短板：WebSocket 连接数飙升、响应延迟增加、偶尔断连重连……更糟糕的是，一旦主节点宕机，整个协作空间瞬间冻结。这不仅影响体验，甚至可能打断一场关键的产品评审会。

为应对这一挑战，Excalidraw 的容器化部署方案开始走向一种新范式：将负载均衡能力直接内嵌到镜像中。不再是“先配 Nginx，再起多个后端”的手动拼装模式，而是通过一个“自包含”的镜像单元，自动完成请求分发、健康检查和会话路由。这种方式尤其适合中小团队快速搭建高可用服务，也为企业级私有化部署提供了轻量而灵活的选择。

内置负载均衡的设计哲学

传统架构下，我们习惯于把负载均衡器当作独立组件来部署——比如用 Nginx 做反向代理，前端挂 ELB 或 Ingress，后面接一堆应用实例。这种分层清晰，但对运维要求较高，尤其是在没有 Kubernetes 或云平台支持的环境中，配置 SSL、健康检查、会话保持等环节容易出错。

而“内置负载均衡”则换了一种思路：让每个容器既是服务提供者，也是流量调度者。准确地说，这个角色通常由容器内的 Sidecar 进程或集成式反向代理承担。它启动时不仅能跑 Excalidraw 主服务，还能主动发现其他实例、探测健康状态，并对外统一接收请求进行智能转发。

这听起来像是把“胖客户端”理念搬到了服务端——没错，正是如此。这种“胖容器”（Fat Container）设计虽然牺牲了一点资源隔离性，却极大降低了部署复杂度。你不需要额外维护一套 LB 配置，也不必担心网络策略冲突，一条docker-compose up就能拉起一个具备基本容灾能力的服务集群。

它是怎么工作的？

整个流程可以拆解为几个关键阶段：

初始化加载：容器启动后，优先运行一个轻量级反向代理（如 Caddy、Traefik 或基于 Go 编写的定制路由模块），监听 80/443 端口。
后端发现：通过环境变量、DNS 解析或多播机制获取当前可用的 Excalidraw 实例列表。例如：
bash BACKEND_NODES=excalidraw-node-1:3000,excalidraw-node-2:3000,localhost:3000
健康探活：定期调用各节点的/health接口，失败超过阈值则从可用列表剔除，避免将流量导向异常实例。
请求接入与分发：外部请求到达后，根据策略选择目标节点。常见的有：
- 轮询（Round Robin）
- 最少连接（Least Connections）
- IP Hash（用于会话保持）
会话一致性处理：对于需要维持上下文的操作（如多人协作编辑），可通过 Cookie 中的session_id哈希绑定到固定后端，确保不会因切换实例导致状态丢失。

整个过程完全封装在镜像内部，无需依赖外部 LB 设备。即使是在边缘计算或离线环境中，也能实现基本的横向扩展能力。

⚠️ 实践中的注意事项：
- 健康检查间隔不宜过短（建议 ≥5s），否则可能误判瞬时抖动为故障；
- 若使用多播发现机制，在高密度部署环境下需防范广播风暴；
- 启用 sticky session 时，必须配合共享存储（如 Redis），否则仍可能出现数据不一致。

协作服务的核心机制：不只是 WebSocket 转发

很多人以为，只要把 WebSocket 请求均匀分发出去就能解决并发问题。但实际上，Excalidraw 的协作功能远不止“消息广播”这么简单。

它的核心在于多端状态同步。当 A 用户移动了一个矩形，B 和 C 用户不仅要立刻看到变化，还要保证撤销栈、光标位置、图层顺序等上下文完全一致。这就引出了两个关键技术点：通信协议和冲突解决模型。

WebSocket 是基础，但不是全部

Excalidraw 使用标准 WebSocket 协议建立全双工通道，路径通常是/collab?room=xxx&token=yyy。连接建立后，服务端会验证 JWT token 权限，并将用户加入指定房间。之后的所有操作都以 JSON 格式的增量包形式传输，带宽消耗极低。

// 客户端发送更新 socket.send(JSON.stringify({ type: 'element-update', payload: { id: 'rect-1', x: 100, y: 200 } }));

服务端收到后，并非简单地原样转发，而是经过校验、去重、合并后再广播给其他成员。更重要的是，它必须处理并发写入带来的冲突。

如何避免“两个人同时改同一个框”？

这是协同编辑领域的经典难题。Excalidraw 目前主要采用两种技术路线：

OT（Operational Transformation）：早期版本使用，通过对操作进行变换来达成一致。例如，A 删除第3个字符，B 插入新字符，系统会自动调整偏移量，使最终结果相同。
CRDT（Conflict-Free Replicated Data Type）：较新的方向，数据结构本身具备最终一致性能力，天然支持离线编辑和无中心同步。

无论哪种方式，都需要所有参与节点拥有相同的上下文视图。如果负载均衡器随意切换后端，用户第一次连到 Node A，第二次连到 Node B，那之前的编辑历史就断了。

因此，在分布式部署中，有两种解法：

启用 Sticky Session：通过 IP Hash 或 Cookie 绑定，确保同一用户的请求始终落在初始节点；
共享状态中心化：将房间状态、操作日志存入 Redis 或数据库，任何节点都能恢复上下文。

后者显然更健壮，但也带来额外延迟。实践中，多数部署会选择“Sticky + Redis”组合：既减少跨节点同步开销，又保留一定的容错迁移能力。

工程实现：从配置到运行时

下面是一个典型的docker-compose.yml示例，展示了如何部署一个具备内置负载均衡能力的 Excalidraw 集群：

version: '3.8' services: excalidraw-lb: image: excalidraw/excalidraw:latest-with-lb ports: - "80:80" environment: - LOAD_BALANCE_STRATEGY=least_conn - BACKEND_NODES=excalidraw-node-1:3000,excalidraw-node-2:3000,localhost:3000 - HEALTH_CHECK_PATH=/health - HEALTH_CHECK_INTERVAL=10s - SESSION_STICKY=true depends_on: - excalidraw-node-1 - excalidraw-node-2 excalidraw-node-1: image: excalidraw/excalidraw:latest command: ["--port", "3000"] excalidraw-node-2: image: excalidraw/excalidraw:latest command: ["--port", "3000"]

在这个配置中，excalidraw-lb是增强版镜像，内部集成了一个基于 Go 的轻量路由引擎。它读取BACKEND_NODES列表，按“最少连接”策略分发请求，每 10 秒探测一次健康状态。开启SESSION_STICKY后，系统会解析 Cookie 中的session_id并哈希映射到固定后端。

值得注意的是，localhost:3000被显式列入后端列表——这意味着当前容器自身也作为一个服务实例运行。这是一种典型的“主+代理”共存模式，充分利用了单机资源。

对应的 Node.js 协作服务简化代码如下：

const WebSocket = require('ws'); const http = require('http'); const { applyOTOperation } = require('./ot-engine'); const wss = new WebSocket.Server({ noServer: true }); const rooms = new Map(); // roomID -> Set<clients> wss.on('connection', (ws, req) => { const url = new URL(req.url, 'http://localhost'); const roomId = url.searchParams.get('room'); const userId = url.searchParams.get('user'); if (!roomId || !userId) { ws.close(4001, 'Missing parameters'); return; } const client = { ws, userId }; const room = rooms.get(roomId) || new Set(); room.add(client); rooms.set(roomId, room); console.log(`User ${userId} joined room ${roomId}`); ws.on('message', (data) => { try { const message = JSON.parse(data); room.forEach((c) => { if (c.ws !== ws && c.userId !== userId) { c.ws.send(JSON.stringify({ type: 'update', payload: message.payload, from: userId })); } }); } catch (err) { console.error('Parse error:', err); } }); ws.on('close', () => { room.delete(client); if (room.size === 0) rooms.delete(roomId); console.log(`User ${userId} left room ${roomId}`); }); }); const server = http.createServer(app); server.on('upgrade', (req, socket, head) => { if (req.url.startsWith('/collab')) { wss.handleUpgrade(req, socket, head, (ws) => { wss.emit('connection', ws, req); }); } else { socket.destroy(); } });

这段代码虽简，但已涵盖核心逻辑：连接管理、房间划分、消息广播。真实生产环境中，还需接入 Redis Pub/Sub 实现跨实例事件同步，避免某个节点无法感知其他房间的变化。

典型部署架构与实战考量

一个高并发 Excalidraw 系统的完整架构通常如下所示：

[Client Browser] ↓ HTTPS/WSS [Nginx / CDN] ← 可选边缘缓存 ↓ [Excalidraw-LB Container] ← 内置负载均衡镜像（入口） ├──→ [Excalidraw Instance A] ← 本地主进程 ├──→ [Excalidraw Instance B] ← 同机或远程实例 └──→ [Excalidraw Instance C] ↓ [Redis] ← 共享会话 & 房间状态 [PostgreSQL] ← 图纸持久化存储

其中，Excalidraw-LB容器扮演多重角色：它是流量入口、反向代理、本地服务提供者，甚至是健康检查的发起方。静态资源（JS/CSS/WASM）可由其直接返回，动态请求（如/collab）则根据策略转发。

在这种架构下，常见痛点得以有效缓解：

问题	解决方案
单实例连接数瓶颈	横向扩展 + 内置 LB 分流，支持数千并发连接
多人协作卡顿	使用 Redis Pub/Sub 替代直接广播，降低单节点压力
故障恢复慢	自动检测并剔除异常节点，分钟级切换
部署复杂	一体化镜像设计，一条命令即可启动

当然，这也带来一些新的权衡：