你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
将 BizTalk Server 迁移到 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) 发布功能。
Sprint 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。
体系结构设计
虽然 Azure 逻辑应用提供的功能可重用 BizTalk Server 资产，但必须具有新式体系结构设计，才能从更现代的功能中获益。 从功能角度来看，尽可能多地使用业务逻辑。 从产品现代化的角度来看，尽可能多地使用 Azure 集成服务。 对于质量和跨领域问题，建议使用 Azure 完善架构框架。
在此框架下，BizTalk 迁移是任务关键型工作负荷。 这一术语描述的是要求平台具有高可用性的应用资源集合，即这些资源必须始终可用、可运行并能抵御故障。
若要完成 BizTalk 迁移的体系结构设计，请遵循 Azure 上任务关键型工作负荷的设计方法。 有关初始体系结构和拓扑，请查看和使用 Azure 体系结构中心中 Azure 上的基本企业集成中所述的参考体系结构。
若要设置初始环境，请使用 Azure 集成服务登陆区域加速器，该加速器旨在使用典型的企业登陆区域设计构建和部署集成平台。
最小可行项目 (MVP) 定义
MVP 是一个产品版本，具有刚好足够的客户可用功能。 此版本显示了产品收集客户反馈并继续工作的可能性和潜力。 对于 BizTalk 迁移，MVP 定义反映了迭代、波次或冲刺组，这些都是在实现工作功能和满足初始集成工作量方面取得进展所需要的。
建议 MVP 定义包括以下业务成果，这些结果在 Scrum 术语中表示为 Epics：
业务成果 (Epics)
- 你想要实现的主要目标是什么？
- 该 MVP 必须具备哪些功能或特性？
- 什么是业务流程？ 这个问题为优化 BizTalk Server 支持的现有流程提供了机会。
- 有哪些业务决策（例如影响 MVP 的业务成果）？或者，资源可用性如何？
建议 MVP 包括以下作用域内流程，这些进程以 Scrum 术语中的功能表示：
范围内进程（功能）
| Feature | 说明 |
|---|---|
| 高级系统功能 | 可以使用发现工具提取这些信息，并用特征来表达描述。 |
| 演员或角色 | 使用此信息来确定受 MVP 支持方案影响的个人。 |
| 业务流程 | 可以使用发现工具提取此信息。 |
| 数据实体和消息 | 通过这些元素，你可以了解是否可以在 BizTalk Server 环境所交换的数据中包含进一步改进。 |
| 数据映射 | 当今世界依赖于 JSON。 但是，BizTalk Server 使用 XML。 此刻正是决定新平台的数据格式和转换需求的大好时机。 |
| 业务规则 | 这些以数据为中心的规则提供了一个机会，让你重新考虑其方法，或通过使用 Azure Logic Apps 功能重新使用它们。 |
| 数据隐私注意事项 | 必须将隐私作为首要任务。 除非客户在 Azure 逻辑应用（标准）中选择混合部署模型，否则由于潜在的部署环境更改，必须在每个波次中解决此区域问题。 |
| 法规注意事项 | 如果客户没有基于云的工作负载，这一点就更为重要。 |
| 设计安全 | 在设计每项功能时都必须考虑到安全性。 |
| 建议的共存功能 | 交付每一个波次时，都会有一定程度的共存。 必须使这种混合架构与现有的服务级别指标 (SLI) 和服务级别目标 (SLO) 保持一致。 |
| 非功能性注意事项 | 业务流程可能具有不同的非功能要求。 并非所有内容都必须实时发生。 与此同时，并非所有内容都是批处理。 |
| 业务指标 | 展示迁移工作进展的可选机会。 |
你还需要确定并列出影响 MVP 工作范围的各种范围外变量，例如：
- 资源可用性
- 风险
- 文档
- 面市时间
初始积压工作
初始积压工作是一组用户情景，你可以将其分组到功能中，以生成 MVP 的范围内进程。 换句话说，MVP 由称为 Epics（主线）、Feature（功能）和 User Story（用户情景）的 Scrum 项表示。 理想情况下，每个 Epic 都包含一组 BizTalk 应用程序或 BizTalk 项目。 可以使用将一个 BizTalk 应用程序或 BizTalk 项目与一个功能关联起来的简单规则。
例如，假设你有一个 BizTalk Server 项目，其中包含客户用来请求银行贷款的业务流程“LoanRequests”。 因此，你有以下建议的功能和用户情景：
功能：贷款处理
用户情景：“作为客户，我想提交贷款申请，以便银行可以向我的安全帐户添加资金。
此用户情景目前可能作为 BizTalk Server 中的实现存在，需要使用 Azure 逻辑应用和 Azure 集成服务执行以下任务：
- 收集 BizTalk 可重用项目。
- 使用 Azure 逻辑应用创建贷款请求工作流。
- 使用 Azure 服务总线或 IBM MQ 配置异步消息传送。
- 使用 Azure 逻辑应用工作流将 JSON 映射到 XML 数据。
- 根据消息传送模式的需要自定义 Azure 集成服务。
下图显示了“主线”、“功能”、“用户情景”和“任务”的建议持续时间，而“任务”又是“用户情景”的细分。 尽管实现决策会影响这些持续时间，但它们假定你在 Azure 逻辑应用中使用现有的 BizTalk 构件。 尽可能使用预建工作流程模板，创建自己的标准工作流程。
迁移波次（冲刺）
团队完成 Sprint 0 后，应该对要构建的 MVP 有一个清晰的认识。 波次是一组冲刺。 初始积压工作应包括尽可能遵循下图的工作项目：
在波次期间，团队会完成迁移、测试和发布到生产的活动。 让我们更仔细地研究每个波次中发生的情况。
Migrate
在每个波次中，迁移侧重于商定的用户情景。 对于第一波次，你的团队专注于初始积压工作。 技术决策必须使用 BizTalk Server 功能映射中的信息，详见功能匹配 - 为什么从 BizTalk Server 迁移到 Azure 逻辑应用？
下图显示了迁移波次期间应发生的事件：
| 步骤 | 说明 |
|---|---|
| 1 | 发现现有的 BizTalk 应用和接口。 虽然该活动在冲刺 0 中引入，但应在每个波次开始时进行。 客户可能会在 BizTalk 环境中继续进行更改。 资源： - BizTalk 迁移工具 - BizTalk Documenter 工具 |
| 2 | 设置初始迁移环境。 可以使用 Azure 集成服务登陆区域加速器，这是一个云采用框架，它是一个云采用框架，用于构建和部署具有典型企业登陆区设计的集成平台。 作为工作负载所有者，你可以通过使用提供的架构指导和 BizTalk 迁移资源，自信地实现目标技术状态。 有关示例体系结构，请参阅示例迁移环境。 |
| 3 | 使用 Azure 门户或带有 Azure 逻辑应用（标准）扩展的 Visual Studio 代码，创建和测试在单租户 Azure 逻辑应用中运行的标准逻辑应用工作流。 使用 Visual Studio Code，可以使用任何源代码管理系统在本地开发、测试和存储逻辑应用项目。 有关详细信息，请参阅以下文档： - 使用 Azure 门户创建示例标准逻辑应用工作流 - 使用 Visual Studio Code 创建示例标准逻辑应用工作流 有关显示示例逻辑应用和连接的关系图，请参阅示例迁移环境。 |
| 4 | 要想在不同环境和平台上轻松、一致地部署标准逻辑应用工作流，并从中充分受益，还必须实现构建和部署流程的自动化。 适用于 Visual Studio Code 的 Azure 逻辑应用（标准）扩展提供了使用 Azure DevOps 创建和维护自动化生成和部署过程的工具。 如需了解更多信息，请参阅使用 Azure DevOps 自动生成和部署标准逻辑应用工作流。 |
| 5 | 若要部署始终可用且响应迅速的任务关键型标准逻辑应用，即使在更新或维护期间，也应通过创建和使用部署槽位来启用零停机时间部署。 零停机时间意味着在部署新版本的应用时，最终用户不应遇到中断或停机。 如需了解更多信息，请参阅设置部署槽位以在 Azure 逻辑应用中启用零故障时间部署。 |
下图显示了一个示例初始迁移环境，其中包含一个标准逻辑应用，用于协调与 API、服务、混合解决方案和本地资源通信的工作流：
测试
每个波次都有自己的测试活动，这些活动嵌入在每个用户情景中。 如果要使用左移测试，请确保完成以下任务：
自动执行测试。
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 集成服务建立了自动测试。 然后，你可以并行运行测试，以帮助使用相同的数据集检查接口并提高测试的整体准确性。
发布到生产环境
团队完成并满足用户情景的“完成定义”后，请考虑以下任务：
为发布到生产环境创建通信计划。
制定“直接转换”计划。
直接转换计划涵盖了从当前平台切换到新平台所需的任务和活动的详细信息，包括团队计划要执行的步骤。 在直接转换计划中包含以下注意事项：
- 必备的步骤
- 彩排
- People
- 计划估算
- 在旧平台中禁用接口
- 在新平台中启用接口
- 验证测试
确定回滚计划。
运行验证测试。
规划运营或生产支持。
选择“通过或不通过”条件以发布到生产环境。
庆祝团队的成功。
进行回顾。
BizTalk 迁移的最佳做法
虽然最佳实践可能因组织而异，但请考虑有意识地努力促进一致性，这有助于减少“重新发明轮子”的不必要工作和类似通用组件的冗余。 当你帮助启用可重用性时，你的组织可以更快地构建更易于支持的界面。 上市时间是数字化转型的关键推动因素，因此当务之急是减少开发人员与支持团队之间不必要的摩擦。
建立自己的最佳做法时，请考虑遵循以下指南：
Azure 资源的常规命名约定
请确保在从资源组到每种资源类型的所有 Azure 资源中设置并一致地应用良好的命名约定。 为了为可发现性和可支持性打下扎实的基础，良好的命名约定可传达目的。 命名约定最重要的一点是，你已经规定了命名约定，并且你的组织理解这些命名约定。 每个组织都有可能需要考虑的细微差别。
有关此做法的指导，请查看以下 Microsoft 建议和资源：
- Azure 资源的缩写示例
- 可生成符合 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 行为。 在设计器中，可以折叠并展开范围的内容，以提高开发人员的工作效率。
实现此模式时，还可以根据前面操作的执行状态（可以是“成功”、“失败”、“跳过”或“超时”）指定何时运行“作用域”操作以及其中的操作。 若要设置此行为，请使用“作用域”操作的“此后运行”(runAfter) 选项：
- 成功
- 失败
- 已跳过
- 已超时
合并共享服务
生成集成解决方案时，请考虑为常见任务创建和使用共享服务。 你可以进行自己的团建活动，并公开你的项目团队和其他人可以使用的共享服务集合。 每个人都能提高工作效率、统一性，并增强对组织解决方案实施治理的能力。 以下各节介绍了可以考虑引入共享服务的一些方面：
| 共享服务 | 原因 |
|---|---|
| 集中式日志记录 | 提供了有关开发人员如何使用适当的日志记录检测其代码的常见模式。 然后，你可以设置诊断视图，帮助你确定接口运行状况和可支持性。 |
| 业务跟踪和业务活动监视 | 捕获和公开数据，以便业务主题专家可以更好地了解其业务事务的状态，并能够执行自助分析查询。 |
| 配置数据 | 将应用程序配置数据与代码分开，以便更轻松地在环境之间移动应用程序。 请确保提供统一一致且易于重现的方法来访问配置数据，以便项目团队可以专注于解决业务问题，而不是将时间花在应用程序配置上进行部署。 否则，如果每个项目都以独特方式实现这种分离，则无法从规模经济中获益。 |
| 自定义连接器 | 针对在 Azure 逻辑应用中没有预生成连接器的内部系统创建自定义连接器，以便为项目团队和其他人员简化。 |
| 常见数据集或数据馈送 | 作为 API 或连接器公开常见的数据集和源以供项目团队使用，并避免重新发明轮子。 每个组织都有在企业环境中集成系统所需的通用数据集。 |
后续步骤
现在，你已经了解了将 BizTalk Server 工作负载迁移到 Azure 逻辑应用的可用迁移方法和最佳实践。 若要提供有关本指南的详细反馈，可以使用以下表单：