遗留系统的迁移是一个相当复杂的工作,以至于重写的成本甚至比迁移的成本更高。但是从技术维度来看,步骤无非就是:
对,就是这么简单。
我们通过把数字化时代的遗留资产划分了这几种类型:
替换这些系统的原因,也无非就是:
架构量子则是具有高功能内聚并可以独立部署的组件,它包括了支持系统正常工作的所有结构性元素。—— 《演进式架构》
在单体架构中,量子就是整个应用程序,每个部分都高度耦合,因此开发人员必须对其进行整体部署。
架构 | 架构量子 | 可演进性 |
---|---|---|
没有架构的单体 | 单体(大泥球) | 低 |
分层单体 | 单体(分层应用) | 低 |
模块化、结构化单体 | 单体(如模块化的 COTS) | 中 |
微内核 | 内核 + 插件 | 中 |
事件驱动 - 中介 | 总线、消费者、订阅者 | 中 |
事件驱动 - 代理 | 队列、消费者、订阅者 | 高 |
基于服务的架构 | 微服务 | 高 |
对应的替换过程模式有:
当然了,每种模式的要求也有所不同:
改善现有 | 缓慢替换 | 完全替换 | |
---|---|---|---|
现有化技术栈 | 低 | 高 | 最高 |
系统修改 | 应用级别 | 应用级别 / 局部变化 | 企业级 |
风险等级 | 低 | 中 | 低 - 高 |
资金需求 | 中 | 中 | 低 - 高 |
持续时间 | 数月 | 数月到 1 年 | 数月到数年 |
长期收益 | 低 | 高 | 最高 |
人生度 | 最高 | 高 | 低 |
人力成本 | 低 | 中 | 高 |
在我们决定好了迁移的目标和模式之后,只需要适合的方式即可:
这里,我们主要考虑讨论的是:重新托管、平台更新、架构重构,因为只有这三项是技术活动。
对于遗留系统的迁移,想必你也相当的有经验了,比如这些常见的实践:
而在这其中除了架构的设计,最复杂的一部分莫过于:防护网的设计。
适用的场景:遗留代码、遗留系统、 遗留架构。
对应的实施方式:
常见的防护措施有:
常见的工具有:xUnit、 REST Assured、Karate、Cucumber 等。
适用场景:遗留基础设施、遗留系统、遗留架构。
基础设施迁移:
常见的实施方式有:
常见的工具有:DBDiff、DbUnit 等。
适用场景:遗留系统绞杀。
常见的实施方式有:
结论
没有银弹,迁移才是最有意思的技术挑战。