4. 更新通道架构设计：C/S架构 vs P2P架构、更新服务器的角色、客户端更新代理的设计原则

更新通道的架构设计，说白了就是回答一个问题：更新包怎么从服务器跑到客户端手里？

我这些年见过不少团队，上来就选P2P，觉得时髦、省带宽。结果呢？内网环境里节点太少，P2P根本跑不起来，最后还得老老实实搭个中心服务器。所以啊，架构选型没有银弹，得看你的实际场景。

4.1 C/S架构 vs P2P架构

这两种架构，我分别说说我的理解。

4.1.1 C/S架构（客户端-服务器）

这是最传统的模式。客户端直接向更新服务器请求更新包。服务器是唯一的数据源。

• 优点：实现简单，控制权完全在服务端。审计、回滚、灰度发布都好做。
• 缺点：服务器压力大。如果几万台设备同时请求更新，带宽和IO都是瓶颈。我在项目中遇到过，一个游戏更新包2GB，同时在线10万人，CDN费用直接爆表。
• 适用场景：企业内网、设备数量可控、对安全要求极高的场景。

4.1.2 P2P架构（点对点）

客户端不仅从服务器下载，还从其他已经下载完成的客户端那里获取数据块。

• 优点：天生抗压，节点越多下载越快。服务器只需要做种子分发和Tracker协调。
• 缺点：实现复杂。需要处理NAT穿透、节点发现、数据块校验、防污染等问题。另外，P2P流量可能会被企业防火墙拦截。
• 适用场景：大规模公网分发、IoT设备集群、游戏更新。

下面这张图，是我常用的混合架构逻辑：

4.2 更新服务器的角色

更新服务器不是一台机器，而是一个角色集群。我习惯把它拆成三个逻辑角色：

角色	职责	关键设计点
元数据服务器	管理更新清单、版本号、校验和、策略配置	必须高可用，数据量小但请求量大。我一般用Redis+MySQL做缓存穿透保护。
存储服务器	存放更新包本体（二进制文件）	关注IO和带宽。大文件用对象存储（如MinIO），小文件用本地磁盘。
分发调度器	决定客户端从哪下载、是否限速、是否灰度	这是核心。我习惯把调度逻辑做成可热更新的规则引擎。

4.3 客户端更新代理的设计原则

客户端更新代理，就是跑在设备上的那个小守护进程。它设计得好不好，直接决定了更新通道的成败。我总结了五个原则：

4.3.1 原则一：幂等性

更新操作必须可以重复执行，且结果一致。不管客户端断网重连多少次，最终状态都是对的。

• 每次更新前记录当前版本和期望版本。
• 更新完成后做全量校验，不通过就回滚。
• 我习惯用两阶段提交的思路：先下载暂存区，校验通过后再替换生效。

4.3.2 原则二：断点续传与增量更新

大包下载到一半断了，不能从头再来。这是用户体验的底线。

• 支持HTTP Range请求，记录已下载的字节偏移量。
• 增量更新用bsdiff或xdelta，只下载变化的部分。我在项目中做过统计，增量包通常只有全量包的5%-15%。

4.3.3 原则三：安全校验

更新代理是安全通道的最后一道防线。我曾经见过一个案例，客户端没做签名校验，结果被中间人攻击植入了恶意固件。

• 必须验证更新包的数字签名（RSA或ECDSA）。
• 校验更新包的哈希值（SHA-256）。
• 验证证书链，防止证书伪造。

4.3.4 原则四：优雅降级与回滚

更新失败是常态，不是异常。代理必须能处理各种失败场景。

• 下载失败：切换备用服务器或P2P源。
• 校验失败：删除已下载数据，记录错误日志，等待下次重试。
• 应用失败：自动回滚到上一个可用版本。我习惯保留最近3个版本的备份。

4.3.5 原则五：资源控制

更新代理不能把设备的CPU、内存、带宽吃光。尤其是IoT设备，资源本来就紧张。

• 限制下载带宽（比如不超过总带宽的30%）。
• 在设备空闲时执行更新（比如凌晨2点）。
• 监控电池电量，低于20%时不执行更新。