平台迁移与整合那些事儿?

背景

迁移了一年,这话真的丝毫没有夸张~

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的配置中心,是失去关系型查询的能力以及要处理好代码与配置的更新先后顺序。

http://static.cyblogs.com/WX20200113-171033.png

系统编排

业务、原子能力可编排已经成为搭建中台、平台不可缺少的能力?这是更好的复用底层的最好方式。

方式一:责任链编排

一个比较复杂的业务需要通过好几个系统才能完成。比如:一个还款业务需要贷前、贷中业务的支撑才能保证还款业务的正确执行,起码要经过贷后业务、贷中业务、贷前业务、下游系统等子模块的调用才能把还款计划给冲销掉。

贷前业务:Handler4

贷中业务:Handler2Handler3

贷后业务:Handler1Handler5

下游系统:Handler6

那么该条业务就是根据某个产品独特的业务特性来编排的:Handler1→Handler2→Handler3→Handler4→Handler5→Handler6

http://static.cyblogs.com/WX20200114-091359.png

优点:从配置上能够很清晰的看出一个业务的逻辑,并且非常的灵活。其中router-convert-in、router-convert-out、handler-convert-in、handler-convert-out就是一层代理,可以在入口以及每一个原子服务的前后都能做一些事情。

缺点:太灵活,导致没有标准,什么都能做。配置量巨大,对于后期的维护不太友好。

方式二:配置中心

http://static.cyblogs.com/WX20200114-092931.png

每个系统的边界是非常清晰的,因为都是接口来提现你的能力。每个服务接口都要自己保证自己的完整性与一致性。至于某一个业务具体走了多少个Handler是要看产品的配置。

优点:系统能力清晰,边界清晰,代码可读性强。配置小,基本就是Yes or No,再就是一些具体的变量值。

缺点:不够灵活,每一次的功能叠加与优化,都需要走发布流程才能完成。

格转功能

其实格转这个我们在哪儿都需要,有一段时间在Java的MVC模式下,每一层的数据转换差点就怀疑人生了。其实分层或者叫fullstack的思想都是有它的道理的。每个团队都有他特有的约定或者行业约定,只要大家认可就好,在同一个约定下开发才能你快乐我也快乐。

  • Setter 与 Getter
  • BeanCopy
  • @Annotation
  • 一些自定义格转框架

用格转的时候,应该从方便性、可维护性、性能方面去考虑,就看你侧重与哪一点?

数据迁移
项目前期分析

项目迁移最重要的就是一个风险的评估,需要对之前的系统以及新的系统的差异点要非常的清楚,否则可能会出现盲点造成生产故障。数据迁移一般只包括存量的数量,新增的数据将会在系统层面提现。如果遇到数据量大,而且分库分表逻辑不一致的时候,就会出现很多的问题。

  • 对于没有数据要按照一定的规则生成
  • 缺少对应关系的需要建设映射关系...等
数据量的评估

对于每一张表的一个条数、物理磁盘空间占用等的评估。对于后面迁移的瓶颈在哪儿有一个大概的评估。

表映射关系
  • 部分字段需要特殊转换
  • 多个表写入一张表
  • 一张表写入多张表

这里的细节取决与对于2个系统之间的了解,都要在前期做很细的规划与考量。

迁移框架开发

对于迁移功能或者框架的要求需要做到如下才行:

  • 可回滚:全量回滚,单笔删除
  • 可重试:回滚重试、不回滚重试
  • 可校验:提供校验入口,输出校验结果
  • 时效性:一定的时间内,完成迁移、校验动作
  • 可控制:写入速度控制、可暂停、可强制停止
  • 可视化:进度条、耗时、速率~

其中迁移最重要的就是ReaderWriter,但大部分都是在写这里出现了性能问题。达不到迁移时间上的要求导致失败或者特殊处理。

Reader:

  • 分页查询,尽量能按照固定顺序来读;
  • 建议好索引,避免出现数据库底层的性能问题,提前分析加上好索引;
  • 部分数据可以加载在内存里里面,在内存里进行包装;

Writer:

  • 最好是利用并发来写数据,注意好线程安全;
  • 尽量把不同的表数据打散开来,提高数据库的并发;
  • 能批量操作的就批量操作,不要一条条的操作,减少网络的开销;
  • 注意好事物的回滚操作与日志监控

业务验证

  • 对于迁移的数据可验证,最好能做成自动化的验证功能
  • 对于异常数据把补偿功能提前做好
  • 提前做好回滚的方案

指标&异常考虑

  • 可回滚:全量回滚,单笔删除 -- 支持以物理表维度全量回滚
  • 可重试:回滚重试、不回滚重试 -- 支持,建议采用回滚重试
  • 可校验:提供校验入口,输出校验结果 -- 支持
  • 时效性:一定的时间内,完成迁移、校验动作
  • 可控制:写入速度控制、可暂停、可强制停止 -- 通过写线程、部署服务数量来控制速录, 支持暂停服务 TaskScheduler
  • 可视化:进度条、耗时、速率 -- 抽样打印插入耗时, 支持打印进度条、打印内存占用率、cpu等

总结

真的没有最厉害的系统,只有最合适的系统。不要过度设计、过度设计、过度设计。每一个设计一定是为了解决某种恶心问题来设计的,它可能解决了最恶心的问题但是也附带了它的问题。首先要去任何架构师的设计,其余的问题就是去耐心解决就好。 如果大家喜欢我的文章,可以关注个人订阅号。欢迎随时留言、交流。

简栈文化服务订阅号