旧系统改造

背景

很多时候，我们在项目前期会优先确保项目业务的落地，在短时间内进行项目冲刺，最后完成项目上线。这样做让短时间内的目标达貌似达成了，却给系统留下了很大的隐患。

在项目的冲刺过程中，我们的精力大部分花在了业务的快速实现上，忽略了系统是否具有良好的微服务架构、是否具有良好的代码质量、是否拥有相应的文档等等。

遗留项目的特点：

• 单体系统庞大，臃肿
• 缺乏质量保障：产品设计在开发过程中不断调整，目标不清晰，对系统测试不到位
• 维护成本高：执行标准低，技术负债累累
• 难以修改：开发人员素质不一，没有监管，代码可读性差、代码质量差
• 学习成本高：没有完善的文档，设计不清晰

欠的技术债，迟早都要还的。

改造策略

重写还是重构？重写：成本大，周期长，风险具大，不现实

演进式改造流程：不能影响使用、风险可控、平滑过渡

需要对系统业务非常熟悉，梳理原系统业务构建指导图->服务拆分->服务改造（优先选择对相对独立、频繁变更、特殊资源进行改造）->业务验证

绞杀者模式：慢慢改造， 逐步替换，现有系统继续对外提供服务

挎斗模式：遗留系统改不动，加一个代理

改造场景：

场景1: 实现新业务服务时与旧系统数据独立

场景2: 实现新业务服务时与旧系统数据有依赖关系

根据数据持有者的不同，有两种处理方案

方案1:旧系统持有数据

方案2:新业务系统持有数据，将旧系统数据同步过来

场景3: 旧系统微服务化改造