揭示大型机中的接缝以实现增量现代化

背景信息

大型机托管着对客户业务运营至关重要的各种服务。我们的计划特别关注为英国和爱尔兰 (UK&I) 的消费者提供洞察力的数据平台。大型机上的这个特定子系统包含大约 700 万行代码，开发时间跨度超过 40 年。它提供了 UK&I 资产大约 50% 的功能，但从运行时角度来看，占用了大约 80% 的 MIPS（每秒百万条指令）。该系统非常复杂，域职责和关注点遍布遗留环境的多个层，这进一步加剧了复杂性。

客户决定从大型机环境迁移的原因有很多，以下是其中一些原因

1. 对系统的更改缓慢且成本高昂。因此，企业在快速发展的市场中难以跟上步伐，阻碍了创新。
2. 与运行大型机系统相关的运营成本很高；客户面临着核心软件供应商即将提价的商业风险。
3. 虽然我们的客户拥有运行大型机所需的技能，但事实证明，很难找到具有这种技术堆栈专业知识的新专业人员，因为该领域的熟练工程师数量有限。此外，就业市场并没有为大型机提供那么多机会，因此人们没有动力去学习如何开发和操作它们。

消费者子系统的高级视图

下图从高级角度展示了消费者子系统中的各种组件和参与者。

大型机支持两种不同类型的工作负载：批处理和在线交易（用于产品 API 层）。批处理工作负载类似于通常所说的数据管道。它们涉及从外部提供商/来源或其他内部大型机系统摄取半结构化数据，然后进行数据清理和建模，以符合消费者子系统的要求。这些管道包含各种复杂性，包括身份搜索逻辑的实现：在英国，与拥有社会安全号码的美国不同，居民没有通用的唯一标识符。因此，在英国和爱尔兰运营的公司必须采用定制算法来准确确定与该数据相关的个人身份。

在线工作负载也呈现出巨大的复杂性。API 请求的编排由多个内部开发的框架管理，这些框架通过在数据存储中查找来确定程序执行流程，并通过分析代码输出处理条件分支。我们不应忽视此框架为每个客户应用的定制级别。例如，一些流程是用临时配置编排的，以满足与我们客户的在线产品交互的系统的实现细节或特定需求。这些配置最初很特殊，但随着我们客户增加在线产品，它们很可能随着时间的推移而成为常态。
这是通过跨层运行的授权引擎实现的，以确保访问产品和底层数据的客户经过身份验证和授权，可以检索原始数据或聚合数据，然后通过 API 响应向他们公开这些数据。

增量遗留系统替换：原则、优势和注意事项

考虑到消费者子系统的范围、风险和复杂性，我们认为以下原则将与我们成功完成该计划紧密相关

• 早期风险降低：从一开始就进行工程设计，“快速失败”方法的实施将帮助我们及早发现潜在的缺陷和不确定性，从而防止从项目交付的角度来看出现延误。这些是
• 结果一致性：客户强调了维护现有遗留系统和新系统之间结果一致性的重要性（需要注意的是，此概念不同于功能一致性）。在客户的遗留系统中，会为每个消费者生成各种属性，并且鉴于严格的行业法规，保持连续性对于确保合同合规性至关重要。我们需要尽早主动识别数据差异，及时解决或解释这些差异，并在早期阶段与客户及其各自的客户建立信任和信心。
• 跨功能需求：大型机是一台高性能机器，并且存在云解决方案是否能满足跨功能需求的不确定性。
• 尽早交付价值：与客户合作将确保我们能够确定我们可以尽早交付的最关键业务功能的子集，确保我们可以将系统分解成更小的增量。这些代表了整个系统的薄片。我们的目标是迭代地、频繁地构建这些切片，帮助我们在领域中加速整体学习。此外，通过薄片工作有助于减少团队所需的认知负荷，从而防止分析瘫痪并确保持续交付价值。为了实现这一点，围绕大型机构建一个平台，更好地控制客户的迁移策略起着至关重要的作用。使用暗启动和金丝雀发布等模式将使我们处于主导地位，以实现向云的平稳过渡。我们的目标是实现静默迁移过程，客户可以在系统之间无缝切换，而不会产生任何明显的影响。这只能通过全面的比较测试和对两个系统输出的持续监控来实现。

