遗留系统替换模式

了解您想要实现的结果

对于组织来说，在解决遗留问题时，商定他们想要实现的结果至关重要。虽然这似乎很明显，但组织的不同部门对预期结果的看法往往大相径庭。大多数遗留系统现代化计划都涉及我们列出的几个结果，但重要的是在踏上旅程之前确定哪些结果是优先事项。

决定如何将问题分解成更小的部分

广义地说，这涉及在当前的业务和技术架构中找到合适的“接缝”。重要的是，你必须考虑当前解决方案的各个元素如何映射到不同的业务能力。对于遗留系统，这通常意味着发现一个大型技术解决方案如何满足多个业务需求，然后看看是否有可能提取单个需求以使用新解决方案独立交付。理想情况下，这些应该能够以最小的相互依赖关系交付。

一个常见的反对意见是，找到这些接缝太难了。虽然我们同意这在开始时很有挑战性，但我们发现它比其他方法更好，其他方法往往会导致功能一致性和大爆炸式发布。我们还观察到，许多组织排除了这种方法，因为他们孤立地看待技术或业务流程。仅仅改变技术的一部分，或者独立更新一个业务流程，很可能失败，但如果我们能够一起考虑和实施这两个方面，那么就有办法“吃掉大象”。

成功交付各个部分

对更快变化的需求以及能够增量交付和独立更改业务元素而无需大型依赖关系，往往会导致“敏捷”交付方法以及基于微服务的架构。对于这些可独立部署的组件，持续交付成为必不可少。除了普通的软件交付之外，让这变得具有挑战性的是，要找到从现有大型解决方案中切断、与之共存以及最终替换元素的策略。有几种成功的策略，包括并行运行、入口分叉和流量转移。

† 目前只是一个存根

改变组织以允许此过程持续进行

如果我们退一步，看看交付新业务需求的整个过程，我们可以很快发现这只是一个部分的技术问题。如果我们使用新技术来缩短构建解决方案的时间和成本，那么我们将突出显示在达成一致需求和将更改投入生产方面遇到的任何问题。

我们需要组织结构和流程的改变，以充分利用更好的技术，并且根据 康威定律，我们还需要一个能够促进这种改变的技术架构。如果团队及其沟通方式围绕着现有的遗留解决方案和流程进行组织，我们可能需要使用 逆康威操作 对其进行重组，以匹配新的解决方案及其架构。

遗留系统会限制和限制采用更现代的工程实践的能力，尤其是那些与极限编程和持续交付相关的实践。在替换遗留系统时，重要的是要确保工作方式发生改变，以确保我们不会最终得到一个速度慢、难以改变且成本高昂的系统。

遗留也是组织文化和领导力的产物，如果没有更广泛的改变，你应该预期与以前相同的成果。我们已经观察到许多遗留现代化工作由于“企业抗体”而失败，这些抗体发现了一些新的变化，并采取行动将其从组织中剔除。

举一个大型组织如何拒绝改变的例子：我们与一家非常大的电信公司合作，该公司希望为手机构建软件。领导层都理解这意味着比他们看到现有的专注于固定基础设施的程序更快的反馈周期和更频繁的更改。

虽然领导层理解这一点，但他们没有对现有的工作实践或管理这些流程的中层管理人员进行任何改变。因此，现有的变更控制流程被严格地应用。最终，软件团队花费在填写变更控制表格和参加变更控制会议上的时间比他们生产软件的时间还要多。“企业抗体”成功地拒绝了这种新的工作方式。

组织变革是一个很大的话题，已经有大量的文献可供参考，遗留系统面临的主要挑战往往与时间有关。很少有组织能够在重构（或重建，对于外包受害者来说）整个交付方式以及组织结构和关键业务流程的同时，推迟遗留系统现代化。虽然组织转型这一更广泛的话题超出了我们的范围，但我们确实建议了一些在遗留系统环境中应用和保护新工作方式的策略。如果你只是改变遗留系统而不做其他任何事情，那么可以预料你将在几年内再次替换遗留系统。

