共用方式為

将 BizTalk Server 迁移到 Azure 逻辑应用的迁移方法

本指南介绍迁移策略和资源，以及规划注意事项和最佳做法，以帮助你交付成功的迁移解决方案。

注意

有关在 Azure 中为迁移选择服务的迁移概述和指南，请查看以下文档：

策略选项

以下部分介绍各种迁移策略及其优点和缺点：

大爆炸

“大爆炸”或“直接转换”方法需要大量规划，不建议不熟悉 Azure 逻辑应用或有大型系统或解决方案进行迁移的组织使用。 当组织实施新技术堆栈时，通常需要学习新的知识。 如果投资过早或过多，你将没有机会从经验教训中受益，并且无法在不冒大量返工风险的情况下进行调整。

此方法可能还需要更长的时间才能获得或累积价值。 如果已完成某些迁移活动，但由于其他挂起或正在进行的工作而尚未将其发布到生产中，则迁移的项目不会为组织产生价值。

建议仅当拥有小型、低复杂性的 BizTalk 工作负载、了解 BizTalk 环境的主题专家 (SME) 以及当前使用的 BizTalk 功能与 Azure 逻辑应用之间存在直接映射时，才考虑此方法。 拥有 Azure 逻辑应用方面的经验还可以大幅降低遵循此方法的风险。

这种方法为你的组织提供了增量实现价值的机会，但比其他方法更快。 项目团队可以使用回顾来尽早了解技术堆栈。 例如，可以将现有的 BizTalk 接口或项目部署到生产环境，然后了解解决方案的需求，包括管理、可伸缩性、操作和监视。 获得这些知识后，可以规划冲刺以优化现有功能或引入可在后续工作中使用的新模式。

无论采用哪种方法，如果计划迁移到 Azure 集成服务或一般的 Azure，强烈建议在停用服务器基础结构之前，考虑将 BizTalk Server 解决方案重构为无服务器或云原生解决方案。 如果你的组织希望将业务完全转变为云，则此选择是一个很好的策略。

BizTalk Server 和 Azure 逻辑应用具有不同的体系结构。 为了进一步实现解决方案的现代化，可以使用 Azure 集成服务来扩展 Azure 逻辑功能中的功能，以满足客户的核心集成需求。

为了获得更高的投资回报率（ROI），我们建议任何 BizTalk 迁移都尽可能使用 Azure 逻辑应用（标准）中的核心本地功能，并根据需要使用其他 Azure 集成服务进行扩展。 这种组合使其他方案成为可能，例如：

  • 利用具有混合部署功能的 Azure 逻辑应用（标准）实现云本地混合功能
  • Azure 逻辑应用（标准）中的有状态或无状态工作流功能
  • 与 Azure 逻辑应用（标准）中的连接器进行原生、内置（应用内）的大型机和中型机集成
  • 使用 Azure 服务总线发布子消息
  • Azure API 管理中的高级 SOAP 功能

交付 BizTalk 迁移项目

若要完成此类项目，建议遵循迭代或基于波的方法并使用 Scrum 过程。 虽然 Scrum 不包含适用于预冲刺活动的 Sprint 零（Sprint 0）概念，但建议将你的第一个冲刺重点放在团队对齐和技术发现上。 在 Sprint 0 之后，请执行多个迁移冲刺，并专注于向最小可行产品 (MVP) 发布功能。

关系图显示了迁移波。

冲刺 0

在此冲刺期间，建议使用波形规划执行 BizTalk Server 环境发现。 了解项目的广度和深度对于成功至关重要。 以下列表包括 Sprint 0 期间要解决的特定区域：

区域 说明
发现 捕获有关所有接口和应用程序的数据，以便了解需要迁移的接口和应用程序的数量。 还需要为每个接口或进程分配复杂性。 在编目过程中，收集以下信息以确定工作的优先次序：

- 正在使用的适配器

- 正在使用的 BizTalk Server 功能，例如业务活动监视、业务规则引擎、EDI 等

