1. 背景介绍

原先我有个项目A，随着业务的发展，产品会提非常多的需求，随着需求的增加，原有的项目就会越来越臃肿，直观的感受就是单测和部署的速度都很慢。

2 系统臃肿带来的影响

• 程序启动慢，发布慢，开发效率会降低，解决bug的响应速度也会降低
• 从领域的角度来说，其实不同的业务可能完全在不同的领域中，比如有些是营销活动相关的，有些是交易订单相关的，有些是做数据聚合展示的
• 不同的模块之间的应用的重要性是不一样的，比如你的应用X是一个包含了支付相关的应用，应用等级是A，但是其中数据展示层的问题导致了线上出现了问题
  • 对用户和公司来说，带来了不可避免的损失
  • 对自己影响也很大，本来应用等级C的故障其实没啥关系，但是因为你的带来了故障的应用包含核心业务，所以提升了故障等级

3 系统迁移的流程

3.1 划分出不同的业务域

示意图如下:

业务领域 (1).png

3.2 子业务介绍

• 核心业务相关的
  这一块内容会包含数据库分库分表的读写，数据库缓存的查询，失效和更新，数据快照等，对外提供高可用的服务接口，一般用户层是直接访问不到的。
  通过dubbo接口对其他服务提供能力

  • 因为其很重要，所以一定需要关注dubbo线程池和业务线程池的健康状况，做好监控，建议到达阀值后就报警，不要满了报警
  • 不同业务的调用，能做到线程池隔离的话，尽量做到线程池隔离，一些业务的调用量会比其他业务高很多，容易拖垮dubbo线程
  • 做好相应的扩容措施，应对突发流量

• 业务展示层
  注重功能业务，以及一些衍生业务，比如依赖底层服务，我们可以使用规则引擎，插件(spi,策略模式)，责任链等方式支持快速开发上层业务逻辑

• 异步任务层
  主要一些mq异步更新的操作，监听binlog同步等的操作，功能相对独立，但是这个业务可能io操作比较多，需要创建io指标的报警项，磁盘的话条件ok可以用SSD的。

• 数据聚合层
  这层比较简单，主要做报表的展示，报表的导出。查询可以走es，hbase

3.3 业务的迁移过程

3.3.1 创建一个新项目

• 假设原先的系统是A，创建一个新的项目B，方式有如下几种
  • 比较简单的，把原先A中所有配置拷过来先，在这之上开发
  • 整一个maven archetype快速创建项目
  • 使用spring boot的autoconfigure方式
    • 这之上其实可以参考Spring initailizer和阿里云开源的spring cloud initailizer，将自己公司的中间件也整一个initailizer，支持快速创建(最近阿里云的initailizer支持COLA了，自己业务可以开发相应的架构模式)

3.3.2 将业务A的一些DO依赖移动到client模块

• A业务的DO不应该迁移到B业务的
• 将A业务的client打成jar包发布到公司的nexus maven私服
  • 不建议将jar包打成snapshot的，这是个非常不好的习惯

3.3.3 将业务B相关的DO，DTO，VO迁移

• 迁移需要迁移干净，不要还引用到A业务中的client包中的B的DO，DTO，VO

3.3.4 将业务B相关的dao，service，controller迁移

• 中间如果有spring注入的A业务的依赖，建议通过在A业务client模块中添加facade接口，业务B通过dubbo进行rpc调用
  • 接口的dto注意需要实现序列化的接口，不然rpc调用会报错
  • rpc调用注意适当的调用顺序，比如应用A的等级是P1，应用B是P3，那么B调A是合理的，A调B是有风险的，因为两者的可用性机器多少是不同的
• controller层依赖的时候，如果公司有api网关的话，最好修改api的名字，见名知义
• 如果有应用循环依赖的问题，可以dubbo配置consumer的check属性为false(不建议)

3.3.5 基础设施迁移

a. redis
检查是否需要使用单独的namespace，不建议共用namaspce，可以申请单独的namespace。根据业务量来看是需要cluster的还是主从的，以及内存大小
b. mq
mq一定要检查，避免业务A还接受到消息，迁移完后，需要将A中B的接受mq的代码注释掉
c. 数据库
数据库的话可以使用一个数据库，根据业务量使用不同的数据库，数据量不大的话但库单表就ok了，数据库创建的时候也要考虑业务容量的增长，适当容余
d. 动态配置服务
需要申请独立的group，和A业务进行独立

3.3.6 迁移完后，构建下是否有报错

3.3.7 迁移后检查

• 使用idea全局搜业务A的包名
• 确保业务B的所有service，dao，controller引用的都是业务B的DO，DTO，VO，如果还有引用业务A中的，idea alt+F7找到所有引用，一一修改引用；检查下mybatis的mapper文件的namespce，result等类型是否还修改了

3.3.8 测试

• 将单元测试代码迁移，把所有的单测跑一遍
• 将新应用的接口和原应用的接口写个文档梳理下，关联到哪些h5页面，native页面等，页面新的url是啥
• 前端配合修改后，让测试进行回归测试

3.3.9 制定发布计划上线

• 制定合理的发布计划，建议先上B应用，上线成功后，再下线A中B应用遗留的代码
• 如果可以制定相应的回滚策略