单体项目改造演变成微服务项目,具体会涉及到哪些方面的改动？会有些什么难点？

问题：单体项目改造演变成微服务项目,具体会涉及到哪些方面的改动？会有些什么难点？

1.传统架构有什么问题？

1. 维护性：团队维护困难、部署项目臃肿、耦合性太强
2. 扩展性：扩展能力差，单机问题严重
3. 技术层次：技术陈旧，没办法提升技术含金量
4. 高性能：单体服务相对容易到达瓶颈
5. 人员水平：人员难招

2.我们需要准备什么？

填坑：旧系统中不完善的代码，需要进行拆分重构、推翻等

架构：拆分成哪几个微服务，是否合理？技术选型？如何统一定制规范？出现问题如何及时收到通知？

组织调整：哪些人负责哪个微服务

3.拆分思路：我们按照什么纬度进行拆分？

先局部拆分，找出能够提前上的技术点

由点到线再到面，再将业务部分由简单到难

比如：用到消息中间件，那么可以提前进行搭建

再比如：一个业务已经很久没新的需求了，且与其他业务关联性不大，很适合拆分出先做微服务，那么先找两个人拆分出来重构，提前上到微服务。

具体拆分步骤

步骤1：

数据库：

将一个数据库，根据业务逻辑垂直拆分成多个库。数据模型需要定义合理；避免微服务之间业务耦合，不然容易引发多次重构、返工。拆分核心：高内聚、松耦合。

第一步是拆分数据库，服务依然是单体的此时应改成多数据源连接。

步骤2:

中间件的搭建：如MQ 注册中心、配置中心、统一网关等。

这样做的目的是：在后边坐业务模块拆分时。可以很好的鱼原有业务进行通信，避免拆分出来没有用处。

步骤3

日志规范：新老系统日志格式统一。

例如：

统一将微服务集成到ELK

步骤4

监控配套，新老系统替换，监控需要与第一次上线微服务一起准备，不然出现问题，不易发现。

步骤5 业务拆分 结合人员分配，并行开发。

步骤6 准备微服务的配套文档。

可能遇到的难点：

1. 新老系统替换，在途的订单数据如何处理？

   新老系统并行一段时间，老系统入口封死，没有新的流量进入创建，西系统入口打开，结合数据状态，增加回掉，当老系统收到单据数据改变时，同步到新系统，使业务闭环。

2. 切换到新系统后，如何保证数据正确性，不丢失？
   定时筛查，类似对账，数据迁移完，通过sql 表对表比对