- 自定义代码，例如表达式、映射和管道组件

- 消息吞吐量

- 消息大小

- 依赖项

- 应用程序和系统依赖项
体系结构设计 创建高级体系结构，用作迁移的焦点。 此设计包括满足高级功能和非功能需求的元素。
最小可行产品 (MVP) 定义 定义第一个波形特征。 换句话说，完成第一波后需要支持的过程。
初始迁移积压工作 使用技术阐述定义第一波特征及其工作项。

发现工具

为了帮助你发现迁移，可以使用 Azure Integration Migrationor 命令行工具（也称为 BizTalk 迁移工具），该工具是一个 Microsoft 开源项目。 该工具采用分阶段的方法，帮助你发现将解决方案迁移到云的有用见解和策略。 建议仅在发现和生成报告时使用迁移工具。 还可以考虑使用在该领域提供解决方案的合作伙伴提供的其他产品进行探索。

要使用 BizTalk Server 元素生成清单，还可以使用 Mark Brimble 开发的 BizTalk Documenter。 此工具适用于 BizTalk Server 2020，尽管指出仅支持 BizTalk Server 2016。

  1. 发现

    拉取 BizTalk Server 资源，并标识要迁移的 BizTalk 项目。 读取程序集和绑定文件信息。

    要求：BizTalk Server 应用程序的 MSI 和所有引用的 BizTalk Server 应用程序

  2. Parse

    读取 BizTalk Server 项目并为 BizTalk Server 应用程序生成源数据模型。

  3. 分析

    使用“分析”阶段中的源数据模型生成 Azure 集成服务目标数据模型。 基本上，该工具会查看 BizTalk Server 资源，确定哪些项可以迁移，并生成 Azure 集成服务目标的数据模型。 

  4. Report

    生成一个报表，其中概述了找到的 BizTalk Server 资源和可以迁移的项。 该报告还包含有关源和目标应用程序中内容的详细信息，以及有关转换的任何潜在问题的详细信息。

  5. 转换

    生成 Azure 管理器资源模板和 Azure CLI 脚本，可用于使用目标数据模型在 Azure 中生成应用程序。

  6. 验证

    此阶段当前未内置于该工具中，但你可以运行安装脚本以将应用程序部署到 Azure。 然后，可以评估生成的应用程序是否提供与 BizTalk Server 本地应用程序相同的功能。

下图显示了 Azure Integration Migrator 工具运行的各个阶段：

显示 Azure 集成服务成员服务的阶段的图。

成功迁移的关键团队角色和技能

若要成功将集成工作流从 BizTalk Server 迁移到 Azure Integration Services，请建立一个具有以下重要角色和技能的团队，这些角色和技能跨越多个学科：

角色 技能
项目经理 负责领导整个项目，并在时间和预算的范围内交付商定的范围。
Scrum 领导者 主动管理积压工作，促进项目活动的优先顺序。
架构师 确保项目符合企业体系结构原则，并提供有关如何应对不确定性和障碍的指导。
开发人员 积极致力于将组件从 BizTalk Server 迁移到 Azure Integration Services。
质量保证测试人员 创建测试计划并针对这些计划执行测试。 在项目冲刺规划过程中跟踪、沟通和会审 bug 和缺陷。
用户验收测试人员 (UAT) 提供业务利益干系人，他们可将接口从现有平台移动到新平台，从而确保不会引入回归。
变更管理专家 评估对现有流程和角色的影响。 制定计划，帮助及早缓解任何察觉到的问题。

为了帮助提供前面所述的部分或所有资源，请考虑具有迁移实践经验的合作伙伴。 作为团队成员，他们可以利用他们的技能和专业知识帮助降低风险，缩短上市时间，并使项目更具可预测性。

生成过程规划

对于规划制定，Microsoft 建议包括冲刺和工作项来处理身份验证、日志记录、例外情况处理等基础服务。 包含这些内容有助于避免在开发周期后期因未满足基础需求而导致的返工。 你还希望避免由于需要其他利益干系人做出的决策而阻止开发人员。