考虑到上述原则和要求，我们选择了增量遗留系统替换方法以及双运行。实际上，对于我们在云上重建的系统的每个切片，我们都计划为新系统和现有系统提供相同的输入，并并行运行它们。这使我们能够提取两个系统的输出，并检查它们是否相同，或者至少在可接受的公差范围内。在这种情况下，我们将增量双运行定义为：使用过渡架构来支持将功能逐片地从遗留环境中移出，从而使目标系统和现有系统能够暂时并行运行并交付价值。

我们决定采用这种架构模式，以在交付价值、尽早发现和管理风险、确保结果一致性以及在整个项目期间为客户保持平稳过渡之间取得平衡。

增量遗留系统替换方法

为了将功能卸载到我们的目标架构，团队与大型机 SME（主题专家）和我们客户的工程师密切合作。这种合作促进了对当前现状的足够了解，包括技术和业务能力；它帮助我们设计了一个过渡架构，将现有大型机连接到基于云的系统，后者由项目中的其他交付工作流开发。

我们的方法首先是将消费者子系统分解成特定的业务和技术领域，包括数据加载、数据检索和聚合，以及可通过面向外部的 API 访问的产品层。
由于客户的业务目的，我们很早就认识到可以利用一个主要的技术边界来组织我们的计划。客户的工作负载主要是分析性的，主要处理外部数据以生成洞察力，然后将其出售给客户。因此，我们看到了将转型计划一分为二的机会，一部分围绕数据管理，另一部分围绕数据服务和产品用例，使用数据交互作为接缝。这是确定的第一个高级接缝。
之后，我们需要将计划进一步细分为更小的增量。
在数据管理方面，我们发现数据集的管理在很大程度上是相互独立的；也就是说，虽然存在上游和下游依赖关系，但*在管理过程中数据集之间没有纠缠，即摄取的数据集与其输入文件具有一对一的映射关系。*。
然后，我们与主题专家密切合作，确定了技术实施中的*接缝*（如下所述），以计划如何为任何给定的数据集提供云迁移，最终达到可以按任何顺序交付的程度（数据库写入器处理管道接缝、粗粒度接缝：批处理管道步骤交接作为接缝和最细粒度：数据特征接缝）。只要上游和下游依赖关系可以交换来自新云系统的数据，这些工作负载就可以相互独立地进行现代化改造。
在服务和产品方面，我们发现任何给定的产品都使用了我们客户创建的 80% 的功能和数据集。我们需要找到一种不同的方法。在调查了向客户销售访问权限的方式后，我们发现可以采用“客户细分”的方法来逐步交付工作。这需要找到最初购买了较少百分比的功能和数据的客户子集，从而减少交付第一个增量所需的工作范围和时间。后续增量将建立在先前工作的基础上，从而能够将更多客户群从现状架构切换到目标架构。这需要使用一组不同的接缝和过渡架构，我们将在数据库读取器和下游处理作为接缝中讨论。
实际上，我们对组件进行了全面分析，这些组件从业务角度来看是一个有机的整体，但构建为可以独立迁移到云的独立元素，并将其作为一系列增量计划进行布局。

接缝

我们的过渡架构主要受我们在大型机中发现的遗留接缝的影响。您可以将它们视为代码、程序或模块的连接点。在遗留系统中，它们可能是有意设计在战略位置，以实现更好的模块化、可扩展性和可维护性。如果是这种情况，它们可能会在整个代码中脱颖而出，尽管当一个系统已经开发了几十年时，这些接缝往往会隐藏在代码的复杂性之中。接缝特别有价值，因为它们可以被战略性地用来改变应用程序的行为，例如拦截大型机内的数据流，从而允许将功能卸载到新系统。

