最近我们团队完成了一次边缘计算系统的迁移，从旧的边缘计算平台迁移到新的平台，整个过程持续了将近两个月，踩了很多坑，也积累了很多经验。

边缘计算的迁移，和普通的云端系统迁移不太一样。云端系统都在数据中心里，网络稳定，环境统一，迁移相对简单。但边缘计算不一样，边缘节点分布在全国各地，甚至世界各地，网络环境复杂，有的在公网，有的在专网，有的带宽很高，有的带宽很低，还经常断网；硬件配置也参差不齐，有的是高性能的边缘服务器，有的是低配的工控机，甚至还有ARM架构的设备；运行环境也不一样，有的是Linux，有的是Windows，有的是定制化的系统。这些因素，都让边缘计算的迁移难度和复杂度比云端系统高很多。

我们这次迁移，涉及到两百多个边缘节点，分布在全国三十多个城市，硬件配置有四五种，操作系统有两三种，网络环境也各不相同，整个迁移过程，可以说是惊心动魄，遇到了各种各样的问题。今天来完整记录这次迁移的过程，包括迁移背景、方案设计、实施步骤、遇到的问题和解决方案，以及经验总结，希望能给做边缘计算迁移的朋友一些参考。

一、迁移背景：为什么要迁移

先说说为什么要迁移。我们的旧边缘计算平台，是三年前搭建的，那时候边缘计算还比较新，没有太多成熟的方案，我们就自己搭了一套，用的是比较轻量的架构，每个边缘节点上跑一个Agent，负责和云端通信，执行云端下发的任务，采集数据上报云端。

这套平台用了三年，随着业务的发展，越来越跟不上需求了，主要有几个问题：

1. 架构老旧，扩展性差

旧平台的架构比较简单，是中心化的，所有边缘节点都直接连云端的中心服务器，节点少的时候没问题，但随着节点数量增加到两百多个，中心服务器的压力越来越大，连接数、消息吞吐量、数据处理能力都到了瓶颈，经常出现消息延迟、数据丢失的情况。而且，旧平台的扩展性很差，增加新的功能模块很困难，每次加功能都要改核心代码，很容易出bug。

2. 设备管理能力弱

旧平台的设备管理能力很弱，只能看到节点是否在线，不能远程管理设备，不能远程升级，不能远程配置，不能远程诊断。节点出了问题，只能派人去现场处理，成本很高，效率很低。尤其是分布在全国各地的节点，出一个小问题，可能就要飞过去处理，差旅费和时间成本都很高。

3. 数据处理能力不足

旧平台的数据处理能力很弱，边缘节点只能做简单的数据采集和上报，复杂的数据处理都要传到云端做，带宽压力很大，延迟也很高。随着业务的发展，我们需要在边缘端做更多的数据处理，比如实时分析、AI推理、数据过滤、数据聚合，这些在旧平台上都很难实现。

4. 稳定性和安全性不足

旧平台的稳定性和安全性也有问题，节点经常离线，数据经常丢失，而且没有完善的安全机制，数据传输没有加密，节点身份没有认证，存在安全隐患。随着业务的发展，对稳定性和安全性的要求越来越高，旧平台已经满足不了了。

基于这些问题，我们决定搭建一套新的边缘计算平台，然后把所有边缘节点从旧平台迁移到新平台。新平台用了更先进的架构，支持分层管理，支持远程设备管理，支持边缘数据处理，有完善的稳定性和安全机制，能满足未来几年的业务需求。

二、迁移方案设计

迁移方案的设计，是整个迁移过程中最重要的环节，方案设计得好，迁移就顺利；方案设计得不好，迁移就会遇到各种各样的问题。我们在方案设计上花了将近两周的时间，反复讨论，反复修改，最终确定了一套比较完善的方案。

1. 迁移原则