以下列表仅涵盖要考虑的一些方面：

区域 说明
身份验证 在深入了解开发周期之前，请解决以下有关身份验证的问题和其他问题。

- 你的组织是否对身份验证方案有任何标准？
- 是否可以在 Azure 中使用托管标识和服务主体？
- 是否允许基本身份验证和 API 密钥？

此活动可能是引入你的企业架构师的好机会，他们可以确保就使用哪种身份验证方案达成明确的协议。
日志记录 请考虑在集中式数据存储库中收集和存储遥测数据，这是集成解决方案使用的常用模式。

例如，Azure 逻辑应用（标准型）可以将遥测数据推送到 Azure Monitor 中的 Application Insights。 Azure 逻辑应用（消耗型）也可以将遥测数据推送到 Log Analytics（也是在 Azure Monitor 中）。 还可以包含跟踪的属性，以便开发人员可以在消息流经集成平台时包含更多上下文。 例如，此数据可能包括工作订单编号、采购订单信息或其他可能对组织有用、有用且相关的任何内容。

可以说，根据组织的需求，每个组织的解决方案可能有所不同。 例如，某些组织希望完全控制记录数据的内容和时间。 在此方案中，可以创建 API 或自定义连接器，然后根据特定的里程碑检测代码。

无论选择哪种方法，请确保开发人员清楚地了解预期，以避免将来的返工。
异常处理 尽早制定策略和一致的模式来处理例外情况和错误，以避免将来返工。 在创建任何逻辑应用之前，请确保尽早明确此区域。 以下列表包括一些在进行异常处理时需要回答的问题：

- 如何使用范围和“在之后运行”设置来检测例外情况？
- 如何使用 result() 表达式更好地了解工作流中发生例外情况的位置，并查找有关根本原因的详细信息？
- 在选择如何捕获例外情况后，希望如何记录此数据并传达给利益干系人？

确保这些决策与前面提到的日志记录策略一致。 理想情况下，你已经建立了一个流程，用于主动在日志记录数据存储中查找新的错误事件。 从那里，你可以响应这些事件并协调例外情况流程。 可能需要筛选出或聚合重复的错误事件，在组织的 IT 服务管理解决方案中记录票证，并选择发送通知的方式。 根据问题的严重性和一天中的时间，你可能会采取不同的通知路径。 可以通过构建工作流来管理此流程，从而实现敏捷性。
Analytics 为了向利益干系人展示解决方案的整体运行状况和卫生状况，请考虑可供利益干系人用来查看的不同镜头，例如：

- 管理人员可能更感兴趣的是整体运行状况、事务计数或数量，以及这些事务产生的业务价值，而不是整体技术细微差别。
- 一线经理可能对整体运行状况更感兴趣，但也可能对技术细节（如性能特征）感兴趣，以确保满足 SLA。
- 支持分析师可能对整体服务运行状况、例外情况和性能瓶颈感兴趣。

在组合分析策略时，请考虑利益干系人以及他们感兴趣的数据类型。 这种思维过程有助于确保跟踪有用和实用的信息，并使该数据可用于报告目的。 如果发现覆盖范围缺口，可能需要重新访问与日志记录相关的工作项，并添加适当的任务来解决这些缺口。
Cadence 在交付集成项目并从这些经验中学习时，请确保捕获不可避免的教训。 在旅程的早期计划修正冲刺或周期，以便尽早更正过程，避免成本过高。 这样，就可以避免在新平台中引入过多的技术债务。

部署规划

在预测和准备部署计划时，可以增加成功部署的机会。 使用 BizTalk Server，在创建所有基础结构和环境后，你将重点转移到解决方案部署上。

使用 Azure 时，这种体验根据要首先考虑的一些活动而异，例如，解决不同环境之间的基础结构部署，其中可能包括不同的 Azure 订阅、Azure 资源组或某种组合，例如：

  • Azure 密钥保管库：机密和访问策略
  • Azure 服务总线：队列、主题、订阅、筛选器和访问策略
  • Azure 应用服务：计划、网络和身份验证

