问题：单体项目改造演变成微服务项目,具体会涉及到哪些方面的改动？会有些什么难点？
1.传统架构有什么问题？
- 维护性：团队维护困难、部署项目臃肿、耦合性太强
- 扩展性：扩展能力差，单机问题严重
- 技术层次：技术陈旧，没办法提升技术含金量
- 高性能：单体服务相对容易到达瓶颈
- 人员水平：人员难招
2.我们需要准备什么？
填坑：旧系统中不完善的代码，需要进行拆分重构、推翻等
架构：拆分成哪几个微服务，是否合理？技术选型？如何统一定制规范？出现问题如何及时收到通知？
组织调整：哪些人负责哪个微服务
3.拆分思路：我们按照什么纬度进行拆分？
先局部拆分，找出能够提前上的技术点
由点到线再到面，再将业务部分由简单到难
比如：用到消息中间件，那么可以提前进行搭建
再比如：一个业务已经很久没新的需求了，且与其他业务关联性不大，很适合拆分出先做微服务，那么先找两个人拆分出来重构，提前上到微服务。
具体拆分步骤
步骤1：
数据库：
将一个数据库，根据业务逻辑垂直拆分成多个库。数据模型需要定义合理；避免微服务之间业务耦合，不然容易引发多次重构、返工。拆分核心：高内聚、松耦合。
第一步是拆分数据库，服务依然是单体的此时应改成多数据源连接。
步骤2:
中间件的搭建：如MQ 注册中心、配置中心、统一网关等。
这样做的目的是：在后边坐业务模块拆分时。可以很好的鱼原有业务进行通信，避免拆分出来没有用处。
步骤3
日志规范：新老系统日志格式统一。
例如：
统一将微服务集成到ELK
步骤4
监控配套，新老系统替换，监控需要与第一次上线微服务一起准备，不然出现问题，不易发现。
步骤5 业务拆分 结合人员分配，并行开发。
步骤6 准备微服务的配套文档。
可能遇到的难点：
-
新老系统替换，在途的订单数据如何处理？
新老系统并行一段时间，老系统入口封死，没有新的流量进入创建，西系统入口打开，结合数据状态，增加回掉，当老系统收到单据数据改变时，同步到新系统，使业务闭环。
切换到新系统后，如何保证数据正确性，不丢失？
定时筛查，类似对账，数据迁移完，通过sql 表对表比对
