Blog

Blog

PHODAL

迁移防护网

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

遗留系统的迁移

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

  • 设定迁移的目标
  • 制定迁移的计划
  • 迁移计划的验证(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。适用于多种客户端模式

结论

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


或许您还需要下面的文章:

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806

新书《全栈应用开发:精益实践》

这不是一本深入前端、后台、运维、设计、分析等各个领域的书籍。本书以实践的方式,将这一系列的领域及理论知识结合到一起,来帮助读者构建全栈Web 开发的知识体系,并辅以精益及敏捷的思想,来一步步开发Web 应用:从创建一个UI 原型到编写出静态的前端页面;从静态的前端页面到带后台的应用,并部署应用;从Web 后台开发API 到开发移动Web 应用。在这个过程中,我们还将介绍一些相辅相成的步骤:使用构建系统来加速Web 应用的开发;为应用添加数据分析工具来改进产品;使用分析工具来改善应用的性能;通过自动化部署来加快上线流程;从而帮助读者开发出一个真正可用的全栈 Web 应用。同时,我们也将帮助读者把这些步骤应用到现有的系统上,改进现有系统的开发流程。

comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签