然后，可以专注于不同环境之间的解决方案部署。

测试计划

为了确保利益干系人对你提供的解决方案感到满意，对于任何迁移项目，都需要考虑测试。 与以前的解决方案相比，新解决方案应提供更多价值，且不会出现任何可能影响业务的回归。

对于迁移项目，请考虑以下测试建议：

  • 回答以下问题来建立基线：

    1. 你有现有的测试吗？
    2. 测试是否在没有错误的情况下运行？
    3. 测试结果是否准确？

    若要确信你的团队未引入回归，你需要能够将新平台的结果与现有平台的可靠测试进行比较。 因此，如果还没有基线，请确保建立一个基线。

    当然，你不希望花费大量资源针对即将停用的平台建立测试，但你需要回答以下问题：“如何知道一切都正常运行？”如果出现这种情况，请根据优先级开始建立基线，并创建一个计划来缓解存在差距的领域。

  • 为新平台设置测试策略。

    假设你对基线感到满意，现在可以考虑如何在新平台上进行测试。 如果在建立基线时遇到问题，请借此机会为新平台打下坚实的基础。

    考虑测试新平台时，请将自动化放在首位。 尽管使用平台可以快速生成接口，但依赖手动测试会削弱这些生产力提升。

  • 自动执行测试。

    Azure 逻辑应用（标准型）包括执行自动测试的功能。 以下列表包含在 GitHub 上免费获取的详细信息和资源：

    • 使用 Azure 逻辑应用团队提供的 Azure 逻辑应用（标准型）进行自动测试

      使用 Azure 逻辑应用（标准版），由于底层体系结构基于 Azure Functions 运行时，并且可以在 Azure Functions 可以运行的任何位置运行，因此不再难以执行自动化测试。 可以为在本地或在 CI/CD 管道中运行的工作流编写测试。 有关详细信息，请参阅 Azure 逻辑应用测试框架的示例项目。

      此测试框架包括以下功能：

      • 为 Azure 逻辑应用中的端到端功能编写自动测试。
      • 在工作流运行和操作级别执行精细验证。
      • 将测试签入 Git 存储库，并在本地或在 CI/CD 管道中运行。
      • 模拟 HTTP 操作和 Azure 连接器的测试功能。
      • 将测试配置为使用生产环境中不同的设置值。

    • 集成演练手册：逻辑应用标准测试，作者 Michael Stephenson，Microsoft MVP

      集成演练手册测试框架基于 Microsoft 提供的测试框架，并支持其他方案：

      • 在标准逻辑应用中连接到工作流。
      • 获取回调 URL，以便可以从测试触发工作流。
      • 检查工作流运行的结果。
      • 检查工作流运行历史记录中的操作输入和输出。
      • 插入逻辑应用开发人员可能使用的自动化测试框架。
      • 插入 SpecFlow 以支持逻辑应用的行为驱动开发 (BDD)。

    无论使用哪种自动化方法或资源，你都能很好地实现可重复、一致和自动化的集成测试。

  • 使用静态结果设置模拟响应测试。

    无论是否设置自动测试，都可以使用 Azure 逻辑应用中的静态结果功能在操作级别临时设置模拟响应。 此功能使你可以模拟要调用的特定系统的行为。 然后，你可以单独执行一些初始测试，并减少在业务线系统中创建的数据量。

  • 并行运行测试。

    理想情况下，你已经为 BizTalk Server 环境设置了基线集成测试，并为 Azure 集成服务建立了自动测试。 然后，你可以并行运行测试，以帮助使用相同的数据集检查接口并提高测试的整体准确性。

发布到生产环境