我们首先确定了几个迁移原则，这些原则贯穿了整个迁移过程：

  • 业务不中断：迁移过程中，业务不能中断，不能影响正常的服务，用户不能感知到迁移。这是最重要的原则，所有的方案设计都要围绕这个原则。
  • 分批迁移：不一次性迁移所有节点，而是分批迁移，先迁一小部分，验证没问题了，再逐步扩大范围，最后全量迁移。这样可以控制风险，出了问题影响范围也小。
  • 可回滚：每个节点迁移之后，如果新平台有问题，可以快速回滚到旧平台，保证业务不中断。回滚方案要提前设计好，并且测试验证。
  • 自动化：尽量用自动化的方式迁移，减少人工操作，提高效率，降低人为失误的风险。两百多个节点，如果靠人工一个个迁移，效率太低，也容易出错。
  • 数据一致性：迁移过程中，要保证数据的一致性，不能丢数据，不能重复数据，不能出现数据混乱。

2. 双跑过渡方案

为了保证业务不中断，我们设计了双跑过渡方案。在迁移期间，旧平台和新平台同时运行，边缘节点同时连接两个平台，旧平台继续处理业务，新平台同步接收数据，验证功能。等新平台验证没问题了，再把业务切换到新平台，然后断开旧平台的连接。

具体来说，每个边缘节点上，同时运行旧Agent和新Agent，两个Agent互不干扰，各自连接各自的平台。旧Agent继续处理业务，执行任务，采集数据上报旧平台；新Agent同步采集数据上报新平台，同时接收新平台下发的任务，但不实际执行，只是记录下来，验证任务下发是否正常。这样，新平台可以在不影响业务的情况下，验证数据采集、任务下发、通信连接等功能是否正常。

等新平台验证一段时间（一般是一到两周），确认所有功能都正常，数据和旧平台一致，就可以切换业务了。切换的时候，把旧Agent的业务处理停掉，让新Agent开始实际执行任务，这样业务就从旧平台切换到了新平台。切换之后，再观察一段时间（一般是一周），确认新平台运行稳定，没有问题，就可以把旧Agent停掉，完成这个节点的迁移。

这个双跑过渡方案，虽然复杂一些，需要同时运行两个Agent，但能最大程度地保证业务不中断，风险可控，出了问题可以快速回滚，是比较稳妥的方案。

3. 分批迁移策略

我们把两百多个节点分成了五批，每批四五十个节点，按照从易到难、从非核心到核心的顺序迁移：

  • 第一批：测试环境节点和非核心业务节点。先迁测试环境的节点，以及一些非核心业务的节点，这些节点即使出了问题，影响也不大，可以用来验证迁移方案和工具的可行性。
  • 第二批：普通业务节点。第一批验证没问题后，迁普通业务节点，这些节点承载着正常的业务，但不是最核心的，出了问题影响可控。
  • 第三批：核心业务节点。普通节点验证没问题后，迁核心业务节点，这些节点承载着关键业务，对稳定性要求很高，迁移的时候要格外小心。
  • 第四批：特殊环境节点。包括网络环境差的节点、硬件配置特殊的节点、操作系统特殊的节点，这些节点迁移难度大，放在后面，等迁移工具和方案都成熟了再迁。
  • 第五批：剩余节点和收尾。最后迁剩下的节点，然后做全量验证，确认所有节点都迁移完成，运行稳定，然后下线旧平台。

每批迁移之间，间隔一周左右，用来观察迁移后的运行情况，解决遇到的问题，优化迁移工具和方案，然后再迁下一批。这样循序渐进，风险可控，也能不断积累经验，优化方案。

4. 迁移工具开发

为了实现自动化迁移，我们开发了一套迁移工具，包括几个部分：

  • 节点信息采集工具：自动采集每个边缘节点的硬件信息、操作系统信息、网络信息、旧Agent的配置信息和运行状态，汇总到迁移管理平台，方便我们了解每个节点的情况，制定迁移计划。
  • 新Agent自动部署工具：支持远程自动部署新Agent到边缘节点，支持不同的操作系统和硬件架构，部署过程自动完成，不需要人工干预。
  • 配置同步工具：自动把旧平台的配置（比如节点信息、任务配置、数据采集配置等）同步到新平台，不需要人工重新配置，减少人工操作，降低出错风险。
  • 迁移状态监控工具：实时监控每个节点的迁移状态，包括是否部署了新Agent、是否双跑中、是否切换了业务、是否完成迁移，以及新Agent的运行状态、数据上报情况、任务执行情况，方便我们跟踪迁移进度，及时发现问题。
  • 回滚工具：如果迁移后新平台有问题，可以一键回滚，把业务切回旧平台，停掉新Agent，保证业务不中断。

