1. 我认为的业务迁移
在我有限的工作经验里，业务迁移到新的服务很简单，之前调用旧接口，只需要将旧接口切换到新的接口，然后能够保证接口调用的正确性，就可以进行上线了。想当然的认为其它的我也控制不了，下游接口的成功率是下游的事情，不需要管，我只需要调通新接口就可以了。这其实非常不负责任的想法，本质上讲是懒惰，只想完成迁移新接口这件事情，其他的不想管，其实其它方面的关注要比迁移本身难多了。
2. 迁移应该注意什么问题？
-
工程打平
所谓打平，就是迁移前和迁移后在工程的变化是一致的。即迁移前后的接口延时不能变化，本质上讲就是qps不发生变化，其次是下游接口的错误率不能因为你的迁移发生变化。
-
业务打平
业务打平，更多的是在业务收益上不发生变化，如果有提高会更好。举个例子，如果这条业务线每天创造的收入是1万元，那前一之后也应该在1万左右。当然这个1万元不是固定的，每天都有波动，那迁移之后，怎么才能算是在正常的波动范围之内呢？这个通过做实验可以验证，比如迁移前波动范围是1千左右，那你迁移之后也应该1千左右。这一点是很多刚毕业的学生经常容易忽略的。
3. 我在迁移过程中遇到了什么问题，怎么解决的？
-
新旧服务调用了下游的同一个接口，为啥延时差别很大？
从监控上看，新服务调用的接口比老服务延时长了很多，在想调用的方式上有什么区别？除了调用的框架不一样，不同的框架有可能调用下游RPC延时，但是不至于差别这么大。所以重点来了，我想当然的认为因为下游的流量调度不一致带来的，因为下游有三个集群，之后花了大量的时间，去调整对每个集群的访问比例，比如A、B、C三个集群被旧服务调用的比例是3:3:4，然后新的服务调用也去靠近这个比例。最后延时仍然相差很大，当然这部分还包括了机房的调用比例调整。**这部分浪费了很长时间，都是基于我认为对下游调度改变带来的，但最终也没有解决。** -
新旧服务调用下游的同一个接口，为啥qps也不符合预期？
在进行迁移的时候，将一般的流量打到了新的服务中，所以理论上对下游的调用qps应该和旧服务保持一致的，但观察监控发现，新服务的qps要高，所以这个时候去检查代码发现，新服务进行了retry，所以新服务的qps很高，改正之后qps符合预期了。 -
qps符合预期之后，延时仍然不符合预期？
有了经验之后，首先去检查了代码，发现旧服务的超时时间是200s，但是新服的超时时间是500s，而下游大部分的处理时间是超过200s的，监控中新服务的延时要高的，修改代码后就fix掉了。
-
如何验证业务上是否打平？
首先将10%-20%的流量迁移到新服务，用于验证工程上是否能够打平，当工程的延时、错误率和qps等能够打平之后，进而放开流量。比如放到50%，这个时候需要观察的时间要长一些，时间长了才能保证业务上都是平的。
4. 我的收获
-
提高自己的积极性，不要认为迁移接口是个小事儿。
-
遇到不符合预期的地方，要多看监控和日志，最重要的是要看代码，不要将原因想当然。
-
不要急于完成某个需求，一定要保证质量。
关注我，让我们一起成长。
