老旧系统改造要点

每次看到遗留系统的时候，我总想着设计一个迁移方案。时间一久，收集的案例一多，外加上我也有了越来越多的案例，便想着记录一下这些内容。

遗留系统的迁移

遗留系统的迁移是一个相当复杂的工作，以至于重写的成本甚至比迁移的成本更高。但是从技术维度来看，步骤无非就是：

• 设定迁移的目标

• 制定迁移的计划

• 迁移计划的验证（PoC）

• 实施应用程序的迁移

• 校验迁移结果

对，就是这么简单。

遗留资产

我们通过把数字化时代的遗留资产划分了这几种类型：

• 遗留代码。所有没有测试的代码。

• 遗留基础设施。所有不安全、没有弹性、不可靠的基础设施。

• 遗留系统。所有不可观察、没有支持的自制系统或者商业化系统（COTS）

• 遗留架构。所有限制交付价值的架构。

• 旧式流程。所有不可度量的流程（缺少 KPI、SLO）

• 旧式组织。所有不敏捷且不统一的组织

• 旧式思维。相信上述内容无法克服或无法改变

替换这些系统的原因，也无非就是：

• 降低成本：更快的概念兑现

• 改善客户体验

• 上市

• 可伸缩、可扩展系统

• 技术变革根上业务变革的速度

迁移的目标架构

架构量子则是具有高功能内聚并可以独立部署的组件，它包括了支持系统正常工作的所有结构性元素。—— 《演进式架构》

在单体架构中，量子就是整个应用程序，每个部分都高度耦合，因此开发人员必须对其进行整体部署。

架构	架构量子	可演进性
没有架构的单体	单体（大泥球）	低
分层单体	单体（分层应用）	低
模块化、结构化单体	单体（如模块化的 COTS）	中
微内核	内核 + 插件	中
事件驱动 - 中介	总线、消费者、订阅者	中
事件驱动 - 代理	队列、消费者、订阅者	高
基于服务的架构	微服务	高

过程模式

对应的替换过程模式有：

• 改善现有。现有系统已经过现代化改造，可以通过改进设计来提供更好的结果。通常，核心技术堆栈保持不变，或者可能会引入一些次要的补充。

• 缓慢替换。IT 系统的组件/功能块已被新技术取代，并作为单独的应用程序移至生产环境，而系统的其余部分仍旧采用旧技术。随着时间的流逝，剩余的组件/功能块将被单独的应用程序取代，然后逐步重建整个系统。

• 普通替换。整个系统使用新技术进行了重建，旧系统已停用。它使用标准平台从头开始构建，或者使用第三方程序包作为基础层构建。
  

当然了，每种模式的要求也有所不同：

	改善现有	缓慢替换	完全替换
现有化技术栈	低	高	最高
系统修改	应用级别	应用级别 / 局部变化	企业级
风险等级	低	中	低 - 高
资金需求	中	中	低 - 高
持续时间	数月	数月到 1 年	数月到数年
长期收益	低	高	最高
人生度	最高	高	低
人力成本	低	中	高

迁移策略

在我们决定好了迁移的目标和模式之后，只需要适合的方式即可：

• 保留（Retain），什么都不做。

• 清退（Retire），摆脱原有束缚。

• 重新采购（Repurchase），转移至不同的产品。

• 重新托管（Rehost），即直接迁移。

• 平台更新（Replatform），『修补加迁移』。

• 架构重构（Re-Architect），更改应用程序的架构和开发方式，往往通过使用云原生功能来完成的。

这里，我们主要考虑讨论的是：重新托管、平台更新、架构重构，因为只有这三项是技术活动。

防护网

对于遗留系统的迁移，想必你也相当的有经验了，比如这些常见的实践：

• 使用版本管理。

• 小步前进。

• 使用测试作为防护网。

• 频繁提交。

• ……
  

而在这其中除了架构的设计，最复杂的一部分莫过于：防护网的设计。

自动化测试

适用的场景：遗留代码、遗留系统、 遗留架构。

对应的实施方式：

• 代码级重构。

• 组件级重构。

• API 级重构。

• 系统级迁移。

常见的防护措施有：

• 单元测试。针对于包级、组件、函数级的代码重构场景。

• • 容器内测试。针对于模块化的 OSGI 架构应用。

• API 测试。采用纺锥型测试策略进行系统迁移。

• • 端对到端测试。较少采用，成本较高，效果较差。

• UI 测试。
  

• 性能测试。针对于云迁移下的对比。

常见的工具有：xUnit、 REST Assured、Karate、Cucumber 等。

比对

适用场景：遗留基础设施、遗留系统、遗留架构。

基础设施迁移：

• 数据库迁移。

• 构建工具迁移。

常见的实施方式有：

• 数据比对测试。通过测试对比迁移前后的数据变化，来判定迁移是否成功。

• 数据库比对测试。同上，只是维度变成了数据库。

• • Schema 比对。确保数据模型或架构结构在源系统和目标系统之间匹配。

  • Row 计数比对。确保计数是针对源和目标之间的表是否匹配。

  • 数据汇总测试。对源和目标之间的大量表执行汇总检查。

• 制品比对测试。针对于构建工具迁移，对比构建产物，看是否发生变化。

• • checksum 比对。

  • class 比对。
    

常见的工具有：DBDiff、DbUnit 等。

防腐层

适用场景：遗留系统绞杀。

常见的实施方式有：

• 过渡 API。适用于遗留系统迁移的过渡模式，在迁移完成好，可以删除。

• 防腐层。即建立与遗留、腐败的代码的层级，以隔离系统变化。

• • BFF。适用于多种客户端模式

结论

没有银弹，迁移才是最有意思的技术挑战。