你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

使用 Azure 逻辑应用实现大型机和中型机现代化

本指南介绍组织如何通过使用 Azure 逻辑应用将大型机和中型机环境现代化来提高业务价值和敏捷性。 当前的商业世界正在经历一个高度创新的时代,并在不断追求获得企业效率、成本降低、增长和业务协调。 各组织正在寻找实现现代化的方法,一种有效的策略是在使用现有旧资产的同时增加业务价值。

对于在大型机和中型机系统进行投资的组织,这意味着充分利用将人类送上月球或帮助建立当前金融市场并使用云和人工智能扩展其价值的平台。 在这种情况下,Azure 逻辑应用及其与大型机和中型机系统集成的原生功能将发挥作用,为传统投资打开 AI 世界的大门。 除其他功能外,此 Azure 逻辑应用整合了 Host Integration Server (HIS)(20 多年来,它一直在 Microsoft 最具战略意义的客户的核心被用于大型机和中型机集成)的核心功能。 因此,Azure 逻辑应用成为了大型机和中型机系统的集成平台即服务 (iPaaS) 产品。

当企业开发人员使用 Azure 逻辑应用构建集成工作流时,他们可以更快地交付新的应用程序,而很少或无需编写代码,或使用更少的自定义代码。 使用 Visual Studio Code 和 Visual Studio 的开发人员比使用 IBM 大型机开发工具和技术的人更有效率,因为他们不需要了解大型机系统和基础结构。 Azure 逻辑应用使业务分析师和决策者能够更快地分析和报告重要的旧信息。 他们可以直接访问大型机数据源中的数据,这使得大型机开发人员不再需要创建提取和转换复杂大型机结构的程序。

大型机和中型机系统集成的云原生功能

自 1990 年以来,Microsoft 通过 Microsoft Communications Server 提供与大型机和中型机系统的集成。 Microsoft Communications Server 的进一步演变在 2000 年创造了 Host Integration Server (HIS)。 虽然 HIS 最初作为系统网络体系结构 (SNA) 网关出现,但 HIS 已扩展到包括 IBM 数据存储(DB2、VSAM 和 Informix)、IBM 事务系统(CICS、IMS 和 IBMi)和 IBM 消息传递(MQ 系列)。 Microsoft 的战略客户已使用这些技术 20 多年。

为了使在 Azure 上运行应用程序和数据的客户能够继续使用这些技术,Azure 逻辑应用和 Visual Studio 已逐步整合这些功能。 例如,用于在 Visual Studio 上运行的逻辑应用的 HIS 设计器和 3270 设计工具,可以借助这些功能来创建在 Azure 逻辑应用中形成大型机和中型机集成时使用的内置连接器所需的元数据项目。 这些内置连接器使用与标准逻辑应用工作流相同的计算资源运行。 通过这种设计不仅可以得到低延迟方案,还可以扩展覆盖范围,以满足更多的灾难恢复和高可用性客户需求。

Conceptual diagram showing Microsoft cloud native capabilities for mainframe integration.

有关 Microsoft 大型机和中型机集成功能的详细信息,请继续阅读以下部分。

用于逻辑应用的 Microsoft HIS 设计器

此工具为 Azure 逻辑应用创建大型机和中型机系统元数据项目,并通过提供图形设计器来与 Microsoft Visual Studio 配合使用,使你可以创建、查看、编辑元数据对象并将其映射到大型机项目。 Azure 逻辑应用使用这些映射来镜像大型机和中型机系统中的程序和数据。 有关详细信息,请参阅用于逻辑应用的 HIS 设计器

Microsoft 3270 设计工具

此工具记录应用程序中任务的屏幕、导航路径、方法和参数,使你可以将这些任务作为 3270 连接器操作添加并运行。 虽然用于逻辑应用的 HIS 设计器面向事务系统和数据,但 3270 设计工具面向 3270 应用程序。 有关详细信息,请参阅 3270 设计工具