这套迁移工具，大大提高了迁移的效率，降低了人工操作的风险，是我们能在两个月内完成两百多个节点迁移的关键。

三、迁移实施步骤

方案和工具准备好之后，就开始正式迁移了。每个节点的迁移，大致分为几个步骤：

第一步：节点信息采集和评估

迁移之前，先用节点信息采集工具，采集目标节点的硬件信息、操作系统信息、网络信息、旧Agent的配置和运行状态，然后对这些信息进行评估，判断这个节点是否适合迁移，有没有特殊的问题需要处理，比如硬件配置太低、操作系统版本太旧、网络环境太差等。如果有特殊问题，先解决问题，再迁移；如果问题暂时解决不了，就放到后面，等方案成熟了再迁。

第二步：新Agent部署和配置同步

评估通过后，用新Agent自动部署工具，把新Agent远程部署到目标节点上。部署完成后，自动启动新Agent，同时用配置同步工具，把旧平台的配置同步到新平台，让新Agent按照和旧Agent一样的配置运行。

部署完成后，检查新Agent的运行状态，确认它能正常连接新平台，正常上报数据，正常接收任务。如果有问题，排查解决，直到新Agent正常运行。

第三步：双跑验证

新Agent正常运行后，进入双跑阶段，旧Agent继续处理业务，新Agent同步运行，验证功能。双跑期间，我们重点关注几个方面：

  • 连接稳定性：新Agent和新平台的连接是否稳定，有没有频繁断连、重连的情况。
  • 数据一致性：新Agent上报的数据和旧Agent上报的数据是否一致，有没有数据丢失、数据错误、数据延迟的情况。
  • 任务下发：新平台下发的任务，新Agent是否能正常接收，任务内容是否正确。
  • 资源占用：新Agent的CPU、内存、磁盘、网络占用是否正常，有没有影响旧Agent的运行，有没有影响节点上的其他业务。

双跑验证一般持续一到两周，期间如果发现问题，及时排查解决，问题解决后，重新开始计时验证。只有双跑期间所有指标都正常，没有问题，才能进入下一步。

第四步：业务切换

双跑验证通过后，就可以切换业务了。切换的时候，先把旧Agent的业务处理停掉（但不停止旧Agent，保持连接，以备回滚），然后让新Agent开始实际执行任务，这样业务就从旧平台切换到了新平台。

切换是迁移过程中最关键的一步，我们一般选择在业务低峰期进行，比如凌晨或者周末，这样即使出了问题，影响也比较小。切换的时候，有专人监控，一旦发现问题，立即回滚。

切换之后，密切观察新平台的运行情况，包括业务处理是否正常、数据上报是否正常、任务执行是否正常、节点资源占用是否正常，以及业务指标是否正常（比如任务成功率、数据完整率、响应时间等）。一般观察24小时，如果一切正常，就说明切换成功了。

第五步：完成迁移和旧Agent下线

切换成功后，再观察一周左右，确认新平台运行稳定，没有问题，就可以完成这个节点的迁移了。完成迁移的时候，把旧Agent停掉，卸载旧Agent，断开旧平台的连接，释放旧平台的资源。

旧Agent下线后，这个节点的迁移就完成了。然后在迁移管理平台上，把这个节点标记为"已迁移"，记录迁移时间、迁移过程中的问题和解决方案，方便后续跟踪和总结。

四、遇到的问题和解决方案

整个迁移过程中，遇到了各种各样的问题，有些是预料之中的，有些是意料之外的。今天挑几个比较典型的问题，和大家分享一下。

