背景
很多时候,我们在项目前期会优先确保项目业务的落地,在短时间内进行项目冲刺,最后完成项目上线。这样做让短时间内的目标达貌似达成了,却给系统留下了很大的隐患。
在项目的冲刺过程中,我们的精力大部分花在了业务的快速实现上,忽略了系统是否具有良好的微服务架构、是否具有良好的代码质量、是否拥有相应的文档等等。
遗留项目的特点:
- 单体系统庞大,臃肿
- 缺乏质量保障:产品设计在开发过程中不断调整,目标不清晰,对系统测试不到位
- 维护成本高:执行标准低,技术负债累累
- 难以修改:开发人员素质不一,没有监管,代码可读性差、代码质量差
- 学习成本高:没有完善的文档,设计不清晰
欠的技术债,迟早都要还的。
改造策略
重写还是重构?重写:成本大,周期长,风险具大,不现实
演进式改造流程:不能影响使用、风险可控、平滑过渡
需要对系统业务非常熟悉,梳理原系统业务构建指导图->服务拆分->服务改造(优先选择对相对独立、频繁变更、特殊资源进行改造)->业务验证
绞杀者模式:慢慢改造, 逐步替换,现有系统继续对外提供服务
挎斗模式:遗留系统改不动,加一个代理
改造场景:
场景1: 实现新业务服务时与旧系统数据独立
场景2: 实现新业务服务时与旧系统数据有依赖关系
根据数据持有者的不同,有两种处理方案
方案1:旧系统持有数据
方案2:新业务系统持有数据,将旧系统数据同步过来
场景3: 旧系统微服务化改造