† 目前只是一个存根

当然还有其他组织转型策略和方法，我们只是重点介绍了这两种方法，因为在某种程度上，它们允许更早地开始遗留系统现代化工作，而不是推迟。

了解结果

我们团队面临的挑战是如何用一个新的可支持、灵活的解决方案来替换已经不再支持、难以更改且成本很高的集成中间件，而不会中断或危及现有的业务运营。所讨论的中间件用于在后端系统和店面之间进行集成。这些系统共同负责每天销售价值数千万英镑的独特高价值产品。

这项工作是更大项目中的一个高优先级部分。支持业务的所有后端系统都将被替换，店面也将在几年内进行现代化改造。

因此，根据上面的步骤 1，团队需要实现的业务成果被定义为：

1. 改进业务流程

如何改进？这个特定的集成中间件解决方案包含大量的逻辑，包括业务核心规则，例如在哪个渠道上销售产品，或者如何在店面内何时展示产品。这个现有系统非常难以更改，阻碍了业务创新，逻辑中的缺陷导致了一些问题，例如产品在一段时间内甚至无法出售！

2. 尽快淘汰旧系统

为什么？为了降低现有的（并且不断增加的）许可证和支持成本。此外，为了减轻在过时的中间件和数据库技术上运行关键功能而给业务带来的风险。

分解问题：第一个缝合点和重构

在 初始阶段，团队与那些对遗留系统有深入了解的人员一起进行了一个研讨会，以协作地可视化现状和目标软件架构。完成此操作后，他们发现了一个可以利用的技术缝隙，即遗留后端和集成中间件之间的基于消息的集成。遗留后端是一个老化的 J2EE 应用程序，它将“发布产品”消息放到一个由非常旧版本的 SwiftMQ 提供的队列中。 事件拦截 模式在这里很有用，如果将其实现为 基于内容的路由器，它将允许控制来自遗留后端的路由消息的方式，并创建一个选项，使消息能够路由到新系统。

集成中间件还处理来自店面的消息（例如，用于产品销售），使用 JDBC 直接更新遗留后端背后的主数据库中的状态。异步消息通过 SwiftMQ 和 JDBC 数据库更新共同构成了遗留后端和集成中间件之间的接口。

虽然当时没有发现，但团队能够在子系统级别使用 分支抽象 模式，作为启用遗留中间件替换的策略。抽象层是队列和 JDBC。通过确保新实现符合该抽象层，它可以被替换为“有缺陷的供应商”，而不会影响业务运营。

团队首先通过重构实现事件拦截，添加了一个事件路由器。

事件路由器 (1) 的创建考虑了三个主要功能：

1. 从一个 SwiftMQ 队列中出队消息，并将它们入队到另一个 SwiftMQ 队列中 (2)。一些配置的微小更改使集成中间件能够从这个新队列 (2) 中消费消息。

总的来说，重构使观察到的系统行为保持不变，但事件路由器现在已成为过渡架构的一部分，已插入消息处理管道中。

2. 事件路由器的愿景是通过配置启用将消息路由到备用目的地，从而使新实现能够处理发布消息。 事件拦截
3. 事件路由器还将提供从旧的 SwiftMQ 技术到为目标架构选择的新的 ActiveMQ 技术的桥梁。

实现事件路由器并不像预期的那样简单。由于缺少可用的驱动程序/库，与 SwiftMQ 集成存在问题，并且该方法多次受到挑战。团队了解了这种方法将解锁的选项的价值，并完成了工作并发布到生产环境中。他们监控了新组件在野外的运行情况，并准备使用新的 持续交付 管道逐步增强其功能。

成功交付各个部分：构建功能，维护契约