问题1：部分节点网络环境差，新Agent部署失败

我们有一部分节点，部署在比较偏远的地方，网络环境很差，带宽低，延迟高，还经常断网。用远程部署工具部署新Agent的时候，经常部署失败，要么是下载安装包的时候断网，要么是部署过程中连接超时，要么是部署完了连不上新平台。

解决方案：针对网络环境差的节点，我们做了几个优化：

  • 把新Agent的安装包做小，去掉不必要的依赖，压缩安装包大小，减少下载时间。
  • 支持断点续传，下载安装包的时候断网了，重新连接后可以继续下载，不需要从头开始。
  • 支持离线部署，把安装包拷贝到U盘或者本地，在节点本地手动部署，部署完之后再连接新平台。
  • 增加重连机制，新Agent连接新平台的时候，如果网络断了，自动重连，指数退避，不会因为网络波动就一直连不上。
  • 对于网络特别差的节点，我们采用了专网或者VPN，提升网络稳定性，保证迁移和后续运行的稳定。

通过这些优化，网络环境差的节点也能顺利完成迁移了。

问题2：部分老旧节点硬件配置低，新Agent跑不起来

我们有一部分老旧节点，是很多年前部署的，硬件配置很低，CPU是低端的双核，内存只有1G或者2G，磁盘也很小。新Agent因为功能更多，资源占用比旧Agent高一些，在这些低配节点上跑起来很吃力，CPU占用率很高，内存不够用，甚至出现了OOM（内存溢出）的情况，影响了节点上的其他业务。

解决方案：针对低配节点，我们做了几个优化：

  • 开发了轻量版的新Agent，去掉了一些非核心功能（比如本地数据缓存、高级日志、远程调试等），减少资源占用。轻量版Agent的CPU和内存占用，和旧Agent差不多，能在低配节点上流畅运行。
  • 支持功能模块化，节点上可以根据硬件配置，选择性地启用功能，低配节点只启用核心功能，高配节点可以启用全部功能，灵活适配不同的硬件配置。
  • 优化资源占用，对新Agent的代码进行了性能优化，减少不必要的内存分配和CPU计算，降低资源占用。
  • 对于实在太老、配置太低的节点，和业务方沟通，评估是否需要升级硬件，或者淘汰这些节点，用新的节点替代。

通过这些优化，大部分低配节点都能顺利运行新Agent了，少数实在太老的节点，也通过升级硬件或者淘汰替换的方式解决了。

问题3：双跑期间数据重复，影响业务统计

双跑期间，旧Agent和新Agent同时采集数据，分别上报到旧平台和新平台，这本来是没问题的。但有一部分业务，数据上报后会触发后续的处理流程（比如告警、统计、报表），双跑期间，两个平台都收到了数据，都触发了处理流程，导致数据重复统计，告警重复发送，影响了业务。

解决方案：针对这个问题，我们做了几个处理：

  • 在新平台侧，双跑期间，新Agent上报的数据只做验证，不触发后续的处理流程（告警、统计、报表等），只是把数据存下来，和旧平台的数据做对比，验证数据一致性。等业务切换到新平台后，再开启后续的处理流程。
  • 对于一些必须实时处理的数据，在数据里加一个标记，标识是来自旧平台还是新平台，后续处理流程根据标记，只处理旧平台的数据，忽略新平台的数据，避免重复处理。
  • 业务切换的时候，选择在数据量少的时间点（比如凌晨），切换的时候暂停一下数据处理，等切换完成后再恢复，避免切换瞬间的数据重复或者丢失。

通过这些处理，双跑期间的数据重复问题得到了解决，没有影响业务统计和告警。

问题4：部分节点操作系统特殊，新Agent不兼容

我们有一部分节点，用的是比较特殊的操作系统，有的是定制化的Linux发行版，有的是很老的内核版本，有的是Windows系统，还有的是ARM架构的设备。新Agent一开始只支持主流的x86架构的Linux系统，在这些特殊操作系统的节点上，要么安装不上，要么运行报错，兼容性有问题。

