协同系统架构：集中式 vs 分布式

做多机协同，第一个要拍板的问题就是：谁来当老大？

说白了，就是整个机群的决策权怎么分配。我这些年折腾下来，发现这步选错了，后面代码写得再漂亮也白搭。咱们先看两种最基础的架构模式。

集中式架构

集中式架构，就是有一架「长机」或者地面站，负责所有计算和决策。其他无人机都是「僚机」，只听命令，不自己拿主意。

我在做物流配送项目时，就用的集中式。地面站一台工控机，管着6架无人机。所有路径规划、避障、任务分配，全在地面算好，再下发给每架飞机。

优点很明显：

• 全局最优解容易算。因为所有信息都在一个地方
• 控制逻辑简单。僚机就是个执行器，代码量少
• 调试方便。出问题就查中心节点

缺点也致命：

• 单点故障。中心挂了，整个机群瘫痪
• 通信压力大。所有数据都往中心挤
• 实时性受限。数据来回传，延迟累积

分布式架构

分布式就不一样了。每架无人机都有自己的「脑子」，能独立决策。大家通过通信协商，达成一致。

你想想看，这就像一群狼打猎。没有狼王发号施令，但每只狼都知道自己该站哪个位置。

优点：

• 鲁棒性强。坏一两架，剩下的还能继续干
• 扩展性好。加飞机不用改中心代码
• 实时性高。本地决策，不用等远程指令

缺点：

• 算法复杂。要解决共识问题、冲突问题
• 调试困难。问题可能出现在任何节点
• 难以保证全局最优

主从模式 vs 对等模式

架构选完了，接下来要定节点之间的关系。这里有两种模式：主从和对等。

主从模式

主从模式里，有一个主节点，其他都是从节点。主节点负责协调，从节点负责干活。

我在做编队飞行时，就用的主从。长机飞在前面，记录轨迹。僚机跟在后面，保持队形。长机说往左，大家就往左。

# 伪代码示例：主从模式下的僚机控制
while True:
    # 接收主节点指令
    cmd = receive_from_master()
    
    # 执行指令
    if cmd.type == 'MOVE':
        fly_to(cmd.target_position)
    elif cmd.type == 'HOVER':
        hover()
    elif cmd.type == 'LAND':
        land()
    
    # 上报状态
    send_status_to_master()

适用场景：

• 编队飞行（长机-僚机）
• 搜索救援（地面站指挥）
• 物流配送（调度中心分配任务）

对等模式

对等模式里，所有节点地位平等。没有谁指挥谁，大家商量着来。

我记得做分布式覆盖任务时，6架无人机要均匀覆盖一片区域。没有中心节点，每架飞机只跟邻居通信，最后居然能自动均匀分布。说实话，第一次跑通时我自己都惊了。

# 伪代码示例：对等模式下的协商
def negotiate_with_neighbors():
    my_position = get_current_position()
    neighbors_positions = get_neighbors_positions()
    
    # 计算理想位置（基于邻居位置）
    target = calculate_ideal_position(my_position, neighbors_positions)
    
    # 如果偏差太大，就移动
    if distance(my_position, target) > THRESHOLD:
        fly_to(target)

适用场景：

• 分布式覆盖
• 集群搜索
• 自组织网络

通信拓扑：星型、环型、全连接

节点关系定了，接下来要设计通信拓扑。说白了，就是谁跟谁说话。

星型拓扑

所有节点都连到一个中心节点。中心节点负责转发消息。

特点：

• 结构简单，容易管理
• 中心节点压力大
• 中心节点挂了，全网瘫痪

我早期做地面站系统时，用的就是星型。地面站是中心，所有无人机直连地面站。简单粗暴，但确实好用。

环型拓扑

节点连成一个环。每个节点只跟左右邻居通信。消息沿着环传递。

特点：

• 没有中心节点，鲁棒性好
• 消息传递延迟随环大小线性增长
• 一个节点坏了，环就断了

环型拓扑我用的不多。说实话，在无人机场景里，环型拓扑的延迟问题比较头疼。你想，10架飞机绕一圈，消息要经过10跳，实时性很难保证。

全连接拓扑

每个节点都跟其他所有节点直连。这是最「奢侈」的拓扑。

特点：

• 延迟最低，任意两点直连
• 鲁棒性最强，坏几个节点不影响
• 通信开销最大，N个节点需要N*(N-1)/2条链路

系统实时性要求

做多机协同，实时性是绕不开的坎。我见过太多项目，算法写得漂亮，但一跑起来就掉链子。为什么？实时性没满足。

关键指标

指标	说明	典型值
端到端延迟	从数据产生到被消费的时间	< 100ms
控制周期	两次控制指令的间隔	10-50ms
通信抖动	延迟的波动范围	< 20ms
同步精度	多机时间同步误差	< 1ms

影响实时性的因素

我踩过的坑，总结下来就这几个：

1. 通信介质：WiFi延迟大，但方便。数传电台延迟小，但带宽低。我建议关键控制链路用数传，状态上报用WiFi
2. 协议栈：TCP可靠但慢，UDP快但可能丢包。控制指令用UDP，文件传输用TCP
3. 节点数量：节点越多，通信压力越大，延迟越高。10架以内还好，超过20架就要考虑分层了
4. 计算负载：机载计算机性能有限。别在飞控上跑深度学习，那是找死

知识体系总览

说了这么多，咱们用一张图把整个知识体系串起来：

这张图把咱们今天讲的内容串起来了。从上到下，先选架构模式，再定节点关系，最后设计通信拓扑。每一步的选择都会影响系统的实时性。

好了，这一章的内容就到这儿。记住一句话：没有最好的架构，只有最合适的架构。选型时多想想你的应用场景、节点数量、实时性要求，别盲目追求高大上。

---

公众号:蓝海资料掘金营，微信deep3321