机器人系统中，地图、任务、设备、告警都运行在一个应用里，这不就是大泥球吗？

不一定。这里混淆了部署方式和代码结构。

单体描述的是部署方式

单体模式（Monolith）指的是：系统的主要能力以一个可独立交付的部署单元为主，通常整体发布和运行。

它内部仍然可以划分模块：

机器人应用
├── 设备接入
├── 地图管理
├── 任务调度
├── 状态监控
└── 告警处理

这些模块可以共同部署，但各自拥有明确职责。任务模块不必知道设备协议细节，地图模块也不应随意修改机器人连接状态。

所以，“部署在一起”和“代码混在一起”是两回事。

单体为什么不等于大泥球？

判断一个系统时，需要分开看两个维度：部署单元有多少个，内部边界是否清晰。

先看左上：它就是本文要保留的状态——部署简单，但模块边界清楚。再看右下：即使拆成多个进程，边界不清、发布仍然互相牵制，也未必得到更好的架构。

左上角是模块化单体：地图、任务、设备和告警各有归属，但仍然一起发布。

左下角才是通常所说的大泥球：界面直接操作设备，任务流程随意读取地图内部数据，告警逻辑散落在各个角落。它恰好是单体，但混乱来自边界消失，而不是部署单元只有一个。

右上角是边界清晰的分布式系统。各单元可以独立演进，但同时也要承担通信、部署和数据一致性成本。它不天然优于左上角，只是适合不同约束。

右下角是分布式单体：看起来已经拆开，变化和发布却仍然绑在一起。一次需求要同时修改多个单元，发布顺序相互依赖，数据也被随意共享。

图里真正的区别是：拆分部署可以改变运行边界，却不会自动创造职责边界。

为什么单体常常适合作为起点？

机器人系统早期，最难的通常不是部署，而是确定归属。

例如，机器人离线后的任务恢复应该由任务模块负责，还是由设备模块负责？地图版本由地图模块管理，还是由机器人档案管理？这些问题通常需要经过真实业务才能逐渐清晰。

在边界尚未稳定时保持单体，有几个直接好处：

• 模块之间可以进行本地调用，不必先设计远程协议；
• 调试和部署路径更短；
• 边界判断错误时，调整成本相对较低。

单体减少的是系统刚起步时不必要的分布式复杂度。

单体也有明确代价

单体的主要问题不是“不够先进”，而是多个模块共享同一个发布和运行边界。

• 修改一个模块，通常要重新测试和发布整个应用；
• 某个模块出现严重故障，可能影响整体运行；
• 模块难以独立扩容，团队发布节奏也会相互影响。

这些代价真实存在。但它们是否已经超过拆分后的通信、数据一致性、部署和故障处理成本，需要结合系统现状判断。

什么时候才值得拆？

代码量大、目录多，或者团队开始讨论微服务，都不是充分理由。

更可靠的拆分信号是：

• 某个模块需要独立扩容；
• 某类故障必须与其他能力隔离；
• 不同模块确实需要独立发布；
• 职责和数据归属已经稳定，拆分边界可以明确表达。

一个“必须拆”的案例

仓库机器人系统里，云端负责任务编排、地图管理和车队调度，车端负责避障、急停和电机控制。

这两部分不能长期共用一个部署单元：云端升级、网络中断，甚至任务模块崩溃，都不应该让车辆失去实时控制能力。此时需要把云端调度和车端控制拆成独立进程或独立设备，让车端在云端失联时仍能停车、避障并进入安全状态。

这不是为了让架构“看起来像微服务”，而是因为安全、实时性和故障隔离要求它们不能共享同一个故障边界。

这里的顺序很重要：先形成模块边界，再考虑部署边界。

如果地图、任务和设备之间仍然互相穿透，提前拆分只会把函数调用变成网络调用，把共享对象变成共享数据库，把一次修改变成多次协调。

怎么判断单体是否健康？

不用先数代码行数，可以直接问三个问题：

• 修改一种任务规则，需要同时改设备、地图和界面吗？
• 每份核心状态是否有明确的维护者？
• 核心规则能否脱离界面、数据库和通信方式独立验证？

如果一次变化大多能停在所属模块内，单体就在发挥它应有的价值。

最后

单体不是微服务之前的失败阶段，也不是大泥球的另一个名字。

判断单体是否健康，不要看它被部署成几份，要看一次变化最终会传播多远。