Excalidraw镜像支持多实例并发，适合大规模应用

Excalidraw镜像支持多实例并发，适合大规模应用

在远程办公成为常态的今天，一个小小的白板，可能正决定着一场产品评审会的效率、一次技术方案讨论的成败。传统的绘图工具虽然精准，但冷冰冰的线条难以激发灵感；而手绘风格的虚拟白板——比如Excalidraw——却以“潦草感”还原了真实会议室里的创意氛围，迅速俘获了开发者的心。

可当团队从几个人扩展到上百人，甚至跨地域协作时，问题来了：单台服务器扛不住高并发连接，用户一多就卡顿、掉线；某个节点宕机，整个房间瞬间崩溃；全球用户访问同一个中心节点，延迟动辄几百毫秒……这些都不是“体验优化”的范畴，而是架构层面的根本挑战。

于是，Excalidraw 的镜像化部署与多实例并发能力，不再是一个“高级选项”，而成了支撑企业级协作的必要条件。它让这个原本轻量的开源项目，具备了承载数千人实时协同的潜力。

我们不妨设想这样一个场景：某大型科技公司正在举行跨大区的产品架构评审会，北京、柏林、旧金山三地的研发团队同时接入同一个 Excalidraw 白板。有人在画微服务拓扑，有人拖拽组件框，还有人在添加注释箭头。尽管他们连接的是不同物理位置的服务实例，但每个人看到的画面始终同步、流畅，没有任何割裂感。

这背后，正是容器化 + 多实例 + 消息中间件协同工作的结果。

首先，Excalidraw 被打包成一个标准化的 Docker 镜像。这个镜像不只是前端代码，还包括运行所需的 Nginx 服务、WebSocket 支持模块和预设配置。你可以把它理解为一个“即插即用”的协作单元。构建完成后，推送到私有镜像仓库（如 Harbor），随时供 Kubernetes 集群拉取启动。

FROM node:18-alpine AS builder WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build FROM nginx:alpine COPY --from=builder /app/dist /usr/share/nginx/html COPY nginx.conf /etc/nginx/conf.d/default.conf EXPOSE 80 CMD ["nginx", "-g", "daemon off;"]

这段Dockerfile看似简单，却是整个系统弹性的起点。多阶段构建确保最终镜像小巧高效，仅包含静态资源和服务层，避免冗余依赖。更重要的是，每一次发布都对应唯一的镜像标签，回滚、灰度、版本追踪变得轻而易举。

接下来，Kubernetes 接手调度工作。通过 Deployment 定义，我们可以声明需要运行 5 个、50 个甚至更多副本：

apiVersion: apps/v1 kind: Deployment metadata: name: excalidraw-deployment spec: replicas: 5 selector: matchLabels: app: excalidraw template: metadata: labels: app: excalidraw spec: containers: - name: excalidraw image: your-registry/excalidraw:latest ports: - containerPort: 80 resources: limits: cpu: "500m" memory: "256Mi" --- apiVersion: v1 kind: Service metadata: name: excalidraw-service spec: selector: app: excalidraw ports: - protocol: TCP port: 80 targetPort: 80 type: LoadBalancer

这里的关键在于replicas: 5和LoadBalancer服务类型。前者意味着五个完全对等的无状态实例并行运行；后者则通过云厂商的负载均衡器对外暴露统一入口。用户的请求被自动分发到当前负载最低的节点上，实现真正的横向扩展。

但问题也随之而来：如果每个实例彼此独立，那 A 用户在实例1上的操作，B 用户在实例2上岂不是看不到？

这就引出了整个架构中最关键的一环——跨实例状态同步机制。

原始的 Excalidraw 是基于客户端直连 WebSocket 的点对点通信模型，适用于小规模本地部署。但在分布式环境下，必须引入一个中心化的消息枢纽。常见的做法是使用 Redis 的 Pub/Sub 功能作为广播通道：

const redis = require('redis'); const publisher = redis.createClient({ url: 'redis://redis-master:6379' }); const subscriber = redis.createClient({ url: 'redis://redis-master:6379' }); wss.on('connection', (ws) => { ws.on('message', (data) => { const { roomId, update } = JSON.parse(data); publisher.publish(`room:${roomId}`, JSON.stringify(update)); }); }); subscriber.subscribe('room:*'); subscriber.on('message', (channel, message) => { const roomId = channel.split(':')[1]; wss.clients.forEach((client) => { if (client.roomId === roomId) { client.send(message); } }); });

这段代码虽短，却完成了核心使命：将本地事件转化为全局通知。无论用户连接的是哪个实例，只要修改发生在同一个roomId，变更就会通过 Redis 广播至所有订阅者，并由各自实例推送给本地客户端。这样一来，即便物理上分散，逻辑上仍如同一台机器在运作。