适用于 IBM 大型机和中型机系统的 Azure 逻辑应用连接器

以下部分介绍了在 Azure 逻辑应用中创建标准工作流时,可用于访问 IBM 大型机和中型机系统并与之交互的基于服务提供商的内置连接器

注意

尽管以下一些连接器可用作在全球 Azure 中运行的“共享”连接器,但本指南侧重于基于服务提供商的内置连接器,这些连接器仅在 Azure 逻辑应用中创建标准工作流时才可用。

IBM 3270

通过此适用于 3270 的 Azure 逻辑应用连接器,标准工作流可访问并运行通常通过导航 3270 仿真器屏幕驱动的 IBM 大型机应用程序。 该连接器使用 TN3270 流。 有关详细信息,请参阅使用 Azure 逻辑应用和 IBM 3270 连接器将 IBM 大型机上的 3270 屏幕驱动的应用与 Azure 集成

IBM 客户信息控制系统 (CICS)

此适用于 CICS 的 Azure 逻辑应用连接器使用多个协议(如 TCP/IP 和 HTTP)提供标准工作流,以便与 CICS 程序交互和集成。 如果需要使用 LU6.2 访问 CICS 环境,则需要使用 Host Integration Server (HIS)。 有关详细信息,请参阅使用 IBM CICS 连接器将 IBM 大型机上的 CICS 程序与 Azure 逻辑应用中的标准工作流集成

IBM DB2

通过此适用于 DB2 的 Azure 逻辑应用连接器,可实现标准工作流与本地或 Azure 中的 DB2 数据库之间的连接。 该连接器为企业 IT 专业人员和开发人员提供直接访问 DB2 数据库管理系统中存储的重要信息的权限。 有关详细信息,请参阅使用 Azure 逻辑应用访问和管理 IBM DB2 资源

IBM 主机文件

此适用于主机文件的 Azure 逻辑应用“连接器”围绕 Host Integration Server 中的“平面文件分析器”功能提供精简包装器。 此脱机“连接器”提供向/从主机文件分析或生成二进制数据的操作。 这些操作要求这些数据来自任何触发器或另一个产生二进制数据的操作。 有关详细信息,请参阅使用 Azure 逻辑应用分析和生成 IBM 主机文件

IBM i

通过这个适用于 IBM i 的 Azure 逻辑应用连接器,标准工作流能够使用 TCP/IP 与在 IBM i 系统上运行的 COBOL 和 RPG 程序进行交互和集成。 如果需要使用 LU6.2 访问 IBM i 环境,需要使用 Host Integration Server (HIS)。 有关详细信息,请参阅使用 IBM i 连接器将 IBM 中型机上的 COBOL 和 RPG 程序与 Azure 逻辑应用中的标准工作流集成

IBM 信息管理系统 (IMS)

此适用于 IMS 的 Azure 逻辑应用连接器使用 IBM IMS Connect 组件,该组件使用 TCP/IP 提供从标准工作流到 IMS 事务的高性能访问。 此模型使用 IMS 消息队列来处理数据。 有关详细信息,请参阅使用 IBM IMS 连接器将 IBM 大型机上的 IMS 程序与 Azure 逻辑应用中的标准工作流集成

IBM MQ

通过此适用于 MQ 的 Azure 逻辑应用连接器,可实现标准工作流与本地或 Azure 中的 IBM MQ 服务器之间的连接。 Microsoft 还提供与 Host Integration Server 和 BizTalk Server 的 IBM MQ 集成功能。 有关详细信息,请参阅从 Azure 逻辑应用中的工作流连接到 IBM MQ 服务器

大型机和中型机系统现代化面临的挑战

大型机和中型机系统可以托管包含程序、数据、文件和工具的多个环境。 多年来,尽管硬件升级,但这些环境可能没有被重构,或者任其发展并达到其限制。 这些环境也可能由多个开发人员和 IT 管理员进行维护,他们遵循不同的编程模式和技术,或者聘请了其他各方来帮助完成需要市场上缺少的专业知识的任务。 随着经验丰富的专业人员数量的减少,所有这些因素都使大型机和中型机环境的现代化工作变得复杂而具有挑战性。