确定技术接缝和有价值的交付增量是一个共生过程；技术领域的可能性为我们提供了可用于计划增量的选项，而这些选项反过来又推动了支持该计划所需的过渡架构。在这里，我们在技术细节上更深入一层，讨论我们为客户计划和设计的增量遗留系统替换解决方案。需要注意的是，随着我们获得更多知识，这些解决方案在整个参与过程中不断得到完善；有些解决方案甚至部署到测试环境中，而另一些解决方案只是试点。随着我们在其他大型大型机现代化计划中采用这种方法，这些方法将通过我们最新的实践经验得到进一步完善。

外部接口

我们检查了大型机向数据提供商和我们客户的客户公开的外部接口。我们可以在这些集成点上应用事件拦截，以允许将面向外部的工作负载过渡到云，因此从他们的角度来看，迁移将是静默的。进入大型机的接口有两种类型：用于提供商向我们客户提供数据的基于文件的传输，以及用于客户与产品层交互的基于 Web 的 API 集。

批处理输入作为接缝

我们发现的第一个外部接缝是文件传输服务。
提供商可以通过两种途径传输包含半结构化格式数据的文件：用于文件上传的基于 Web 的 GUI（图形用户界面），与底层文件传输服务交互，或用于程序化访问的基于 FTP 的文件直接传输到该服务。

文件传输服务根据每个提供商和文件确定大型机上的哪些数据集应该更新。这些数据集将依次通过数据集触发器执行相关的管道，这些触发器在批处理作业调度程序上配置。

假设我们可以在云上整体重建每个管道（请注意，稍后我们将更深入地探讨如何将更大的管道分解成可操作的块），我们的方法是在云上构建一个单独的管道，并与大型机双重运行它，以验证它们是否产生相同的输出。在我们的例子中，这是可以通过在文件传输服务上应用额外的配置来实现的，该服务将上传分叉到大型机和云。我们能够使用类似生产的文件传输服务测试这种方法，但使用的是在测试环境中运行的虚拟数据。

这将允许我们在云和大型机上双重运行每个管道，只要需要，以确保没有差异。最终，我们的方法是在文件传输服务上应用额外的配置，防止对大型机数据集的进一步更新，从而使原有管道弃用。我们自己没有测试最后一步，因为我们没有完成端到端管道的重建，但我们的技术主题专家熟悉在文件传输服务上有效弃用大型机管道所需的配置。

API 访问作为接缝

此外，我们对面向外部的 API 采用了类似的策略，在暴露给客户的预先存在的 API 网关周围确定了一个接缝，代表他们进入消费者子系统的入口点。

借鉴双重运行，我们设计的方法是在 HTTPS 调用链的尽可能靠近用户的地方放置一个代理。我们正在寻找能够并行运行两个调用流（原有大型机和云上新构建的 API）并报告其结果的东西。

实际上，我们计划对新产品层使用暗启动，以便通过对其输出进行广泛而持续的监控来尽早获得对工件的信心。我们在第一年没有优先构建这个代理；为了利用它的价值，我们需要在产品级别重建大部分功能。但是，我们打算在 API 层可以运行任何有意义的比较测试后立即构建它，因为该组件将在协调暗启动比较测试方面发挥关键作用。此外，我们的分析强调，我们需要警惕产品层产生的任何副作用。在我们的例子中，大型机产生了副作用，例如计费事件。因此，我们需要对大型机代码进行侵入性更改，以防止重复并确保客户不会被重复计费。

与批处理输入接缝类似，我们可以并行运行这些请求，只要需要。但最终，我们将在代理层使用金丝雀发布，逐个客户地切换到云，从而逐步减少大型机上执行的工作负载。

内部接口