解决方案：针对兼容性问题，我们做了几个工作：

  • 扩展新Agent的支持范围，陆续适配了不同架构（x86、ARM、MIPS）、不同操作系统（主流Linux发行版、定制化Linux、Windows）、不同内核版本的环境，让新Agent能在各种节点上运行。
  • 采用静态编译的方式，把新Agent编译成静态链接的可执行文件，不依赖系统的动态库，减少对操作系统环境的依赖，提高兼容性。
  • 对于实在太特殊、无法适配的节点，和业务方沟通，评估是否可以更换操作系统，或者用其他方式（比如容器化）来运行新Agent。

通过这些工作，大部分特殊操作系统的节点都能顺利运行新Agent了。

问题5：迁移过程中，部分节点旧Agent意外停止，导致业务中断

迁移过程中，有几次出现了意外情况：在部署新Agent或者切换业务的时候，因为操作失误或者脚本bug，导致旧Agent意外停止了，而新Agent还没开始处理业务，出现了短暂的业务中断。虽然时间不长，影响也不大，但这是不应该发生的，违反了我们"业务不中断"的原则。

解决方案：针对这个问题，我们做了几个改进：

  • 完善迁移工具的安全性，所有操作都加了校验和确认，避免误操作。比如停止旧Agent之前，先检查新Agent是否正常运行，是否已经开始处理业务，如果新Agent没有准备好，就不允许停止旧Agent。
  • 增加旧Agent的守护进程，旧Agent如果意外停止了，守护进程会自动拉起它，保证业务不中断。只有在确认新Agent正常运行、业务已经切换之后，才会停止守护进程，允许旧Agent下线。
  • 迁移操作都在业务低峰期进行，并且有专人监控，一旦出现业务中断，立即回滚，把影响降到最低。
  • 对迁移脚本和工具进行了充分的测试，在测试环境反复验证，确保没有bug，再用到生产环境。

通过这些改进，后面的迁移过程中，再也没有出现过旧Agent意外停止导致业务中断的情况。

五、经验总结

整个迁移过程完成之后，我们做了一次详细的复盘，总结了一些经验教训，在这里和大家分享。

1. 迁移方案设计是关键，一定要充分调研和论证

边缘计算迁移，复杂度高，风险大，迁移方案的设计是关键。在设计方案之前，一定要充分调研，了解每个边缘节点的情况（硬件、操作系统、网络、业务），了解旧平台和新平台的差异，了解业务的特点和要求，然后基于这些信息，设计合理的迁移方案。方案设计好之后，要充分论证，多和团队成员、业务方讨论，考虑各种可能的情况和风险，制定对应的预案。不要急于开始迁移，方案设计得越充分，迁移过程就越顺利。

我们这次迁移，之所以能比较顺利地完成，很大程度上是因为方案设计得比较充分，双跑过渡、分批迁移、可回滚、自动化这些原则和方案，在迁移过程中发挥了很大的作用。

2. 自动化工具很重要，能大大提高效率，降低风险

两百多个节点，如果靠人工一个个迁移，不仅效率低，而且容易出错，风险很大。开发一套自动化的迁移工具，虽然前期需要花一些时间和精力，但能大大提高迁移效率，降低人工操作的风险，是非常值得的。

自动化工具不只是部署工具，还包括信息采集、配置同步、状态监控、回滚等，覆盖迁移的整个流程。工具越完善，迁移就越顺利，人为失误就越少。我们这次迁移，迁移工具发挥了关键作用，如果没有这套工具，两个月内完成两百多个节点的迁移是不可能的。

3. 分批迁移，循序渐进，控制风险

边缘计算迁移，不要急于求成，不要一次性迁移所有节点，一定要分批迁移，循序渐进。先迁少量的、非核心的节点，验证方案和工具的可行性，积累经验，发现问题，解决问题，然后再逐步扩大范围，最后迁核心节点和特殊节点。每批之间留足够的观察时间，确认没问题了再迁下一批。

