序

在项目重构指南中，有一部分关于数据源迁移的总结，当时其实也涉及到了服务的迁移，但是当时由于服务迁移并不是高优先级的任务，故而忽略。

迁移方案

迁移可以简要分为数据源迁移、服务迁移。迁移方案主要是事前、事中、事后，对应着可监控、可灰度、可回滚。事前做好数据备份和迁移方案，迁移方案一定是围绕”可监控、可灰度、可回滚“进行的，事中做好平滑迁移，事后做好监控。数据源迁移和服务迁移的迁移过程大体一致，但还是有一些细节不一致。比如：数据源迁移更担心的是数据不一致问题，而服务迁移更多的重点放在流量对服务的灰度迁移预测。

在业务中可以从生产和消费两种角度来了解，生产是数据增量，而消费是消费存量数据。而生产和消费是业务逻辑，实施对象是数据，因此整体业务落地到服务和数据源。 迁移指的就是对业务的迁移，所以可以大致分为服务迁移和数据源迁移。

1. 数据源迁移

数据源迁移的过程中主要在意两点：1. 数据一致性；2. 数据时效性。数据一致性是迁移方案的重中之重，数据时效性这一点是业务需要，需要去和产品业务多方对齐，业务能接受的数据时效性，因为数据迁移有时间成本，故而要和业务方确认它们能接收的数据时效性，这一块的经验就是沟通，沟通技巧很重要，目前没有太多实战经验，。

数据源迁移重点就在数据一致性，数据一致性，就在于读写一致性，那迁移的时候就要从读写入手。
步骤网上有很多，项目重构指南中的第二部分也总结了一下，数据源的迁移方案可以从事前、事中、事后来分析，事前是数据备份，事后是数据回滚监控，而事中是需要做准备最多的地方。
事中主要是为了保障数据的平滑迁移而做的准备，整体步骤如下：

1. 同步：首先是要保证数据源的准确和一致性，所以要先讲存量数据源迁移到新库，也就是数据同步的过程；
2. 双写：之后是增量数据的同步过程，也就是双写过程；
3. 双读：双写保证了写一致，那下一步就是要保障读一致，所以我们要双读，双读的话，就是要从新库中读数据，且验证和旧业务的读是否数据一致性，因为此过程对旧业务并无影响，所以不用灰度；
4. 切读：以上保证了新数据源的读写，这是迁移工作的前提准备，然后开始真正的迁移，因为迁移会导致数据的不一致或者乱写，所以我们要最大程度降低这个风险，读接口对服务的影响最低，所以先开始切读，切读的时候因为新数据源本身的稳定性需要考虑，所以流量是否会对新服务造成一些性能或者其他影响都还待考量，所以切读的时候要灰度。
5. 切写：写接口的话，虽然前面已经验证了数据的一致性，但是以防万一，所以这一步我们最好是配置监控，实时监控，有异常及时告警，先止损。

2.服务迁移

2.1 前端接口迁移

在迁移前端接口的过程中，需要考虑到服务中是否已配置了Nginx作为负载均衡器，因此需要确保Nginx的配置相应地迁移或更新，以确保前端接口能够正确地通过Nginx进行路由和分发。这里可能还会有一个事前准备是其他没有的：调研平台，了解平台的用法。

1. 事前：
   1. 调研：从0到1的过程是最为珍贵的，因为1-n的过程是迭代，而0到1是探索。摸着石头过河，毫无章法。所以事前的调研在最开始的时候是最重要的，可以慢慢帮助我消除盲区，但是调研的时候最忌讳细节，深度的挖深和横向的探索需要得到平衡。最开始调研的时候可能只有几个关键字，所以整体的知识框架一定搭建不起来。这时候要根据目的反推现在的行为，以始为终，整体的脉络会比较清楚。以迁移为例，为需要调研enginx的用法，最终目标是在enginx平台上迁移Proxy服务，所以我们只需要了解如何迁移到新服务上，原接口和现接口的一致性如何保证，如何验证？
   2. 制定迁移方案：
      1. 现状了解:
         1. 统计新旧迁移接口的情况
         2. 新旧接口在平台中的配置
      2. 评估迁移收益
         1. 接口迁移一定是区分优先级的，如何定义优先级的同时，其实也是在评估迁移收益，迁移哪个迁移收益最高，要做好平衡。
      3. 迁移可实施性：迁移的过程是新旧服务之间的迁移，因为当下的旧服务正常运行，所以要验证新服务的链路正常，新旧服务之间的链路正常之后，再去验证旧服务转新服务。
         1. 新服务的链路验证
         2. 旧服务转新服务的中间链路保障：
            1. 可监控：北斗监控
            2. 可灰度：enginx的灰度是自动化的，先灰5%，停五分钟；然后灰20%，停五分钟，之后全量。
            3. 可回滚：enginx的回滚是直接删除配置，相当于重新部署。
2. 事中：
   1. 接口配置发生改动之后需要及时观察监控，看实际的监控和预期是否一致。当然预期结果一定要在事前的方案中就要思考到，切不可当场思考。
3. 事后：
   1. 迁移之后要观察一段时间，查看服务是否正常，是否可以缩容等。

2.2 后端服务接口迁移

后端服务接口迁移的时候，走的是thrift协议，所以对后端服务接口迁移更注重的是协议的一致性、数据的一致性。
协议一致性指的是字段和数据结构的一致性。而数据一致性指的是业务内部处理和数据源的一致性。
后端服务接口迁移的具体步骤是：

1. 事前
   1. 制定迁移方案：
      1. 现状了解：旧接口的QPS、响应时间等；
      2. 评估迁移收益
      3. 迁移可实施性：
         1. 新接口的链路验证
         2. 旧服务转新服务的中间链路保障：
            1. 可监控：北斗
            2. 可灰度：设置灰度开关，和整体迁移开关。灰度量控制尽量控制在成倍增长。
            3. 可回滚：云效
2. 事中
   1. 观察监控，看CPU的水位是否可以抗住，及时扩容或者回滚。
3. 事后
   1. 迁移之后要观察一段时间，查看服务是否正常，是否可以缩容等。

综上所述，迁移方案制定围绕的中心就是保障新旧服务的可用性和迁移过程中的可监控、可灰度和可回滚。