虽然下面的列表并不全面,但定义一个成功的现代化策略至少包括处理以下任务的方法:

  • 为环境维护当前的服务级别指标和目标。
  • 管理旧数据与迁移数据之间的共存。
  • 在共存期间跨环境执行 DevOps。
  • 管理应用程序相互依赖关系。
  • 定义大型机计划程序和作业的未来。
  • 定义用于取代商用现货 (COTS) 产品的策略。
  • 执行混合功能和非功能测试活动。
  • 维护外部依赖项或接口。

考虑到这些任务,客户通常会选择以下任一路径来执行大型机和中型机系统现代化:

  • 大爆炸

    此方法主要基于瀑布软件交付模型,但分阶段进行迭代。 由于代码行数少、应用程序密度低以及众所周知的旧系统或编程语言,使用小的大型机和中型机系统和复杂程度较低的环境的客户更多地采用大爆炸方法。

  • 敏捷波次

    此方法遵循软件工程的敏捷原则。 由于代码行数多、应用程序密度高、不太为人所知的系统或编程语言以及大量的依赖关系和接口,更大的大型机或中型机系统和复杂程度高的环境的客户更多地采用敏捷波次方法。

这些路径之间的选择取决于组织的需求和场景。 每个路径都有需要考虑的优点和缺点。 以下部分提供有关这些现代化方法的详细信息。

大爆炸或瀑布

大爆炸迁移通常具有以下阶段:

Conceptual diagram showing big bang migration phases approach.

  1. 设想:启动

  2. 规划:确定和准备计划可交付结果,例如范围、时间和资源。

  3. 构建:规划可交付结果获得批准后开始

    此阶段还要求所有依赖项的工作都已经确定,然后迁移活动就可以开始了。 进行多次迭代以完成迁移工作。

  4. 稳定或测试:在针对大型机环境中的测试区域测试迁移的环境、依赖项和应用程序时开始。

  5. 部署:所有内容获得批准后,迁移进入生产环境。

通常选择此方法的组织专注于锁定时间、迁移范围和资源。 此路径听起来像是一个良好的选择,但包括以下风险:

  • 迁移可能需要数月甚至数年的时间。

  • 部署到生产环境的风险更大。

  • 在迁移旅程开始时或规划期间执行的分析不再准确,因为该信息通常已过时。

  • 组织通常专注于拥有全面的文档以减少交付风险。

    但是,提供规划项目所花费的时间会产生完全相反的效果。 专注于规划多于执行往往会造成执行延迟,从长远来看,这会导致成本增加。

敏捷波次

敏捷方法以结果为导向,专注于构建软件,而不是规划可交付成果。 敏捷交付的第一阶段可能是混乱和复杂的,因为需要打破组织障碍并使迁移团队保持一致。 然而,当迁移团队执行了几次冲刺而变得成熟之后,旅程会变得更加顺利。 此方法的目标是将功能频繁发布到生产环境,并比使用大爆炸方法更快地提供业务价值。

敏捷波次迁移通常具有以下冲刺:

Conceptual diagram showing mainframe migration with Agile waves approach.

  • 冲刺 0(零)

    • 定义团队、初始工作积压工作和核心依赖项。
    • 确定要交付的功能和最小可行性产品 (MVP)。
    • 使用一组选定的工作项或用户描述启动大型机准备工作,以开始工作。
  • 冲刺 1、2、...、N

    每个冲刺都有一个目标,在这个目标中,团队保持交付思维模式,这意味着他们专注于完成迁移目标并将可交付结果发布到生产环境。 团队可以使用一组冲刺来交付一个特定功能或一波功能。 每个功能都包含集成工作负载的切片。

Conceptual diagram showing mainframe migration with Agile waves per streams.