团队完成并满足用户情景的“完成定义”后，请考虑以下任务：

  1. 为发布到生产环境创建通信计划。

  2. 制定“直接转换”计划。

    直接转换计划涵盖了从当前平台切换到新平台所需的任务和活动的详细信息，包括团队计划要执行的步骤。 在直接转换计划中包含以下注意事项：

    • 必备的步骤
    • 彩排
    • 人员
    • 计划估算
    • 在旧平台中禁用接口
    • 在新平台中启用接口
    • 验证测试

  3. 确定回滚计划。

  4. 运行验证测试。

  5. 规划运营或生产支持。

  6. 选择“通过或不通过”条件以发布到生产环境。

  7. 庆祝团队的成功。

  8. 进行回顾。

BizTalk 迁移的最佳做法

虽然最佳实践可能因组织而异，但请考虑有意识地努力促进一致性，这有助于减少“重新发明轮子”的不必要工作和类似通用组件的冗余。 当你帮助启用可重用性时，你的组织可以更快地构建更易于支持的界面。 上市时间是数字化转型的关键推动因素，因此当务之急是减少开发人员与支持团队之间不必要的摩擦。

建立自己的最佳做法时，请考虑遵循以下指南：

Azure 资源的常规命名约定

请确保在从资源组到每种资源类型的所有 Azure 资源中设置并一致地应用良好的命名约定。 为了为可发现性和可支持性打下扎实的基础，良好的命名约定可传达目的。 命名约定最重要的一点是，你已经规定了命名约定，并且你的组织理解这些命名约定。 每个组织都有可能需要考虑的细微差别。

有关这种做法的指导，请查看以下Microsoft建议：

  • 可生成符合 Azure 的名称的 Azure 命名工具，此工具可帮助你对名称进行标准化，并自动执行命名过程。

Azure 逻辑应用资源的命名约定

逻辑应用和工作流的设计提供了一个关键起点，因为此区域为开发人员提供了创建唯一名称的灵活性。

逻辑应用资源名称

若要区分消耗型和标准型逻辑应用资源，可以使用不同的缩写，例如：

  • 消耗型：LACon
  • 标准型：LAStd

从组织的角度来看，可以设计一个命名模式，包括业务部门、部门、应用程序以及部署环境（例如 DEV、UAT、PROD 等），例如：

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

假设你正在开发一个标准逻辑应用，该应用为企业服务业务部门的人力资源部门实现工作流。 可以将逻辑应用资源命名为 LAStd-CorporateServices-HR-DEV，并在适当的情况下使用帕斯卡大小写表示法以保持一致性。

逻辑应用工作流名称

消耗型逻辑应用资源始终仅映射到一个工作流，因此只需一个名称。 标准型逻辑应用资源可以包含多个工作流，因此请设计一个也适用于成员工作流的命名约定。 对于这些工作流，请考虑基于流程名称的命名约定，例如：

Process-<*process-name*>

因此，如果你有实现员工入职任务的工作流（例如创建员工记录），则可以将工作流命名为 Process-EmployeeOnboarding。

下面是设计工作流命名约定的更多注意事项：

  • 遵循工作流的父子模式：在其中突出显示一个或多个工作流之间的某种关系。
  • 考虑工作流是发布还是消耗消息。

工作流操作名称

将触发器或操作添加到工作流时，设计器会自动为该操作分配默认通用名称。 但是，操作名称在工作流中必须是唯一的，因此设计器会在后续操作实例上附加连续的数字后缀，这会降低可读性并导致难以理解开发人员的原始意图。

若要使操作名称更有意义且更易于理解，可以在默认文本后面添加一个简短的任务描述符，并使用帕斯卡大小写表示法实现一致性。 例如，对于“分析 JSON”操作，可以使用 Parse JSON-ChangeEmployeeRecord 等名称。 使用此方法或其他类似方法，你将继续记住操作是“分析 JSON”以及操作的具体用途。 因此，如果需要稍后在下游工作流操作中使用此操作的输出，则可以更轻松地识别和查找这些输出。

注意