之后，我们对大型机内部的组件进行了分析，以确定我们可以利用哪些特定的接缝将更细粒度的功能迁移到云。

粗粒度接缝：数据交互作为接缝

我们关注的主要领域之一是跨程序的普遍数据库访问。在这里，我们首先确定了对数据库进行写入、读取或同时进行这两项操作的程序。将数据库本身视为接缝，使我们能够分解依赖数据库作为程序之间连接的流。

数据库读取器

关于数据库读取器，为了在云环境中启用新的数据 API 开发，大型机和云系统都需要访问相同的数据。我们分析了被我们选为迁移第一个客户群的第一个候选产品的数据库表，并与客户团队合作交付数据复制解决方案。这使用更改数据捕获 (CDC) 技术将所需表从测试数据库复制到云，以将源同步到目标。通过利用 CDC 工具，我们能够以近乎实时的方式跨云上的目标存储复制所需的数据子集。此外，复制数据还为我们提供了重新设计其模型的机会，因为我们的客户现在可以访问的存储不仅是关系型的（例如，还考虑了文档存储、事件、键值和图形）。访问模式、查询复杂性和架构灵活性等标准有助于确定每个数据子集要复制到的技术堆栈。在第一年，我们构建了从 DB2 到 Kafka 和 Postgres 的复制流。

此时，可以通过从数据库*读取*数据的程序实现的功能可以重建，并在以后逐步迁移到云。

数据库写入器

关于数据库写入器，它们主要由在大型机上运行的批处理工作负载组成，在仔细分析了流经和流出它们的数据后，我们能够应用提取产品线来识别可以相互独立执行的独立域（作为同一流的一部分运行只是一个我们可以更改的实现细节）。

围绕这些原子单元及其各自的接缝进行工作，使其他工作流能够开始在云上重建其中一些管道，并将输出与大型机进行比较。

除了构建过渡架构之外，我们的团队还负责提供一系列服务，供其他工作流用于设计其数据管道和产品。在这种特定情况下，我们在大型机上构建了批处理作业，通过在文件传输服务中删除文件以编程方式执行，这些作业将提取和格式化这些管道在大型机上生成的日志，从而使我们的同事能够通过自动比较测试对其工作进行紧密反馈。在确保结果保持不变之后，我们未来的方法是让其他团队能够逐个切换每个子管道。

子管道生成的结果可能需要在大型机上进行进一步处理（例如，在线交易）。因此，当这些管道稍后在云上完成时，我们选择的方法是使用遗留模拟并将数据复制回大型机，只要依赖于这些数据的功能也被迁移到云上。为了实现这一点，我们正在考虑使用相同的 CDC 工具进行到云的复制。在这种情况下，在云上处理的记录将作为事件存储在流中。让大型机直接使用此流似乎很复杂，无论是构建还是测试系统的回归，并且它需要对遗留代码进行更深入的修改。为了降低这种风险，我们设计了一个适配层，将数据转换回大型机可以使用的格式，就好像这些数据是由大型机本身生成的一样。如果简单明了，这些转换函数可能由您选择的复制工具支持，但在我们的例子中，我们假设我们需要构建自定义软件以及复制工具，以满足云端的额外需求。这是我们看到的一个常见场景，企业借此机会从头开始重建现有流程，以改进它们（例如，提高效率）。

总而言之，与客户端的 SME 密切合作帮助我们挑战了大型机上现有批处理工作负载的实现，并制定了具有更清晰数据边界的替代离散管道。请注意，由于我们已与 SME 定义的边界，我们正在处理的管道没有在相同的记录上重叠。在后面的部分中，我们将检查我们必须处理的更复杂的案例。

粗粒度接缝：批处理管道步骤交接

数据库可能不是您可以使用的唯一接缝。在我们的例子中，我们有数据管道，除了将它们的输出持久化到数据库之外，还将精选数据提供给下游管道以进行进一步处理。

