背景
迁移了一年，这话真的丝毫没有夸张~
1、从2018年底开始从阿里的HSF迁移到SpringCloud，全面拥抱Spring开源框架；
2、然后就是项目组上海、北京、深圳的项目交接，全部由深圳这边来做业务；
3、后面就是全平台的迁移与整合，包括代码、中间件、数据库、网络等；
4、包括中途发布系统迁移了3~4次，网络从阿里云的经典网络迁移到阿里云的VPC网络；
做这一切都是为了（降本增效）：提高我们的对接效率，节约我们的成本，对接的人员更加的专业与熟练。我个人觉得做这些还是挺有意义的，只是要尽快的结束掉。
项目如何迁移？
如何建设一个标准统一平台？
配置中心
错综复杂的业务以及以前一些”坑爹“的特殊处理，你想实现平台大统一。谁都是知道是一件很不容易的事情。你系统的包容能力、可拓展能力真的要很强。那如何去实现这些呢？毫无疑问：一套给力的配置中心是少不了的？
方案一：采用MySQL + Redis的方式
优点：以MySQL关系型数据库做基础，用Redis作为缓存提高吞吐。数据库中的配置保持着简单明了，只存储关键节点，一般情况就是Yes or No，再就是具体的值，每次变更完后立马刷新到缓存即可。
缺点：Redis的方式只能通过客户端的拉取，每次修改都要伴随着一个人工或者手动触发的动作。
方案二：采用Zookeeper + MySQL的方式
优点：利用Zookeeper的方式存储数据，能够保证高可用性以及消息能主动推送的效果，然后用MySQL来做降级。
缺点：类似Zookeeper、Diamond的配置中心，是失去关系型查询的能力以及要处理好代码与配置的更新先后顺序。
系统编排
业务、原子能力可编排已经成为搭建中台、平台不可缺少的能力？这是更好的复用底层的最好方式。
方式一：责任链编排
一个比较复杂的业务需要通过好几个系统才能完成。比如：一个还款业务需要贷前、贷中业务的支撑才能保证还款业务的正确执行，起码要经过贷后业务、贷中业务、贷前业务、下游系统等子模块的调用才能把还款计划给冲销掉。
贷前业务：Handler4
贷中业务：Handler2、Handler3
贷后业务：Handler1、Handler5
下游系统：Handler6
那么该条业务就是根据某个产品独特的业务特性来编排的：Handler1→Handler2→Handler3→Handler4→Handler5→Handler6。
优点：从配置上能够很清晰的看出一个业务的逻辑，并且非常的灵活。其中router-convert-in、router-convert-out、handler-convert-in、handler-convert-out就是一层代理，可以在入口以及每一个原子服务的前后都能做一些事情。
缺点：太灵活，导致没有标准，什么都能做。配置量巨大，对于后期的维护不太友好。
方式二：配置中心
每个系统的边界是非常清晰的，因为都是接口来提现你的能力。每个服务接口都要自己保证自己的完整性与一致性。至于某一个业务具体走了多少个Handler是要看产品的配置。
优点：系统能力清晰，边界清晰，代码可读性强。配置小，基本就是Yes or No，再就是一些具体的变量值。
缺点：不够灵活，每一次的功能叠加与优化，都需要走发布流程才能完成。
格转功能
其实格转这个我们在哪儿都需要，有一段时间在Java的MVC模式下，每一层的数据转换差点就怀疑人生了。其实分层或者叫fullstack的思想都是有它的道理的。每个团队都有他特有的约定或者行业约定，只要大家认可就好，在同一个约定下开发才能你快乐我也快乐。
- Setter 与 Getter
- BeanCopy
- @Annotation
- 一些自定义格转框架
用格转的时候，应该从方便性、可维护性、性能方面去考虑，就看你侧重与哪一点？
数据迁移
项目前期分析
项目迁移最重要的就是一个风险的评估，需要对之前的系统以及新的系统的差异点要非常的清楚，否则可能会出现盲点造成生产故障。数据迁移一般只包括存量的数量，新增的数据将会在系统层面提现。如果遇到数据量大，而且分库分表逻辑不一致的时候，就会出现很多的问题。
- 对于没有数据要按照一定的规则生成
- 缺少对应关系的需要建设映射关系…等
数据量的评估
对于每一张表的一个条数、物理磁盘空间占用等的评估。对于后面迁移的瓶颈在哪儿有一个大概的评估。
表映射关系
- 部分字段需要特殊转换
- 多个表写入一张表
- 一张表写入多张表
这里的细节取决与对于2个系统之间的了解，都要在前期做很细的规划与考量。
迁移框架开发
对于迁移功能或者框架的要求需要做到如下才行：
- 可回滚：全量回滚，单笔删除
- 可重试：回滚重试、不回滚重试
- 可校验：提供校验入口，输出校验结果
- 时效性：一定的时间内，完成迁移、校验动作
- 可控制：写入速度控制、可暂停、可强制停止
- 可视化：进度条、耗时、速率~
其中迁移最重要的就是Reader与Writer，但大部分都是在写这里出现了性能问题。达不到迁移时间上的要求导致失败或者特殊处理。
Reader:
- 分页查询，尽量能按照固定顺序来读；
- 建议好索引，避免出现数据库底层的性能问题，提前分析加上好索引；
- 部分数据可以加载在内存里里面，在内存里进行包装；
Writer：
- 最好是利用并发来写数据，注意好线程安全；
- 尽量把不同的表数据打散开来，提高数据库的并发；
- 能批量操作的就批量操作，不要一条条的操作，减少网络的开销；
- 注意好事物的回滚操作与日志监控
业务验证
- 对于迁移的数据可验证，最好能做成自动化的验证功能
- 对于异常数据把补偿功能提前做好
- 提前做好回滚的方案
指标&异常考虑
- 可回滚：全量回滚，单笔删除 – 支持以物理表维度全量回滚
- 可重试：回滚重试、不回滚重试 – 支持，建议采用回滚重试
- 可校验：提供校验入口，输出校验结果 – 支持
- 时效性：一定的时间内，完成迁移、校验动作
- 可控制：写入速度控制、可暂停、可强制停止 – 通过写线程、部署服务数量来控制速录， 支持暂停服务 TaskScheduler
- 可视化：进度条、耗时、速率 – 抽样打印插入耗时， 支持打印进度条、打印内存占用率、cpu等
总结
真的没有最厉害的系统，只有最合适的系统。不要过度设计、过度设计、过度设计。每一个设计一定是为了解决某种恶心问题来设计的，它可能解决了最恶心的问题但是也附带了它的问题。首先要去任何架构师的设计，其余的问题就是去耐心解决就好。
如果大家喜欢我的文章，可以关注个人订阅号。欢迎随时留言、交流。
