3、远程升级架构设计：C/S架构、B/S架构、P2P架构在终端升级中的对比

各位做配电终端的朋友，咱们今天聊点实在的。

远程升级这事儿，说白了就是给挂在电线杆上、配电房里的那些终端设备“换脑子”。架构选不对，后面全是坑。我这些年见过太多项目，升级到一半终端变砖，最后只能派人提着笔记本去现场刷机——那叫一个狼狈。

今天我把三种主流架构掰开揉碎了讲。C/S、B/S、P2P，到底谁适合你的场景？咱们一个一个看。

3.1 C/S架构：老牌劲旅，稳如老狗

C/S架构，就是客户端-服务器模式。终端作为客户端，升级服务器在后台等着。

工作流程很简单：

  1. 终端主动轮询服务器：“有新版固件吗？”
  2. 服务器返回版本信息。
  3. 如果有新版本，终端下载固件包，校验，然后重启升级。

我个人习惯用这种架构做小规模部署。比如一个变电站下面管着几十台FTU（馈线终端），用C/S架构非常顺手。

优点：

  • 终端主动发起，服务器压力小。你想想看，一万台终端不会同时去抢服务器，因为轮询间隔可以错开。
  • 安全性高。终端只认固定的服务器IP，中间人攻击很难得手。
  • 断点续传好实现。我在项目中遇到过网络不稳定的情况，C/S架构配合分段下载，断了能从断点接着传。

缺点也很明显：

  • 每台终端都要装客户端软件。维护客户端本身就是一个麻烦事。
  • 升级策略不灵活。你想临时给某几台终端推个紧急补丁？得改服务器配置，或者等终端下次轮询。
  • 我曾经吃过一次亏：终端轮询间隔设成了24小时，结果漏洞爆发，等所有终端升级完，黄花菜都凉了。
// 典型的C/S升级轮询代码片段（伪代码）
while(1) {
    if (check_interval_expired()) {
        response = http_get("https://upgrade.example.com/version");
        if (response.version > local_version) {
            download_firmware(response.url);
            verify_checksum();
            reboot_to_upgrade();
        }
    }
    sleep(轮询间隔);
}

3.2 B/S架构：浏览器里搞定一切

B/S架构，就是浏览器-服务器模式。终端内置一个轻量级Web服务器，运维人员用浏览器访问终端，上传固件，点击升级。

嗯，这里要注意：B/S架构的“浏览器”不是指PC上的Chrome，而是终端里跑的一个微型HTTP服务。说白了，终端自己就是个网页服务器。

典型流程：

  1. 运维人员打开浏览器，输入终端IP。
  2. 登录终端Web管理页面。
  3. 选择固件文件，点击“上传并升级”。
  4. 终端接收文件，校验，重启。

适用场景：

我建议在运维人员需要频繁现场调试时用B/S架构。比如配电房里的站所终端（DTU），运维人员带着平板电脑过去，连上Wi-Fi，打开浏览器就能升级，不用带任何专用软件。

优点：

  • 零客户端安装。只要有浏览器，任何设备都能升级。
  • 操作直观。上传文件、点个按钮，完事。
  • 适合小批量、高频率的升级场景。

缺点：

  • 安全性堪忧。Web服务暴露在网络上，容易被扫描和攻击。我记得有个项目，终端Web页面没做登录验证，结果被隔壁小孩乱点升级，搞得全线瘫痪。
  • 不适合大规模并发。你想想看，一千台终端同时开着Web页面，服务器得扛多大压力？
  • 断点续传基本别想。浏览器上传大文件，断了就得重来。
<!-- B/S架构的升级页面核心逻辑 -->
<form action="/upload" method="post" enctype="multipart/form-data">
    <input type="file" name="firmware" accept=".bin">
    <input type="submit" value="开始升级">
</form>
<script>
    // 上传完成后触发升级
    function onUploadComplete() {
        fetch('/upgrade', {method: 'POST'});
    }
</script>

3.3 P2P架构：去中心化的野路子

P2P架构，就是点对点模式。终端之间互相传固件，没有中心服务器。

这个架构在配电领域用得不多，但我认为在某些场景下很有价值。比如偏远山区的光伏并网终端，网络条件差，中心服务器根本连不上。

工作原理：

  1. 一台终端从运维人员的U盘或手机热点获取新固件。
  2. 这台终端变成“种子节点”，向周围终端广播：“我有新固件！”
  3. 其他终端从种子节点下载固件，下载完成后自己也变成种子。
  4. 像病毒一样扩散，直到所有终端都升级完成。

优点：

  • 没有单点故障。一台服务器挂了，不影响其他终端升级。
  • 带宽利用率高。一百台终端同时升级，不会挤爆一台服务器，因为流量分散在终端之间。
  • 适合无中心网络的场景。比如微电网、孤岛运行模式。

缺点：

  • 升级进度不可控。你没法知道哪台终端升级了，哪台没升级。
  • 安全性风险大。终端之间互相传文件，万一有恶意节点注入假固件，后果不堪设想。
  • 我曾经在一个实验项目中试过P2P升级，结果因为网络拓扑太复杂，有些终端永远找不到种子节点，最后还得派人去现场。
// P2P升级的简单广播逻辑
void broadcast_upgrade_available() {
    udp_broadcast("NEW_FIRMWARE_AVAILABLE", firmware_hash);
}

void on_receive_broadcast(packet) {
    if (packet.firmware_hash != local_hash) {
        peer = select_peer_with_best_speed();
        download_from_peer(peer, packet.firmware_hash);
        verify_and_upgrade();
        broadcast_upgrade_available(); // 变成新种子
    }
}

3.4 三种架构对比：一张表说清楚

对比维度 C/S架构 B/S架构 P2P架构
部署难度 中等（需装客户端） 低（只需浏览器） 高（需组网协议）
安全性 高（固定服务器） 中（Web暴露面大） 低（节点互信难）
并发能力 强（错峰轮询） 弱（浏览器并发有限） 极强（流量分散）
断点续传 支持良好 基本不支持 依赖实现
运维友好度 一般（需配置客户端） 高（网页操作） 低（不可控）
适用规模 百级到千级 十级到百级 千级以上
典型配电场景 FTU集中管理 DTU现场调试 微电网/孤岛

3.5 我的选择建议

说了这么多，到底怎么选？我个人的经验是：

  • 如果你管着几百台终端，网络稳定， 选C/S架构。稳，省心，出了问题好排查。
  • 如果你经常跑现场，需要临时升级几台设备， 选B/S架构。方便，带个手机就能干活。
  • 如果你在做实验项目，或者终端分布在无网络地区， 可以试试P2P架构。但要做好安全防护，别让固件被篡改。

避坑指南：

我曾经在一个项目中混合使用了C/S和B/S架构——终端平时用C/S自动轮询升级，运维人员现场调试时用B/S手动干预。效果不错，但要注意两种架构不能冲突，比如同时触发升级会导致固件写坏。解决办法是加一个互斥锁，同一时间只允许一种升级方式生效。

最后说一句：架构没有绝对的好坏，只有适不适合你的场景。你想想看，一个只有50台终端的配电房，非要去搞P2P架构，那不是给自己找麻烦吗？

下一章咱们聊聊升级过程中的安全策略，包括固件签名、加密传输、回滚机制这些硬核内容。到时候见。

← 上一章 📖 返回目录 下一章 →