分批迁移的好处是风险可控，出了问题影响范围小，而且能在迁移过程中不断优化方案和工具，让后面的迁移更顺利。我们这次分了五批，每批之间间隔一周，虽然整体时间长了一些，但整个过程很平稳，没有出大的问题。

4. 双跑过渡是保证业务不中断的有效方式

双跑过渡，虽然复杂一些，需要同时运行两个Agent，资源占用也高一些，但能最大程度地保证业务不中断，让新平台在不影响业务的情况下充分验证，是非常稳妥的方式。对于边缘计算这种对业务连续性要求高、节点环境复杂的场景，双跑过渡是很值得的。

双跑期间，要充分验证新平台的各项功能，包括连接稳定性、数据一致性、任务下发、资源占用等，不要急于切换业务。只有双跑期间一切正常，才能切换业务。切换之后，也要观察足够长的时间，确认稳定了，再下线旧平台。

5. 回滚方案一定要提前准备，并且测试验证

迁移过程中，难免会出现问题，回滚方案是最后的保障，一定要提前准备，并且在测试环境充分测试验证，确保出了问题能快速、准确地回滚，把影响降到最低。

回滚方案不只是技术方案，还要包括操作流程、责任人、沟通机制等，确保出了问题的时候，大家知道该怎么做，谁来做，怎么沟通，不要手忙脚乱。我们这次迁移，每次切换业务的时候，都有专人负责回滚，一旦发现问题，立即回滚，虽然没有用到几次，但这个准备是必须的。

6. 充分考虑边缘节点的差异性，不要想当然

边缘节点最大的特点，就是差异性大，硬件、操作系统、网络、运行环境，各种各样，不要想当然地认为所有节点都一样，更不要用统一的标准去要求所有节点。在迁移方案和工具的设计上，要充分考虑这种差异性，支持不同的硬件、操作系统、网络环境，灵活适配不同的节点。

我们这次迁移，遇到的很多问题，都是因为边缘节点的差异性导致的，比如网络环境差、硬件配置低、操作系统特殊等。这些问题，在方案设计的时候就要考虑到，提前准备好应对方案，不要等遇到了再临时想办法，那样会很被动。

7. 和业务方充分沟通，取得理解和支持

边缘计算迁移，不只是技术团队的事情，还涉及到业务方，因为迁移过程中可能会影响业务，需要业务方配合。在迁移之前，要和业务方充分沟通，说明迁移的目的、方案、时间安排、可能的影响，取得业务方的理解和支持。迁移过程中，及时同步进度，有问题及时沟通，不要让业务方蒙在鼓里。

我们这次迁移，一开始就和业务方做了充分的沟通，制定了详细的迁移计划，明确了每批迁移的时间和节点，业务方也很配合，在迁移期间安排了专人对接，有问题及时沟通。整个迁移过程中，业务方的理解和支持，是我们能顺利完成迁移的重要保障。

六、写在最后

这次边缘计算迁移，从方案设计到全部完成，持续了将近两个月，整个过程可以说是既紧张又充实。紧张的是，边缘节点环境复杂，迁移过程中随时可能出问题，精神一直绷着；充实的是，通过这次迁移，我们不仅完成了平台的升级换代，还积累了很多边缘计算迁移和运维的经验，团队的技术能力也得到了提升。

边缘计算是未来的趋势，越来越多的业务会从云端延伸到边缘，边缘节点的数量会越来越多，规模会越来越大，边缘计算的迁移、运维、管理，也会成为越来越多团队面临的问题。希望我们这次迁移的经验和教训，能给正在做或者将要做边缘计算迁移的朋友一些参考，让你们少踩一些坑，少走一些弯路。

最后，总结一下边缘计算迁移的几个关键点：充分调研，方案先行；自动化工具，提高效率；分批迁移，控制风险；双跑过渡，保证业务；回滚预案，有备无患；考虑差异，灵活适配；沟通业务，取得支持。做到这几点，边缘计算迁移就能比较顺利地完成。

希望大家的边缘计算迁移，都能顺顺利利，少踩坑，多收获。