对于这些场景，我们首先确定了管道之间的握手。这些通常包括持久化在平面/VSAM（虚拟存储访问方法）文件中的状态，或者可能是 TSQ（临时存储队列）。以下显示了管道步骤之间的这些交接。

例如，我们正在研究迁移下游管道的方案，该管道读取存储在上游的精选平面文件。大型机上的这个下游管道生成了一个 VSAM 文件，在线交易将查询该文件。由于我们计划在云上构建这个事件驱动的管道，我们选择利用 CDC 工具从大型机中获取这些数据，然后将其转换为云数据管道可以使用的事件流。与我们之前报告的类似，我们的过渡架构需要使用适配层（例如，模式转换）和 CDC 工具将云上生成的结果复制回大型机。

通过使用我们之前确定的这些握手，我们能够为一个示例管道构建和测试这种拦截，并使用相同的方法设计在云上进一步迁移上游/下游管道，使用遗留模拟向大型机提供必要的数据以继续进行下游处理。在这些握手旁边，我们对大型机进行了重要的更改，以允许提取数据并将其反馈回来。但是，我们仍然通过在边缘使用不同的作业触发器来重用核心中的相同批处理工作负载，从而最大限度地降低风险。

细粒度接缝：数据特征

在某些情况下，上述用于查找内部接缝和过渡策略的方法是不够的，正如我们的项目中发生的那样，这是由于我们希望切换的工作负载规模很大，因此转化为更高的业务风险。在我们的一个场景中，我们正在使用一个离散模块来获取数据加载管道的数据：身份管理。

消费者身份管理是一个复杂的领域，在我们的例子中，它是我们客户的差异化因素；因此，他们无法承受新系统对英国和爱尔兰人口的结果不如大型机准确。为了成功地将整个模块迁移到云，我们需要构建数十个身份搜索规则及其所需的数据库操作。因此，我们需要进一步细化，以保持更改较小，并能够频繁交付以降低风险。

我们与 SME 和工程团队密切合作，旨在识别数据和规则中的特征，并将它们用作接缝，这将使我们能够逐步将此模块切换到云。经过分析，我们将这些规则分为两个不同的组：简单和复杂。
简单的规则可以在两个系统上运行，前提是它们使用不同的数据段（即上游的独立管道），因此它们代表了进一步分离身份模块空间的机会。它们代表了在提取文件期间触发的大多数（约 70%）。这些规则负责在已存在的身份和新数据记录之间建立关联。
另一方面，复杂的规则是由数据记录指示需要更改身份的情况触发的，例如创建、删除或更新。这些规则需要谨慎处理，并且不能逐步迁移。这是因为对身份的更新可以由多个数据段触发，并且在两个系统中并行操作这些规则可能会导致身份漂移和数据质量损失。它们需要一个系统在某个时间点生成身份，因此我们设计了一种大爆炸迁移方法。

在我们最初对大型机上身份模块的理解中，提取数据的管道会触发对 DB2 的更改，从而形成对身份、数据记录及其关联的最新视图。

此外，我们确定了一个离散的身份模块，并改进了此模型以反映我们与 SME 发现的更深入的系统理解。此模块从多个数据管道获取数据，并将简单和复杂的规则应用于 DB2。

现在，我们可以应用我们之前为数据管道编写的相同技术，但我们需要对身份管道采用更细粒度和增量的方法。
我们计划处理可以在两个系统上运行的简单规则，但需要注意的是，它们在不同的数据段上运行，因为我们被限制为只有一个系统维护身份数据。我们致力于一种使用批处理管道步骤交接的设计，并应用事件拦截来捕获和分叉数据（临时，直到我们可以确认系统交接之间没有数据丢失）以将数据馈送到大型机上的身份管道。这将允许我们采用分而治之的方法来处理提取的文件，在云上运行并行工作负载，该工作负载将执行简单规则并将更改应用于大型机上的身份，并逐步构建它。简单存储桶下有很多规则，因此我们需要目标身份模块上的功能在尚未实现的规则需要触发时回退到大型机。这看起来像下面这样