新的店面管理器 (1) 现在由团队迭代构建。与本示例相关的是，该构建包括实现遗留模拟模式的主数据库适配器 (2)。这是作为抽象层的一部分所需的，用于使用从店面接收到的销售信息更新主数据库。由于事件路由器不会转换消息，因此创建了一个遗留事件适配器 (3) (消息转换器)，用于将消息转换为新格式，不会将遗留世界暴露给新世界，并符合新架构的原则。遗留店面 适配器(4) 也在新的店面管理器 (1) 和遗留店面之间实现，以隔离新实现，使其不受将来店面替换时发生的更改的影响。

在遗留店面 (5) 上引入了一个新的 API，新的店面管理器将使用它。此外，还添加了一个功能，使新 API 上发布的产品的回调可以发送到新的店面管理器的适配器 (4)。重要的是，这使遗留实现和新实现能够并行运行。

成功交付各个部分（续）：过渡到实时服务 - 使用第二个缝合点

所有部分都到位后，企业能够测试新的解决方案，但如何以**风险管理的方式**将其推出到实时服务中。

为了做到这一点，他们利用了另一个缝隙——这次使用按产品细分模式。事件路由器得到了增强，可以根据产品类型和唯一产品 ID 添加可配置路由 (6)。团队能够根据 ID 测试单个产品的发布、管理和销售，然后随着时间的推移，使用越来越多的产品类型配置路由器，实质上增加了由新解决方案处理的产品百分比。

当所有产品都由新系统处理时，遗留集成中间件被停用，实现了许可证、支持和数据中心托管费用的显著节省。

改变组织以允许此过程持续进行

我们的团队已经在组织的另一个部门与客户合作，并且已经成功地替换了另一个遗留系统。

在整个组织的工程层面上，持续交付和良好的支持质量实践现在已成为既定规范，微服务风格的架构使容器化服务能够定期且独立地部署到基于云的平台上。

新项目中的团队与新的利益相关者合作，需要将业务的这一部分也带到相同的“敏捷和 CD”旅程中，早期的风险管理发布使信任得以建立。随着时间的推移，可以证明新的工程和质量实践（包括 CD）如何减轻历史上导致更高程度的官僚主义和治理的相同风险。因此，较少频率、较大范围的发布也被较小、更频繁、更高置信度的部署所取代，并在企业准备好接受更改时向企业发布切换发布。

结束语

当然，与上面简化的故事中所暗示的相比，复杂性和集成需求要大得多。在生产环境中测试新实现后不久，就出现了对考古学需求的示例。一些对业务至关重要的管理信息报告不一致——产品“丢失了”。

经过深入调查，团队发现集成中间件使用的数据库（用于存储长时间运行的业务事务状态）被复制到组织的数据仓库中。通过一系列批处理作业、存储过程和视图，这些数据被用于业务关键 KPI 报告。

为了确保这些报告不会中断，需要额外的遗留模拟。团队在来自店面的销售消息上使用了 线缆监听，并使用 JDBC 将数据注入数据仓库中的相应表格。这些额外的模拟也成为了过渡架构的一部分，并在可能的情况下被移除。

抽象分支方法以及上面描述的模式和实践旨在降低风险。

使用事件拦截（技术缝合）、遗留模拟和过渡架构，客户能够将问题分解。然后，通过产品（业务缝合）进行细分，在本例中为产品类型，可以对更广泛的推广进行精细控制，并进一步管理风险。总体而言，这种方法允许企业以他们舒适的速度进行系统替换。

这种方法可以管理风险，但也有成本。因此，需要考虑的问题是“企业对这种风险缓解的价值如何？”明确并量化它，将允许团队跟踪针对它的投资。事件路由器和遗留模拟是过渡架构的一部分，旨在管理风险。它们的作用是创造选项，使风险能够得到管理。这种工作很容易被视为“一次性”——因此，应尽可能避免成本。在“风险缓解价值”与“过渡架构成本”的权衡中，要明确和透明。