当然，光有消息传递还不够。为了保证协作不乱套，还需要考虑几个工程细节：

• 消息顺序与冲突处理：网络传输无法保证绝对有序。因此每条更新应携带时间戳或递增 ID，接收端按序排列。对于并发编辑冲突，可采用 OT（Operational Transformation）算法进行合并，或者更现代的 CRDT 结构来实现最终一致性。
• 持久化保障：Redis 只负责临时广播，真正的画布状态需定期落盘。PostgreSQL 存储结构化元数据（如房间信息、权限设置），对象存储（如 S3 或 MinIO）保存完整快照，防止意外丢失。
• 无状态设计原则：每个 Excalidraw 实例都不应保存任何会话状态。这样在扩缩容或故障重启时，才能做到无缝切换。客户端重连后，通过房间 ID 重新订阅即可恢复上下文。

再来看整体架构全景：

+------------------+ | DNS / CDN | +--------+---------+ | +--------v---------+ | Load Balancer | | (NGINX / ALB) | +--------+---------+ | +------------------------+-------------------------+ | | | +---------v----------+ +---------v----------+ +----------v----------+ | Excalidraw | | Excalidraw | | Excalidraw | | Instance 1 | | Instance 2 | | ... Instance N | | (Container) | | (Container) | | (Auto-scaled) | +---------+----------+ +---------+----------+ +----------+-----------+ | | | +----------------------+-----------------------+ | +--------v---------+ | Shared Services | | - Redis (Pub/Sub)| | - PostgreSQL | | - Object Storage | +------------------+

这套架构带来的好处是实实在在的：

• 性能瓶颈被打破：单实例最多支撑千级连接？现在可以通过增加副本数无限延伸。实测表明，在合理配置下，集群整体可支持数千并发用户稳定协作。
• 高可用性显著提升：哪怕某个实例因宿主机故障突然退出，负载均衡器会立即将其剔除，其他实例继续服务。用户端只需短暂重连，几乎不影响体验。
• 全球化低延迟成为可能：你可以在 AWS eu-west、阿里云 ap-southeast、Azure us-east 分别部署区域实例组，结合 GeoDNS 将用户导向最近节点。跨洲协作也能控制在 100ms 以内，真正实现“就近接入”。

运维层面也变得更加可控。借助 Prometheus + Grafana，你可以实时监控各实例的 CPU 使用率、内存占用、活跃连接数、Redis 消息延迟等关键指标。一旦发现某节点异常，告警触发，自动扩容或滚动更新随即启动。

安全方面也不能忽视。尽管 Excalidraw 本身简洁，但大规模部署时仍需加固：
- 所有入口前置 WAF，防御 XSS、CSRF 等常见 Web 攻击；
- Redis 和数据库开启认证与 TLS 加密；
- 房间访问通过 JWT Token 控制权限，防止未授权窥探。

值得一提的是，这种架构也为未来的智能化演进留下了空间。想象一下：你在白板上写下“帮我画一个三层微服务架构”，后台调用 LLM 接口，自动生成包含 API 网关、业务服务、数据库的标准图示，并插入到当前画布中。这类 AI 辅助生成功能，完全可以集成在后端服务中，而不影响前端稳定性。

事实上，已经有团队在探索将自然语言转图表的能力嵌入 Excalidraw 后端，配合多实例架构，为数百个教育机构提供在线教学白板服务。老师一句话，就能生成流程图辅助讲解，学生则在另一端实时观看并参与修改——这已经不再是简单的绘图工具，而是一种新型的知识交互平台。

回到最初的问题：为什么我们需要 Excalidraw 支持多实例并发？

答案其实很清晰：因为它代表了一种转变——从“个人生产力工具”到“组织级协作基础设施”的跃迁。当一个工具能被纳入 CI/CD 流程、能随流量自动伸缩、能在全球范围内低延迟响应、能与 AI 深度融合时，它就已经超越了功能本身，成为数字时代团队运转的“神经系统”之一。

而这一切的基础，正是那个看似不起眼的容器镜像。它把代码、环境、配置封装成一个可复制、可调度、可编排的单元，使得 Excalidraw 不再受限于某一台服务器的命运，而是能够在云原生的浪潮中自由生长。

未来，随着边缘计算的发展，也许我们还能看到 Excalidraw 实例部署在离用户更近的地方——CDN 节点、本地数据中心，甚至是混合云环境中。那时，“打开白板”将像打开网页一样自然，而背后的复杂性，早已被良好的架构悄然化解。

这种高度集成与弹性扩展的设计思路，正引领着轻量级协作工具向更可靠、更智能、更普及的方向演进。