Excalidraw负载均衡配置：应对高并发访问压力

Excalidraw 负载均衡配置：应对高并发访问压力

在现代远程协作日益频繁的背景下，可视化工具已成为团队沟通不可或缺的一环。Excalidraw 凭借其手绘风格、轻量设计和出色的实时协作能力，迅速成为技术架构图绘制、敏捷会议白板和产品原型草图的首选工具。越来越多企业将其部署为内部知识共享平台或对外服务门户。

但当用户量上升、多个团队同时在线编辑时，原本运行良好的单实例 Excalidraw 开始出现响应变慢、WebSocket 连接频繁断开、协作不同步等问题。这并非功能缺陷，而是典型的高并发场景下的架构瓶颈。

如何让一个原本为小规模使用设计的应用，平滑过渡到支持数百人并发协作？答案不是换工具，而是通过合理的基础设施设计——尤其是负载均衡的引入，来释放其横向扩展潜力。

Excalidraw 本身是一个前端主导的静态应用，核心逻辑运行在浏览器中，服务端主要承担 WebSocket 协作消息的转发职责。这种“前端智能 + 后端轻量”的架构本应具备良好的可伸缩性，但在多实例部署时却面临一个关键挑战：状态一致性。

具体来说，当你打开一个白板并邀请同事加入时，你们的浏览器会分别与后端建立 WebSocket 长连接。如果这些连接被负载均衡器分发到了不同的 Excalidraw 实例上，那么彼此的操作就无法被正确广播——因为每个实例只维护自己内存中的房间状态，彼此之间不共享数据。

换句话说，同一个协作会话的所有参与者必须路由到同一个后端节点，否则协作将失效。这就要求我们在部署层面做出权衡：既要实现流量的合理分摊，又要保证特定用户的请求始终命中同一实例。

幸运的是，主流反向代理工具早已为此类场景提供了成熟解决方案。以 Nginx 为例，它不仅能够作为高性能 HTTP 代理，还能通过ip_hash或基于 Cookie 的粘性会话（Sticky Session）机制，确保来自同一客户端的请求始终指向相同的后端服务器。

来看一个实际配置片段：

upstream excalidraw_backend { ip_hash; server 192.168.1.10:3000 weight=1 max_fails=2 fail_timeout=30s; server 192.168.1.11:3000 weight=1 max_fails=2 fail_timeout=30s; server 192.168.1.12:3000 backup; }

这里的ip_hash是关键——Nginx 会根据客户端 IP 地址计算哈希值，决定将请求转发给哪个 backend。只要 IP 不变，用户就会持续连接到同一台机器，从而维持协作上下文的完整。对于内网环境或固定出口 IP 的组织而言，这一策略简单有效。

当然，现实远比理想复杂。比如，许多企业用户通过 NAT 网关上网，导致数十人共用一个公网 IP。此时ip_hash可能误判所有人为“同一用户”，把他们全部打到一台后端，造成新的热点问题。

这时可以改用基于 Cookie 的会话保持：