共享元素(如作业和相互依赖关系)存在于整个环境中并产生影响。 一个成功的策略侧重于部分启用作业、为现代化重新设计应用程序,并将具有最多相互依赖关系的系统留到最后,以首先减少迁移工作量,然后完成现代化工作的范围。

Microsoft 建议将重点放在新平台的投资上,同时限制旧系统的增长,从而按照迭代的、基于敏捷波次的模型来将大型机和中型机系统工作负载现代化。 这种方法通过保留现有业务价值,同时引入现代化的环境,大幅降低实现风险。 这样,你的团队还可以利用技术技能,帮助你的企业提高竞争力。 在此场景中,Azure 逻辑应用可在你的现代化旅程中为你提供帮助。

现代化模式

优秀的设计包含许多要素,例如部件设计和部署中的一致性和连贯性、简化管理和开发的可维护性,以及允许其他应用程序和场景重用组件和子系统的可重用性。 对于云托管应用程序和服务,在设计和实施阶段做出的决策对质量和总拥有成本具有巨大影响。

Azure 体系结构中心提供经过测试的设计和实现模式,这些模式描述了它们所解决的问题、应用模式的注意事项以及基于 Microsoft Azure 的示例。 虽然存在多个设计和实现模式,但大型机现代化最相关的一些模式包括“反腐层”和“Strangler Fig”、“Saga”和“协调”模式。

防损层模式

无论选择哪种现代化方法,你都需要使用 Azure 逻辑应用实现“反腐层”。 此服务成为大型机旧系统与 Azure 之间的一个外层或适配器层。 若要获得有效的方法,请确定要作为大型机集成工作负载集成或共存的大型机工作负载。 为每个集成工作负载创建策略,这是迁移大型机应用程序需要启用的一组接口。

Conceptual diagram showing the Anti-corruption Layer pattern.

有关详细信息,请参阅反腐层

Strangler Fig 模式

实施反腐层后,将逐步实现现代化。 对于此阶段,需要使用“Strangler Fig”模式,在该模式中,识别可以逐步现代化的大型机工作负载或功能。 例如,如果选择使 CICS 应用程序现代化,则不仅必须使 CICS 程序现代化,而且很可能还必须使 3270 应用程序及其相应的外部依赖项、数据和作业现代化。

最终,将大型机系统中的所有工作负载或功能替换为新系统后,你将完成迁移过程,这意味着可以解除旧系统授权。

Conceptual diagram showing the Strangler Fig pattern.

有关详细信息,请参阅 Strangler Fig 模式

Saga 和协调模式

分布式事务(如两阶段提交 (2PC) 协议)要求事务中的所有参与者在事务继续之前提交或回滚。 云混合体系结构在遵循最终一致性方面,比分布式事务模型效果更好。

Saga 设计模式是一种在分布式事务场景中跨服务管理一致性的方法。 Saga 是一系列事务,用于更新每项服务并发布消息或事件来触发下一个事务步骤。 如果某个步骤失败,则 Saga 将执行补偿事务,以抵消上一个事务的影响。 有关详细信息,请参阅 Saga 分布式事务模式

在 Azure 逻辑应用中,工作流可以作为协调者来协调 saga。 工作流操作是原子级的,因此可以单独重新运行它们。 “范围”操作类型提供了仅在一组操作成功或失败后运行另一组操作的功能。 Azure 逻辑应用在范围级别执行补偿事务,而 Azure 事件网格和 Azure 服务总线提供特定域所需的事件管理。 所有这些服务构成了 Azure 集成服务,可以在客户需要可靠的集成平台来执行任务关键型方案时为其提供所需的支持。 有关详细信息,请参阅协调模式

Conceptual diagram showing the SAGA pattern.

尽管本文介绍了几种现代化模式,但复杂的解决方案需要更多模式,而你本身也清楚地了解组织的现代化目标。 虽然扩展旧资产价值的任务颇具挑战,但这种方案是保留这些资产中的投资并延长其业务价值的最佳方式。

后续步骤