本指南介绍迁移策略和资源，以及规划注意事项和最佳做法，以帮助你交付成功的迁移解决方案。 有关详细信息，请参阅 为什么要从 BizTalk Server 迁移到 Azure Logic Apps？
策略选项
以下部分介绍各种迁移策略及其优点和缺点：
大爆炸
“大爆炸”或“直接转换”是一种需要大量规划的方法，不建议用于不熟悉 Azure Logic Apps 的组织，或需要迁移大型系统或解决方案的场合。 当组织实施新技术堆栈时，通常需要学习新的知识。 如果投资过早或过多，你将没有机会从经验教训中受益，并且无法在不冒大量返工风险的情况下进行调整。
此方法可能还需要更长的时间才能获得或累积价值。 如果您已经完成了一些迁移活动，但由于其他挂起或正在进行的工作尚未将其发布到生产环境中，那么已经迁移的构件不会为组织创造价值。
建议仅当拥有小型、低复杂性的 BizTalk 工作负载、了解 BizTalk 环境的主题专家（SME）以及当前使用的 BizTalk 功能与Azure Logic Apps之间的直接映射时，才考虑此方法。 使用Azure Logic Apps的经验也大大减少了遵循此方法的风险。
迭代或波次式（建议）
这种方法为你的组织提供了增量实现价值的机会，但比其他方法更快。 你的项目团队可以通过使用回顾来尽早了解技术堆栈。 例如，可以将现有的 BizTalk 接口或项目部署到生产环境，然后了解解决方案的需求，包括管理、可伸缩性、操作和监控。 获得这些知识后，可以规划冲刺以优化现有功能或引入可在后续工作中使用的新模式。
无论您采用何种方法，如果计划迁移到 Azure Logic Apps 或常规迁移到 Azure，强烈建议您在停用服务器基础架构之前，将 BizTalk Server 解决方案转型为无服务器或云原生解决方案。 如果你的组织希望将业务完全转变为云，则此选择是一个很好的策略。
BizTalk Server 和Azure Logic Apps具有不同的体系结构。 为了获得更高的投资回报率（ROI），我们建议任何 BizTalk 迁移尽可能地使用 Azure Logic Apps（标准）中的核心本机功能，并根据需要扩展到其他 Azure Integration Services。 这种组合使其他方案成为可能，例如：
- 具有混合部署的 Azure Logic Apps（标准）云原生混合能力
- Azure Logic Apps中的有状态或无状态工作流功能（标准）
- 本机、内置（应用内）大型机和中型机与 Azure Logic Apps（标准）中的连接器集成
- 使用 Azure Service Bus 或 RabbitMQ 进行发布-订阅消息传递
- Azure API Management中的高级 SOAP 功能
- 将逻辑应用转换为 AI 代理工作流
实施 BizTalk 迁移项目
若要完成此类项目，建议遵循迭代方法或波动式方法，并使用Scrum 过程。 虽然 Scrum 不包含适用于预冲刺活动的 Sprint 零（Sprint 0）概念，但建议将你的第一个冲刺重点放在团队对齐和技术发现上。 在 Sprint 0 之后，请执行多个迁移冲刺，并专注于向最小可行产品 (MVP) 发布功能。
冲刺 0
在此冲刺期间，建议使用波形规划执行 BizTalk Server 环境发现。 了解project的广度和深度对于成功至关重要。 以下列表包括 Sprint 0 期间要解决的特定区域：
| 区域 | 说明 |
|---|---|
| 发现 | 捕获有关所有接口和应用程序的数据，以便了解需要迁移的接口和应用程序的数量。 还需要为每个接口或进程分配复杂性。 在编目过程中，收集以下信息以确定工作的优先次序： - 正在使用的适配器 - 正在使用的 BizTalk Server 功能，例如业务活动监视、业务规则引擎、EDI 等 - 自定义代码，例如表达式、映射和管道组件 - 消息吞吐量 - 消息大小 - 依赖项 - 应用程序和系统依赖项 |
| 体系结构设计 | 创建高级体系结构，用作迁移的焦点。 此设计包括满足高级功能和非功能需求的元素。 |
| 最小可行产品 (MVP) 定义 | 定义第一个波形特征。 换句话说，完成第一波后需要支持的过程。 |
| 初始迁移积压工作 | 使用技术阐述定义第一波特征及其工作项。 |
发现工具
为了帮助你进行迁移发现，可以使用 Azure Integration Migrator 命令行工具（也称为 BizTalk 迁移工具），这是 Microsoft 的开源项目。 该工具采用分阶段的方法，帮助你发现将解决方案迁移到云的有用见解和策略。 建议仅在发现和生成报告时使用迁移工具。 还可以考虑使用在该领域提供解决方案的合作伙伴提供的其他产品进行探索。
若要使用 BizTalk Server 元素生成清单的另一种方法，可以使用 Mark Brimble 开发的 BizTalk Documenter。 此工具适用于 BizTalk Server 2020，尽管指出仅支持 BizTalk Server 2016。
最小可行项目（MVP）定义
MVP 是一个产品版本，具有刚好足够的客户可用功能。 此版本显示了产品收集客户反馈并继续工作的可能性和潜力。 对于 BizTalk 迁移，MVP 定义反映了迭代、波次或冲刺组，这些都是在实现工作功能和满足初始集成工作量方面取得进展所需要的。
建议 MVP 定义包括以下业务成果，这些结果在 Scrum 术语中表示为 Epics ：
业务成果 (Epics)
- 你想要实现的主要目标是什么？
- 该 MVP 必须具备哪些功能或特性？
- 什么是业务流程？ 这个问题为优化 BizTalk Server 支持的现有流程提供了机会。
- 有哪些业务决策（例如影响 MVP 的业务成果）？或者，资源可用性如何？
建议 MVP 包括以下作用域内流程，这些进程以 Scrum 术语中的 功能 表示：
范围内进程（功能）
| 功能 / 特点 | 说明 |
|---|---|
| 高级系统功能 | 可以使用发现工具提取这些信息，并用特征来表达描述。 |
| 演员或角色 | 使用此信息来确定受 MVP 支持方案影响的个人。 |
| 协同编排 | 可以使用发现工具提取此信息。 |
| 数据实体和消息 | 通过这些元素，你可以了解是否可以在 BizTalk Server 环境所交换的数据中包含进一步改进。 |
| 数据映射 | 当今世界依赖于 JSON。 但是，BizTalk Server 使用 XML。 此刻正是决定新平台的数据格式和转换需求的大好时机。 |
| 业务规则 | 这些以数据为中心的规则让你有机会重新思考其方法，或者通过采用Azure Logic Apps功能来重复使用它们。 |
| 数据隐私注意事项 | 必须将隐私作为首要任务。 除非客户在Azure Logic Apps（标准）中选择混合部署模型，否则由于潜在的部署环境更改，必须在每波中解决此区域问题。 |
| 法规注意事项 | 如果客户没有基于云的工作负载，这一点就更为重要。 |
| 安全设计 | 在设计每项功能时都必须考虑到安全性。 |
| 建议的共存功能 | 交付每一个波次时，都会有一定程度的共存。 必须使这种混合架构与现有的服务级别指标 (SLI) 和服务级别目标 (SLO) 保持一致。 |
| 非功能性注意事项 | 业务流程可能具有不同的非功能要求。 并非所有内容都必须实时发生。 与此同时，并非所有内容都是批处理。 |
| 业务指标 | 展示迁移工作进展的可选机会。 |
你还需要确定并列出影响 MVP 工作范围的各种范围外变量，例如：
- 资源可用性
- 风险
- 文档
- 面市时间
初始积压工作
初始待办事项是一组用户故事，你可以将其分组到功能中，以生成适用于 MVP 的范围内流程。 换句话说，MVP 由称为 Epics（主线）、Feature（功能）和 User Story（用户情景）的 Scrum 项表示。 理想情况下，每个 Epic 都包含一组 BizTalk 应用程序或 BizTalk 项目。 可以使用将一个 BizTalk 应用程序或 BizTalk project与功能关联的简单规则。
例如，假设你有一个 BizTalk Server 项目，其中包含一个名为“LoanRequests”的编排，客户用来请求银行贷款。 因此，你有以下建议的功能和用户情景：
功能：贷款处理
用户情景：“作为客户，我想提交贷款申请，以便银行可以向我的安全帐户添加资金。
此用户情景（目前可能作为 BizTalk Server 中的实现）具有以下任务，用于使用 Azure Logic Apps 和 Azure Integration Services 实现：
- 收集 BizTalk 可重用工件。
- 使用Azure Logic Apps创建贷款请求工作流。
- 使用 Azure Service Bus 或 IBM MQ 配置异步消息传送。
- 使用Azure Logic Apps工作流将 JSON 映射到 XML 数据。
- 根据需要自定义 Azure 集成服务的消息传递模式。
下图显示了“主线”、“功能”、“用户情景”和“任务”的建议持续时间，而“任务”又是“用户情景”的细分。 尽管实现决策会影响这些持续时间，但它们假定你在 Azure Logic Apps 中使用现有的 BizTalk 工件。
迁移波次（冲刺）
团队完成 Sprint 0 后，应该对要构建的 MVP 有一个清晰的认识。 波次是一组冲刺。 初始积压工作应包括尽可能遵循下图的工作项目：
在波次期间，团队会完成迁移、测试和发布到生产的活动。 让我们更仔细地研究每个波次中发生的情况。
Migrate
在每个波次中，迁移侧重于商定的用户情景。 对于第一波次，你的团队专注于初始积压工作。 技术决策必须使用 BizTalk Server 功能映射中的信息，详见功能匹配 - 为什么从 BizTalk Server 迁移到 Azure Logic Apps。
下图显示了迁移波次期间应发生的事件：
| 步骤 | 说明 |
|---|---|
| 1 | 发现现有的 BizTalk 应用和接口。 虽然该活动在冲刺 0 中引入，但应在每个波次开始时进行。 客户可能会在 BizTalk 环境中继续进行更改。 资源： - BizTalk 迁移工具 - BizTalk Documenter 工具 |
| 2 | 设置初始迁移环境。 可以使用 Azure Integration Services 登陆区域加速器，这是一种云采用框架，用于构建和部署具有典型企业登陆区域设计的集成平台。 作为工作负荷所有者，您可以使用提供的架构指导和 BizTalk 迁移资源，自信地实现目标技术状态。 有关示例体系结构，请参阅示例迁移环境。 |
| 3 | 使用 Azure portal 或结合 Azure Logic Apps（Standard）扩展的 Visual Studio Code，创建和测试运行在单租户 Azure Logic Apps 中的标准逻辑应用工作流。 使用 Visual Studio Code，可以使用任何源代码管理系统在本地开发、测试和存储逻辑应用project。 有关详细信息，请参阅以下文档： - 使用 Azure portal 创建标准逻辑应用工作流 - 使用 Visual Studio Code 创建标准逻辑应用工作流 若要使用 BizTalk 应用程序源代码和绑定开始快速迁移，请使用 BizTalk 迁移初学者。 借助此工具，可以快速为迁移构建概念证明，帮助降低迁移的风险和波数。 此工具创建类似于 BizTalk 业务流程的逻辑应用工作流定义。 对于基于内容的路由方案（CBR），该工具也会创建工作流。 有关显示示例逻辑应用工作流和连接的关系图，请参阅 示例迁移环境。 |
| 4 | 要想在不同环境和平台上轻松、一致地部署标准逻辑应用工作流，并从中充分受益，还必须实现构建和部署流程的自动化。 Visual Studio Code 的 Azure Logic Apps（标准）扩展提供了使用 Azure DevOps 创建和维护自动化生成和部署过程的工具。 |
| 5 | 若要部署始终可用且响应迅速的任务关键型标准逻辑应用，即使在更新或维护期间，也应通过创建和使用部署槽位来启用零停机时间部署。 零停机时间意味着在部署新版本的应用时，最终用户不应遇到中断或停机。 有关详细信息，请参阅 在 Azure Logic Apps 中设置部署插槽以启用零停机部署。 |
下图显示了一个示例初始迁移环境，其中包含一个标准逻辑应用，用于协调与 API、服务、混合解决方案和本地资源通信的工作流：
下图显示了一个示例初始迁移环境，其中包含一个本地部署的标准逻辑应用，用于协调用于与 API、服务、混合解决方案和本地资源通信的工作流：
测试您的迁移
每个 波形 都有自己的测试活动，这些活动嵌入在每个用户情景中。 若要使用 左移测试，请遵循以下指南：
使用 Visual Studio Code 在 Azure Logic Apps 中创建标准工作流中的单元测试。
对于此任务，请创建一个示例标准逻辑应用工作流，可以在单租户Azure Logic Apps中运行，方法是将 Visual Studio Code 与 Azure Logic Apps （Standard） 扩展配合使用。 请按照 使用 Visual Studio Code 创建标准逻辑应用工作流的步骤操作。
对逻辑应用和数据映射使用单元测试代理配置文件。
单元测试代理配置文件是一组重点代理，可帮助你发现工作流和映射、编写可重用规范、生成类型化模拟和测试数据，以及为 Azure Logic Apps 标准项目实现 MSTest 套件。 按照 介绍逻辑应用和数据映射的单元测试代理配置文件中的步骤进行。
部署
团队完成用户故事并满足其“完成定义”后，请考虑以下任务：
为发布到生产环境创建通信计划。
制定“切换”计划。
直接转换计划涵盖了从当前平台切换到新平台所需的任务和活动的详细信息，包括团队计划要执行的步骤。 在切换计划中包含以下注意事项：
- 必备的步骤
- 彩排
- 人员
- 计划估算
- 在 BizTalk Server 环境中禁用接口
- 在逻辑应用环境中启用接口
- 验证测试
确定回滚计划。
运行验证测试。
规划运营或生产支持。
选择“通过或不通过”条件以发布到生产环境。
庆祝团队的成功。
进行回顾。
BizTalk 迁移的最佳做法
虽然最佳实践可能因组织而异，但请考虑有意识地努力促进一致性，这有助于减少“重新发明轮子”的不必要工作和类似通用组件的冗余。 当你帮助启用可重用性时，你的组织可以更快地构建更易于支持的界面。 上市时间是数字化转型的关键推动因素，因此当务之急是减少开发人员与支持团队之间不必要的摩擦。
建立自己的最佳做法时，请考虑遵循以下指南：
Azure资源的常规命名约定
请确保在所有Azure资源（从资源组到每个资源类型）中设置和一致地应用良好的命名约定。 为了为可发现性和可支持性打下扎实的基础，良好的命名约定可传达目的。 命名约定最重要的一点是，你已经规定了命名约定，并且你的组织理解这些命名约定。 每个组织都有可能需要考虑的细微差别。
有关这种做法的指导，请查看以下Microsoft建议：
- Azure命名工具，它生成Azure兼容的名称，有助于标准化名称，并自动执行命名过程。
Azure Logic Apps资源的命名约定
逻辑应用和工作流的设计提供了一个关键起点，因为此区域为开发人员提供了创建唯一名称的灵活性。
逻辑应用资源名称
若要区分消耗型和标准型逻辑应用资源，可以使用不同的缩写，例如：
- 消费：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”操作，可以使用诸如“解析 JSON-更改员工记录”的名称。 使用此方法或其他类似方法，你将继续记住操作是“分析 JSON”以及操作的具体用途。 因此，如果需要稍后在下游工作流操作中使用此操作的输出，则可以更轻松地识别和查找这些输出。
注意事项
对于广泛使用表达式的组织，请考虑不提倡使用空格的命名约定。 Azure Logic Apps中的表达式语言将空格替换为下划线('_')，这可能会使创作复杂化。 通过事先避免使用空格，有助于减少创作表达式时的摩擦。 请改用短划线或连字符 (-)，这样既可提高可读性，又不会影响表达式的编写。
为了避免以后可能的返工和有关下游依赖项的问题（使用操作输出时产生），请在将操作添加到工作流时立即重命名操作。 通常，在重命名某个操作后，下游操作会自动更新。 但是，Azure Logic Apps在执行重命名之前不会自动重命名创建的自定义表达式。
连接名称
在工作流中创建连接时，基础连接资源会自动获取一个通用名称，例如 sql 或 office365。 与操作名称一样，连接名称也必须是唯一的。 具有相同类型的后续连接将获取顺序数字后缀，例如 sql-1、 sql-2 等。 这些名称不提供任何上下文，这使得区分和映射与工作流的连接极具挑战性，尤其是对于不了解解决方案空间并必须维护这些工作流的开发人员而言。
因此，有意义且一致的连接名称非常重要，原因如下：
- 可读性
- 知识转移和可维护性更轻松
- 调控
同样，规定命名约定至关重要，尽管格式并不重要。 例如，可以使用以下模式作为指导：
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
作为具体示例，可以将 OrderQueue 逻辑应用工作流中的Service Bus连接重命名为新名称CN-ServiceBus-OrderQueue。 有关详细信息，请参阅 Turbo360（以前称为 Serverless360）博客文章逻辑应用最佳做法、提示和技巧：#11 连接器命名约定。
使用作用域和“之后运行”选项处理例外情况
作用域提供对多个操作进行分组的功能，以便你可以实现 Try-Catch-Finally 行为。 在设计器中，可以折叠并展开范围的内容，以提高开发人员的工作效率。
实现此模式时，还可以根据前面操作的执行状态（可以是“成功”、“失败”、“跳过”或“超时”）指定何时运行“作用域”操作以及其中的操作。 若要设置此行为，请使用Scope操作的“运行后 (runAfter)”选项：
- 是成功的
- 失败
- 已跳过
- 已超时
合并共享服务
生成集成解决方案时，请考虑为常见任务创建和使用共享服务。 你可以让你的团队构建并公开一个共享服务的集合，以供你的项目团队和其他团队使用。 每个人都能提高工作效率、统一性，并增强对组织解决方案实施治理的能力。 以下各节介绍了可以考虑引入共享服务的一些方面：
| 共享服务 | 原因 |
|---|---|
| 集中式日志记录 | 提供了有关开发人员如何使用适当的日志记录检测其代码的常见模式。 然后，你可以设置诊断视图，帮助你确定接口运行状况和可支持性。 |
| 业务跟踪和业务活动监视 | 捕获和公开数据，以便业务主题专家可以更好地了解其业务事务的状态，并能够执行自助分析查询。 |
| 配置数据 | 将应用程序配置数据与代码分开，以便更轻松地在环境之间移动应用程序。 确保提供统一、一致且易于复制的方法来访问配置数据，以便项目团队可以专注于解决业务问题，而不是花时间处理应用程序配置以进行部署。 否则，如果每个项目都以独特方式进行这种分离，将无法受益于规模经济。 |
| 自定义连接器 | 为Azure Logic Apps中没有预构建连接器的内部系统创建自定义连接器，以简化项目团队及其他人员的操作。 |
| 常见数据集或数据馈送 | 将常用数据集和源公开为 API 或连接器，供项目团队使用，并避免重复造轮子。 每个组织都有在企业环境中集成系统所需的通用数据集。 |
后续步骤
你详细了解了将 BizTalk Server 工作负载迁移到Azure Logic Apps的可用迁移方法和最佳做法。 若要提供有关本指南的详细反馈，请使用以下形式：