作者: Phodal Huang 2020年6月30日 20:37

每次看到遗留系统的时候，我总想着设计一个迁移方案。时间一久，收集的案例一多，外加上我也有了越来越多的案例，便想着记录一下这些内容。 ## 遗留系统的迁移 遗留系统的迁移是一个相当复杂的工作，以至于重写的成本甚至比迁移的成本更高。但是从**技术维度**来看，步骤无非就是： - 设定迁移的目标 - 制定迁移的计划 - 迁移计划的验证（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。适用于多种客户端模式 ## 结论 没有银弹，迁移才是最有意思的技术挑战。

作者: Phodal Huang in 架构 2020年6月22日 20:18

最大化重用会使得可用复杂化。 —— 《Java 应用架构设计》

作者: Phodal Huang in 杂谈 2020年6月16日 20:05

最近，我又挖了几个开源项目的坑，Ledge、Ledge Framwork、Igso 等等。每次挖新坑的时候，经常性地都要花很多的时间，想着怎么编写 README、完善 README。而就是这么一个简单的 README 的编写，它都要花费我相当长的时间，或是几个小时，或是几天。

作者: Phodal Huang 2020年6月9日 20:45

上周在公司内部又做了一次关于开源的分享，与三月份那次稍有不同的是，这次的关注点主要是：企业与开源软件。

作者: Phodal Huang in 杂谈 2020年6月1日 20:03

很早以前，我便想着写一篇文章吐槽一下数字化时代。如果你熟知我在开源世界的贡献（代码 + 内容），就知道我一直是开源软件、自由软件的拥趸：RMS 一直是对的 [🐶🐶🐶] 。

作者: Phodal Huang 2020年5月25日 20:32

需求代码化，即将软件开发需求抽象为特定的领域语言，并使用管理代码一样的方式来管理需求，追踪需求的变化 。同时，为通过新的 API 来对接版本管理系统，以可视化需求，演变为看板代码化。

作者: Phodal Huang 2020年5月25日 20:24

不同的微前端框架都源于它们的使用场景，也受限了它们不能满足于其它场景。受限于使用场景，这些微前端框架都需要不同程度的改造，才能满足各自的需要。

作者: Phodal Huang 2020年5月19日 13:26

随着持续部署、DevOps 在各个企业的推进，越来越多的企业已经有完善的基础设施，软件开发团队只需要一个在线的 IDE，就可以完成开发工作，这就进入了云开发时代。

作者: Phodal Huang 2020年5月17日 21:25

PS：过去的几个月里，我陆陆续续和不同公司的人一起讨论了开发、研发的未来。光是发我写过的几篇文章的链接，已经不能很好地解决问题。所以我决定写一篇长长的文章，来帮助更多地人理解：研发的未来在哪里？

作者: Phodal Huang 2020年5月11日 20:31

这个故事很长，不过我并不想讲得太长。原先，关于这个问题的答案只有一个。只是我在写 Ledge 的时候，发现了一些有意思的东西。因此，我决定写一篇不太不短的文章来讲述一下。