agv系统的核心是调度软件。小规模时单体架构足够，但当AGV数量超过五十台时，单体软件容易崩溃。本文解析从单体到微服务的架构演进，帮助用户选择合适的方案。
一、单体架构：适合小型车队
单体架构将所有功能（路径规划、交通管制、任务分配、通信、监控）打包在一个进程内。优点是开发简单，部署快捷，适合AGV数量少于三十台的场景。缺点是任何模块的故障会导致整个系统宕机，并且无法横向扩展。某工厂二十台AGV使用单体调度，运行正常；当增加至四十台时，服务器CPU负载经常达到百分之九十，任务响应延迟超过五秒。升级硬件也难解决，需要架构重构。
二、模块化与分布式部署
将单体拆分为多个独立模块，例如任务管理器、路径规划器、交通管制器、通信网关、监控看板。每个模块可部署在不同的服务器上，通过消息队列通信。优点是模块间隔离，一个模块崩溃不会影响其他；可根据负载独立扩展，例如增加路径规划器实例。适用于三十到一百台AGV。某汽车厂使用模块化架构，支持了八十台AGV，系统可用性达到百分之九十九点九。
三、微服务架构：适合大规模集群
对于超过一百台的集群，推荐微服务架构。每个服务都是独立的小应用，拥有自己的数据库，通过REST API或gRPC通信。服务可以动态伸缩，例如早晚高峰自动增加任务分配服务实例。服务发现和负载均衡使用注册中心。容器化部署（Docker加K8s），实现自动容灾。某电商物流中心三百台AGV使用微服务架构，单点故障时系统自动重启故障服务，AGV几乎无感知。
四、高可用与灾备设计
无论哪种架构，高可用都是必须的。部署至少两台服务器作为主备，主节点故障时备用节点自动接管。使用浮动IP或虚拟IP。数据库采用主从复制，定期备份。关键数据如地图文件、配置参数必须持久化存储。每季度进行一次灾备演练，模拟主服务器宕机，验证切换时间小于一分钟。某工厂未做高可用，一次服务器硬盘损坏导致全厂AGV停机八小时，损失重大。
五、实时性保障与通信协议
调度软件的实时性要求任务下达到AGV接收延迟小于五十毫秒。使用消息队列（如ZeroMQ或Kafka）降低延迟。对于高实时控制信号，采用共享内存或RTOS。AGV与调度之间的通信协议推荐VDA5050或私有但高效的二进制协议。避免使用HTTP轮询，延迟太大。定时任务心跳检测AGV在线状态，超时三秒未收到心跳则判定离线。
六、选型建议与案例
小型企业（AGV少于三十台）：选择轻量级单体调度，但要求厂家提供定期备份功能。中型企业（三十到一百台）：模块化分布式部署，要求支持主备切换。大型企业（一百台以上）：微服务加容器化，要求提供API和扩展说明。成都蓉希智能的调度系统覆盖从小型到大型的全部架构，可根据用户需求灵活部署。