对于广泛使用表达式的组织，请考虑不提倡使用空格的命名约定。 Azure 逻辑应用中的表达式语言会将空格替换为下划线 (_) ，这可能会使创作复杂化。 通过事先避免使用空格，有助于减少创作表达式时的摩擦。 请改用短划线或连字符 (-)，这样既可提高可读性，又不会影响表达式的编写。

为了避免以后可能的返工和有关下游依赖项的问题（使用操作输出时产生），请在将操作添加到工作流时立即重命名操作。 通常，在重命名某个操作后，下游操作会自动更新。 但是，Azure 逻辑应用不会自动重命名在执行重命名之前创建的自定义表达式。

连接名称

在工作流中创建连接时，基础连接资源会自动获取一个通用名称，例如 sql 或 office365。 与操作名称一样，连接名称也必须是唯一的。 具有相同类型的后续连接将获取顺序数字后缀，例如 sql-1、 sql-2 等。 这些名称不提供任何上下文，这使得区分和映射与工作流的连接极具挑战性，尤其是对于不了解解决方案空间并必须维护这些工作流的开发人员而言。

因此，有意义且一致的连接名称非常重要，原因如下：

  • 可读性
  • 知识转移和可支持性更轻松
  • 调控

同样，规定命名约定至关重要，尽管格式并不重要。 例如，可以使用以下模式作为指导：

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

作为具体示例，可以在 OrderQueue 逻辑应用工作流中重命名服务总线连接，并将 CN-ServiceBus-OrderQueue 作为新名称。 有关详细信息，请参阅 Turbo360（以前称为 Serverless360）博客文章逻辑应用最佳做法、提示和技巧：#11 连接器命名约定。

使用作用域和“在以下阶段后运行”选项处理例外情况

范围提供对多个操作进行分组的功能，因此你可以实现 Try-Catch-Finally 行为。 “作用域”操作的功能类似于 Visual Studio 中的“区域”概念。 在设计器中，可以折叠并展开范围的内容，以提高开发人员的工作效率。

实现此模式时，还可以根据前面操作的执行状态（可以是“成功”、“失败”、“跳过”或“超时”）指定何时运行“作用域”操作以及其中的操作。 若要设置此行为，请使用“作用域”操作的“此后运行”() 选项：

  • 成功
  • 失败
  • 已跳过
  • 已超时

合并共享服务

生成集成解决方案时，请考虑为常见任务创建和使用共享服务。 你可以进行自己的团建活动，并公开你的项目团队和其他人可以使用的共享服务集合。 每个人都能提高工作效率、统一性，并增强对组织解决方案实施治理的能力。 以下各节介绍了可以考虑引入共享服务的一些方面：

共享服务 原因
集中式日志记录 提供了有关开发人员如何使用适当的日志记录检测其代码的常见模式。 然后，你可以设置诊断视图，帮助你确定接口运行状况和可支持性。
业务跟踪和业务活动监视 捕获和公开数据，以便业务主题专家可以更好地了解其业务事务的状态，并能够执行自助分析查询。
配置数据 将应用程序配置数据与代码分开，以便更轻松地在环境之间移动应用程序。 请确保提供统一一致且易于重现的方法来访问配置数据，以便项目团队可以专注于解决业务问题，而不是将时间花在应用程序配置上进行部署。 否则，如果每个项目都以独特方式实现这种分离，则无法从规模经济中获益。
自定义连接器 针对在 Azure 逻辑应用中没有预生成连接器的内部系统创建自定义连接器，以便为项目团队和其他人员简化。
常见数据集或数据馈送 作为 API 或连接器公开常见的数据集和源以供项目团队使用，并避免重新发明轮子。 每个组织都有在企业环境中集成系统所需的通用数据集。

后续步骤

现在，你已经了解了将 BizTalk Server 工作负载迁移到 Azure 逻辑应用的可用迁移方法和最佳实践。 若要提供有关本指南的详细反馈，可以使用以下表单：

提供有关 BizTalk Server 到 Azure 逻辑应用的迁移指南的反馈