一、前言

---

应用迁移，可能很多人都会遇到过这一个场景，无论是传统应用迁移至k8s，还是应用的跨可用区迁移。对于开发测试环境来说，这种不涉及生产业务性的环境，对于我们来说，可能很容易，一旦涉及到生产环境，我们就要考虑在迁移过程中应用的可用性，如果业务可接受中断，那么也会简单些，如果应用不能中断，则就需要考虑很多事情，根据不同的业务系统架构，以及业务系统的复杂性，可能需要的方案也是不一样，我这里主要探讨的是生产环境平滑迁移的步骤及思考。

二、为什么迁移

---

说到迁移，可能对于不同部门的人，所思考的问题是不一样的，我这里只说个人观点，并不代表任何人意见。对于运维执行(大多是新员工)着来说，可能是比较倾向于折腾，一来可以熟悉业务系统架构，二来迁移迁移过程也能学习到更多的运维技能，如果是涉及应用到迁移至k8s，那么对于运维来说，不但后面维护比较方便，可能对于自己来说也是一种机会，毕竟现在k8s已经是一个标准的交付方案，会k8s也 变成运维的一个必备技能。

对于开发部门来说，可能大多是不同意迁移，因为迁移不仅涉及到系统的不稳定性，而且还会涉及到很多的修改，例如,第三方白名单，第三方url接口地址等，这些都会徒增开发的工作量。

所以我们就要搞清楚，业务为什么迁移？如果是强制性的，比如都是在云环境，云商当当前可用区网络调整，不得不迁移，那么就没办法，只能乖乖的做好迁移规划准备；如果是为了保证架构适应当前流行技术栈，则需要考虑下是否值得迁移，如果确定迁移，也要做好迁移前的准备工作。

三、迁移方案

---

迁移方案，其实说的通俗点就只有两种，平滑迁移和复制迁移。

• 复制迁移: 在现有环境之外，搭建一套一模一样的环境，然后测试通过后，直接把流量切至新环境。
• 平滑迁移: 在现有环境之上，应用及中间件足部迁移，流量慢慢过渡。

复制迁移，相对来说比较直接干脆，当然风险也是最大的，因为新环境，工作量也是最大的，平滑迁移相对来说风险点比较小，当然耗时比较长，一般取决于结构的复杂性，具体我们往下分析。

四、应用迁移至k8s集群

---

这里迁移都是以平滑迁移为基础，关于环境复制迁移，这里不展开讨论。

4.1 迁移前置工作准备

• 梳理使用技术栈

  • Jenkins
  • Docker/jar包
  • ansible
  • Prometheus

• 数据库中间件

  • RDS
  • Redis
  • Mongodb
  • ....

• 消息注册类中间件

  • nacos
  • zk
  • kafka
  • apollo
  • .....

• 域名

  • 内网域名
  • 外网域名
  • 网关域名
  • ....

• 网络

  • 服务器网络
  • 中间件网络

• 白名单

• ....

迁移前梳理业务架构系统所使用资源，不仅有有助于我们做出更好的平滑迁移方案，也可以在迁移过程出现问题时可以快速定位问题点。

4.2 迁移规划

迁移规划，其实也是迁移步骤，就是我们根据自己梳理的系统资源，去评估资源的迁移优先级。

• 网络规划

  • 网络互通: 应用及其他资源迁移钱我们首先要做的就是规划网络，这里网络不仅是新环境的各种资源网段的划分，也要考虑一个点就是，新环境的网络需要与旧环境网络保证网络的互通。比如，如果是vpcA --> vpcB,我们可以使用VPC对等链接 (opens new window)或者使用vpc NAT网关 (opens new window),也可以使用云企业网 (opens new window)来保证2个vpc之间的内网互通。如果是阿里的经典网络迁移至vpc网络，我们使用ClassicLink (opens new window)打通网络即可。这样我们才能做到平滑迁移的一个前提。
  • 新环境网段: 包括应用pod网段，node网段，云中间件网段、自建中间件网段、云数据库网段等等，处于规范下，我们把一类的资源都划分到一个网段中，这样不至于后面加白名单时，出现一个网段中有多种类型的应用
  • 新环境出口IP: 统一出口IP，方便我们访问外部第三方应用时，直接添加白名单，机器没有外网IP，安全性也更高一些。

• 中间件迁移规划

  • 数据库相关: 数据库如果涉及到迁移，则可以使用阿里的DTS (opens new window)，进行数据的迁移，然后根据业务特性看是否允许双向同步
  • 小象中间件: 大多消息都是生产者消费者模型，我们可以搭建新的环境，然后根据生产者消费者消费情况择机切换至新环境即可，如果涉及到zk、kafka、nacos等中间件，可以直接使用MSE Sync白屏化迁移工具 (opens new window)进行数据的双向同步迁移。

• 域名迁移规划

  • 内网域名: 我们一般使用阿里的clb或者其他的负载均衡进行代理，如果有其他应用也是使用slb代理进行互相访问，这里建议改造下应用的路由方式，因为如果大多都依赖外部负载，则我们可能维护的端口映射比较多，我们可以考虑使用nacos或者其他的注册中心，应用注册后，通过注册中心进行路由，这样我们只需要暴露一个网关即可。
  • 外网域名: 外网一般就是api网关，或者特定的应用，对于域名迁移肯定是分成不方便，因此我们这里，我们可以新增一个域名，把旧的域名代理至新的域名，这样客户端无感知，也可以通知调用方更换新域名，或者测试无误后直接修改域名至新环境，这个要根据实际情况与开发机第三方沟通后操作。

• 应用迁移规划

​ 我们知道，后端应用相对来说都属于无状态，因此迁移相对来说比较简单，我们直接发布至新的集群即可，这里就需要我们先把上一步域名的迁移规划好之后，这样应用的迁移就只是剩下发布即可

4.3 迁移实施

上面我们按照评估把优先级定下来之后，就可以有序进行操作，当然我们在实际操作过程中，也需要去评估每一步对应用的影响性，尽量做到有问题可以快速回滚，把影响时间降到最低。对于生产的迁移，实际过程往往比这些更加复杂，但是只要我们一步一步去梳理，做好规划按照步骤，评估风险性，就会把复杂的迁移做的简单化。

五、总结

---

上面是基于阿里云的云环境，只是一个迁移的大概缩影，具体的迁移步骤可能比这些考虑的要更多，而且不同云环境可能使用的工具也不一样。之说以花时间写这篇文章，只是为了记录下自己迁移过程的一个总结，也是想表达平滑迁移的可行性。目前工作将近8年，所经历的大的生产迁移有4次：

• 传统微服务迁移至docker swarm

• 经典网络集群应用迁移至vpc网络集群应用

• vpc网络-传统docker部署迁移至k8s集群

• 经典网络-传统docker部署迁移至vpc网络k8s集群