2018-2-4 项目迁移总结---杭州

合抱之木,生于毫末；九层之台,起于垒土；千里之行,始于足下。-----------送给在码农之路上搬砖的自己。

本次迁移所能够设想到的内容，以后迁移方案可以按照这个步骤来：

1>券包迁移方案需要满足的要求：
1)daily／gray上发布，因为无法保证一次将优惠券移到另一个trade不会发生问题，尽量以接口或接口部分流量为单位进行迁移则可以大大降低出错率。
2)客户端无感知，平滑迁移，系统长时间不可用是无法接受的。
3)可回滚，一旦出现异常问题可以快速回滚，避免造成较大影响。必须有回滚方案。
4)易实现，尽量避免大量地操作，操作多意味着犯错的可能性更大，回滚的难度也大，在风险可控的情况下选择最优最易实现的方案。
5)数据校验，迁移方案确定之后，功能都能够实现，对线上环境最重要的是 线上数据迁移之后进行的数据校验确保 迁移前后数据一致。

2>数据库部分需要满足的要求：
1)建新表尽量建新表以避免对老数据的破坏。
2)假如需要减字段，那么请考虑临时替代的方案，比如新建一张临时表，让程序先取临时表数据，最后等新表建立后再切换过来，导入数据。
3)CACHE等需要序列化，反序列化的部分。一定要兼容原先在缓存中的数据，例如SID千万不要变化，否则反序列化失败，假如有字段需要增加，那么考虑第一次读入先取数据库。
4)外部接口相关的，能不要求外部接口联调，尽量就不做联调，一是麻烦，二是风险大。尽量对原接口传入和传出的数据保持兼容。假如有变化，考虑用适配器封装，实在没办法再实行下策。
5)注意操作的先后顺序，这个也是非常重要，例如你先发了数据库，但是程序还是老的，并且会受到影响，那么就挂了。

3>优惠券迁移方案的详细流程：

 1>本次迁移设计到哪些项目／模块／功能

2>本次迁移设计的controller层

3>迁移设计到的service

4>设计到数据库表

5>兼容老的服务接口

6>dubbo服务的更新

7>发布，根据易现实性，在风险可控的情况下选择最好发布线上的设计

 7.1>线上发布在保证数据准确性下的具体流程。设计到nginx的请求重定向等等。

7.2>nginx流量的跳转控制等

总结：这次优惠券的迁移花了一周的时间，跟CTO对过之后，在具体的迁移过程中没有对着自己所列的注意事项一项一项迁移，导致发布gray的时候dubbo／service都没有更新，许多dto都是使用jar包上的，也没有迁移。导致时间往后delay了3天。还有许多小细节自己也没有处理好，处理问题缓慢等原因。

 以后遇见迁移的问题可以直接往上面套，不仅仅是迁移一次就完了，以后再次需要迁移就是从1-->n的而不是还是从0-->1的过程。