2、分布式部署架构设计：中心节点与边缘节点架构、通信协议选型（MQTT/HTTP）、冗余与容错机制

好，咱们接着聊。上一章我们把充电宝的硬件选型定了下来，这一章，咱们要解决一个更核心的问题——这么多充电宝，怎么管起来？

你想想看，一个地铁站，少说几十台设备，大站上百台。如果每台都直接连到服务器，服务器扛不住，网络也扛不住。我早年做过一个项目，就是这种“直连”架构，结果一到早晚高峰，服务器直接挂了。嗯，从那以后，我就彻底转向了分布式架构。

2.1 中心节点与边缘节点架构

说白了，就是把计算能力“下沉”。

我们设计了两层结构：

• 中心节点：部署在车站的弱电机房或通信机房。负责全局调度、数据汇总、与上层业务系统对接。
• 边缘节点：部署在充电宝机柜内部或旁边。负责本地设备控制、实时响应、断网时独立运行。

我个人的习惯是，边缘节点一定要“够用”。别省那点硬件成本，否则后面运维会让你头疼死。我在深圳某地铁线项目中，就因为边缘节点选了个低配的ARM板，结果并发处理能力不足，充电宝归还时经常超时。后来全部换成了RK3588级别的板子，问题才解决。

具体分工如下：

功能模块	中心节点	边缘节点
设备管理	全局设备状态监控	本地设备实时控制
订单处理	订单生成、支付对接	本地缓存订单、断网续传
数据存储	全量数据持久化	最近7天数据本地缓存
故障处理	全局告警、派单	本地自检、自动恢复
固件升级	版本管理、下发策略	下载校验、回滚机制

2.2 通信协议选型：MQTT vs HTTP

这个问题，我几乎在每个项目里都会被问到。其实没那么复杂，看场景。

MQTT，我强烈推荐用于设备与边缘节点之间的通信。为什么？

• 它是发布/订阅模式，天然适合一对多。
• 报文头极小，只有2字节，适合窄带宽场景。
• 支持三种QoS等级，从“最多发一次”到“确保到达”。
• 有心跳保活机制，能及时发现设备离线。

我曾经在成都某地铁线项目中，用MQTT实现了2000多台充电宝的实时状态上报。每台设备每5秒上报一次心跳，服务器端毫无压力。如果用HTTP，光是TCP连接的开销就够呛。

HTTP，则更适合边缘节点与中心节点之间的通信。原因也很简单：

• HTTP是请求-响应模式，适合“查询”类操作，比如查订单、查用户信息。
• RESTful API设计成熟，团队上手快。
• 配合HTTPS，安全性有保障。
• 适合大数据量的上传，比如日志文件、监控截图。

但要注意，HTTP不适合高频、小数据量的场景。你想想看，如果每台设备每秒钟都发一个HTTP请求，服务器光处理握手就忙不过来了。

所以，我的建议是混合使用：

• 设备 ↔ 边缘节点：MQTT
• 边缘节点 ↔ 中心节点：HTTP + MQTT（双通道）

2.3 冗余与容错机制

轨道交通场景，最怕的就是“单点故障”。一旦中心节点挂了，整个站的充电宝都不能用，那乘客投诉可就来了。

所以，冗余设计是必须的。我一般从三个层面来考虑：

2.3.1 中心节点冗余

• 主备切换：两台服务器，一台主一台备。主节点挂了，备节点自动接管。我用的是Keepalived + HAProxy，切换时间控制在3秒以内。
• 数据同步：主备之间通过数据库主从复制，保证数据一致性。如果网络中断，备节点也能基于本地缓存的数据继续服务。

2.3.2 边缘节点容错

• 本地缓存：边缘节点本地存储最近7天的订单数据和设备状态。即使与中心节点断连，也能独立运行。
• 自动重连：网络恢复后，边缘节点自动将缓存数据上传，并同步最新策略。
• 看门狗机制：边缘节点上跑一个看门狗进程，如果主进程挂了，自动重启。我一般设置3次重启失败后，触发硬件复位。

2.3.3 通信链路冗余

• 双网口设计：边缘节点配两个网口，一个连有线，一个连4G/5G。有线断了自动切到无线。
• MQTT集群：中心节点部署MQTT Broker集群，比如EMQX或VerneMQ。单个Broker挂了，客户端自动切换到其他Broker。
• 消息持久化：MQTT消息开启持久化，即使Broker重启，消息也不会丢失。

我记得有一次在上海某地铁站做压力测试，模拟了中心节点宕机的情况。结果边缘节点自动切换到4G网络，本地缓存正常服务了整整4个小时，直到中心节点恢复。嗯，那一刻我觉得，之前的冗余设计没白做。

2.4 小结

这一章的内容，说白了就是一句话：让该快的快，让该稳的稳。

边缘节点负责本地实时控制，中心节点负责全局调度。MQTT搞定设备通信，HTTP搞定业务查询。冗余设计不是浪费，而是为了关键时刻不掉链子。

下一章，咱们聊聊具体的通信协议实现，我会给出完整的MQTT Topic设计和HTTP API接口定义。到时候，你可以直接拿来用。