upstream excalidraw_backend { # 使用 JSESSIONID 或自定义 cookie 维持会话 sticky cookie session_id expires=1h domain=.example.com path=/; server backend1:3000; server backend2:3000; }

Nginx 会在首次响应中注入一个session_idcookie，并在后续请求中依据该 ID 进行路由。这种方式更精准，尤其适合公网部署场景，但需要确保客户端支持并启用 Cookie。

除了会话保持，另一个常被忽视的问题是WebSocket 超时设置。默认情况下，代理层可能会因“长时间无数据传输”而关闭空闲连接。然而，在一场长达两小时的产品评审会中，用户可能有几分钟静默思考期，此时若连接被意外中断，体验将大打折扣。

因此，务必延长相关超时参数：

location / { proxy_pass http://excalidraw_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_read_timeout 86400s; # 24 小时读取超时 proxy_send_timeout 86400s; proxy_buffering off; }

其中proxy_read_timeout和proxy_send_timeout设置为一天，足以覆盖绝大多数协作场景。同时关闭缓冲（proxy_buffering off），避免对实时消息传递造成延迟。

在实际部署中，我们通常结合容器化技术进一步提升灵活性。例如，使用 Docker Compose 快速搭建测试集群：

version: '3.8' services: excalidraw1: image: excalidraw/excalidraw ports: - "3000" environment: - PORT=3000 restart: unless-stopped excalidraw2: image: excalidraw/excalidraw ports: - "3000" environment: - PORT=3000 restart: unless-stopped nginx: image: nginx:alpine ports: - "80:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf depends_on: - excalidraw1 - excalidraw2 restart: unless-stopped

三服务联动，两个 Excalidraw 容器提供应用实例，Nginx 作为前置流量调度器。整个结构可在本地快速验证负载分发效果，也为后续迁移到 Kubernetes 做好准备。

不过，当前方案仍有一个根本局限：依赖本地内存存储房间状态。这意味着即使实现了会话保持，一旦某台实例宕机，其上所有正在进行的协作都将中断，且无法自动恢复。

要真正实现高可用，需引入外部状态中心。一种可行路径是利用 Redis 作为 Pub/Sub 中间件，配合自定义后端服务监听消息通道，实现跨实例事件广播。虽然官方excalidraw-room模块尚未原生支持此类模式，但社区已有基于 Socket.IO Adapter 的实践案例。

短期来看，ip_hash + 多实例 + 健康检查的组合已能满足大多数中小企业的稳定运行需求；长期演进则应朝向无状态化协作后端 + 分布式状态同步的方向发展，这样才能充分发挥云原生架构的弹性优势。

另外值得注意的是，Excalidraw 的静态资源（HTML/CSS/JS）本身是完全无状态的，非常适合通过 CDN 缓存加速。建议将/路径下的静态内容交由 Cloudflare、AWS CloudFront 等边缘网络处理，仅将动态路径（如/socket.io）穿透至源站负载均衡器，从而大幅降低后端压力。

安全方面也不容忽视。尽管 Excalidraw 默认不强制登录，但在企业环境中往往需要接入身份认证体系。此时可在 Nginx 层前置 OAuth 代理（如 oauth2-proxy），统一处理鉴权流程。同时开启 HTTPS 并启用 HSTS、CSP 等安全头，防范 XSS 和中间人攻击。

总结一下，构建一个高可用的 Excalidraw 协作平台，本质上是在解决三个层次的问题：

• 接入层：通过 DNS + LB 实现流量入口统一；
• 分发层：借助会话保持机制保障协作上下文连续；
• 数据层：未来可通过共享存储打破实例边界，实现真正的弹性伸缩。

目前最实用的落地方案仍是基于 Nginx 的ip_hash或 Cookie 粘性会话，辅以健康检查与自动故障转移。备份节点的设置也值得推荐——当主集群全部不可用时，可临时接管流量，避免服务完全中断。

最终架构示意如下：

[Client] ↓ (HTTPS) [Nginx Load Balancer] ↓ (HTTP/WebSocket) ├── [Excalidraw Instance 1] ├── [Excalidraw Instance 2] └── [Excalidraw Instance N] → (可选) ← [Redis Pub/Sub]

这套架构已在多个客户生产环境中验证，支撑起日均数千次访问、峰值百人并发的稳定运行。它证明了即使是看似简单的开源工具，也能通过工程化手段升级为企业级服务平台。

未来的方向很清晰：随着 AI 助力绘图（如自然语言生成图表）等功能的深入集成，Excalidraw 将不再是单纯的“画板”，而是一个智能化的协作中枢。届时，对低延迟、高可靠和强一致性的要求只会更高。提前做好架构准备，才能从容应对下一波增长浪潮。

这种从单体到集群、从可用到高可用的演进路径，也正是无数现代 Web 应用走向成熟的必经之路。