随着云身份模块的新版本的发布，我们将看到越来越少的属于简单存储桶的规则通过回退机制应用。最终，只有复杂的规则可以通过该路径观察到。正如我们之前提到的，这些规则需要一次性迁移以最大程度地减少身份漂移的影响。我们的计划是针对云数据库副本逐步构建复杂规则，并通过广泛的比较测试来验证其结果。

一旦构建了所有规则，我们将发布此代码并禁用到大型机的回退策略。请记住，在发布此代码后，大型机身份和关联数据实际上将成为由云身份模块管理的新主存储的副本。因此，需要复制以保持大型机的正常运行。

如前几节所述，我们的设计采用了遗留模拟和反腐败层，可以将数据从大型机模型转换为云模型，反之亦然。该层由跨系统的多个适配器组成，确保数据以流的形式从大型机流出，以便云使用事件驱动的数据管道进行消费，并以平面文件的形式返回到大型机，以允许现有批处理作业处理它们。为了简单起见，上面的图表没有显示这些适配器，但每次数据在系统之间流动时都会实现它们，而不管接缝的粒度如何。不幸的是，我们在这里的工作主要是分析和设计，除了运行 Spikes 以确保可以使用 CDC 工具和文件传输服务以所需格式将数据传入和传出大型机之外，我们无法将其带到下一步并验证我们的假设。在大型机周围构建所需脚手架以及对现有管道进行逆向工程以收集需求所需的时间相当长，超出了该计划第一阶段的时间范围。

细粒度接缝：下游处理交接

类似于用于上游管道为下游批处理工作负载提供数据的方法，遗留模拟适配器被用于在线流的迁移。在现有系统中，客户 API 调用会触发一系列程序，产生副作用，例如计费和审计跟踪，这些副作用会持久化到大型机上的相应数据存储（主要是日志）中。

为了成功地将在线流逐步过渡到云，我们需要确保这些副作用要么由新系统直接处理，从而增加云上的范围，要么提供回大型机的适配器以执行和协调负责它们的底层程序流。在我们的例子中，我们选择了后者使用 CICS Web 服务。我们构建的解决方案针对功能需求进行了测试；跨功能需求（例如延迟和性能）无法验证，因为在第一阶段很难获得类似生产的大型机测试环境。下图显示了，根据我们适配器的实现，迁移客户的流程是什么样的。

值得注意的是，适配器计划是临时脚手架。当云能够自行处理这些副作用时，它们将不再起作用，之后我们计划将数据复制回大型机，只要需要就可以保持连续性。

数据复制以支持新产品开发

在上述增量方法的基础上，组织可能会有产品创意，这些创意主要基于大型机上保存的核心数据的分析数据或聚合数据。在这些情况下，通常不太需要最新信息，例如报告用例或汇总过去一段时间的数据。在这种情况下，可以通过明智地使用数据复制来更早地释放业务效益。
如果做得好，这可以通过早期相对较小的投资来推动新产品的开发，从而为现代化工作带来动力。
在我们最近的项目中，我们的客户已经开始了这段旅程，使用 CDC 工具将核心表从 DB2 复制到云。

虽然这在支持推出新产品方面非常棒，但它并非没有缺点。

除非您在复制数据库时采取措施抽象模式，否则您的新云产品将在构建后立即与遗留模式耦合。这可能会阻碍您可能希望在目标环境中进行的任何后续创新，因为您现在在更改应用程序核心方面遇到了额外的阻力因素；但这一次更糟糕，因为您不想再次投资于更改您刚刚资助的新产品。因此，我们提出的设计包括从副本数据库进一步投影到优化的存储和模式中，新产品将在此基础上构建。

这将使我们有机会重构模式，并有时将部分数据模型移动到非关系型存储中，这可以更好地处理与 SME 观察到的查询模式。

在迁移批处理工作负载时，为了保持所有存储同步，您可能需要考虑以下两种策略之一：一种是直接向新的主数据库（以前称为副本）回写策略，然后主数据库再将数据反馈给大型机上的 DB2（尽管这样一来，批处理与旧模式的耦合度会更高）；另一种是将 CDC 和适配层的方向从优化存储作为源、新主数据库作为目标进行反转（您可能需要分别管理每个数据段的复制，例如，一个数据段从副本复制到优化存储，另一个数据段则反过来）。

结论

从大型机上卸载应用程序时，需要考虑多个因素。根据您希望从大型机上迁移的系统规模，这项工作可能需要相当长的时间，而且增量双运行的成本也不容忽视。成本的高低取决于多种因素，但您不能指望通过并行运行两个系统来节省成本。因此，企业应该着眼于尽早创造价值，以获得利益相关者的支持，并为一项多年的现代化计划提供资金。我们将增量双运行视为团队快速响应业务需求的推动因素，与敏捷和持续交付实践相辅相成。

首先，您必须了解整个系统环境以及系统的入口点是什么。这些接口起着至关重要的作用，允许将外部用户/应用程序迁移到您正在构建的新系统。您可以在迁移过程中自由地重新设计外部契约，但这需要在大型机和云之间建立一个适配层。

其次，您必须确定大型机系统提供的业务功能，并确定实现这些功能的底层程序之间的接缝。以功能为导向有助于确保您不会构建另一个错综复杂的系统，并在适当的层面上保持职责和关注点的分离。您会发现自己正在构建一系列适配器，这些适配器要么公开 API，要么消费事件，要么将数据复制回大型机。这确保了在大型机上运行的其他系统可以继续按原样运行。最佳实践是将这些适配器构建为可重用组件，因为您可以根据自己的特定需求在系统的多个区域中使用它们。

第三，假设您要迁移的功能是有状态的，那么您可能需要一个大型机可以访问的数据副本。这里可以使用 CDC 工具来复制数据。了解数据复制的 CFR（跨功能需求）非常重要，某些数据可能需要一条快速复制通道到云端，而您选择的工具最好能够提供这一点。现在有很多工具和框架可以针对您的具体情况进行考虑和调查。有大量的 CDC 工具可以评估，例如，我们考察了用于 DB2 表的 Qlik Replicate 和更专门用于 VSAM 存储的 Precisely Connect。

云服务提供商也在这个领域推出了新的产品；例如，谷歌云的 Dual Run 最近推出了自己的专有数据复制方法。

如需更全面地了解如何动员团队来交付这种规模的工作计划，请参阅我们的同事 Sophie Holden 撰写的文章“吃掉大象”。

最后，还有其他一些需要考虑的因素，本文中已经简要提及。其中，测试策略将发挥至关重要的作用，以确保您构建的新系统是正确的。自动化测试缩短了构建目标系统的交付团队的反馈循环。比较测试可确保两个系统从技术角度表现出相同的行为。这些策略与合成数据生成和生产数据混淆技术结合使用，可以更好地控制您打算触发的场景并验证其结果。最后但并非最不重要的一点是，生产比较测试可确保随着时间的推移，在双运行中运行的系统会产生与单独运行的遗留系统相同的结果。在需要时，至少要从外部观察者的角度（例如与系统交互的客户）比较结果。此外，我们还可以比较中间系统的结果。

希望本文能让您了解在开始大型机卸载之旅时需要考虑的事项。我们参与的是一项为期多年的计划的最初几个月，我们讨论的一些解决方案还处于非常早期的阶段。尽管如此，我们从这项工作中学到了很多东西，我们认为这些想法值得分享。将您的旅程分解成可行且有价值的步骤总是需要根据具体情况而定，但我们希望我们的经验教训和方法可以帮助您入门，以便您能够更进一步，将其投入生产，并实现您自己的路线图。