Azure 逻辑应用 是 BizTalk Server 的继任者。 Azure 逻辑应用 Standard 为云解决方案提供工作流编排、企业集成和扩展性。 本文总结了迁移的原因、可用的托管选项以及您需要评估的BizTalk功能。
有关迁移策略、规划考虑和交付指导，请参见《用 Azure 逻辑应用 迁移代理迁移 BizTalk Server》。
BizTalk Server生命周期
BizTalk Server 2020 是 BizTalk Server 的最终版本。 Microsoft预计BizTalk Server 2020的销售将于2027年3月31日结束。 主流支持将持续至2028年4月12日，之后产品仍受Microsoft固定生命周期策略的约束。
Microsoft还计划从2028年4月13日至2030年4月10日，为符合条件的客户提供可选的付费扩展主流支持。 该服务旨在作为临时迁移保障，预计将排除部分 BizTalk 功能，并受最终资格、保障、定价和购买条款的约束。
尤其是如果您的解决方案依赖业务活动监控（BAM）、企业服务总线（ESB）工具包、行业加速器、遗留企业适配器、BizTalk专用应用生命周期管理工具，或2022 Visual Studio以后的Visual Studio版本，应尽早开始迁移规划。 这些功能预计将被排除在付费的扩展主流支持之外，或者可能需要重新设计。
最新日期和条款请参见：
为什么 Logic Apps Standard 适合 BizTalk 工作负载
BizTalk应用通常结合了持久的编排、消息传递、转换、企业对企业（B2B）处理、定制代码以及对私有系统的访问。 Azure 逻辑应用 Standard 在单租户运行时中提供了这些集成能力，并支持有状态和无状态的工作流。 与消耗逻辑应用不同，标准逻辑应用可以包含多个共享计算、存储、网络和配置的工作流程。
以下功能使 Standard 成为大多数 BizTalk 现代化项目首选的逻辑应用资源类型：
| BizTalk 要求 | 逻辑应用标准功能 |
|---|---|
| 持久且长期运行的业务流程 | 有状态工作流能够持久化运行状态，并能恢复中断的运行。 无状态工作流支持低延迟的内存处理，当不需要持久性时。 |
| 相关集成过程 | 多个工作流程可以在一个标准逻辑应用中运行，并共享资源、配置和部署边界。 |
| 企业消息与数据格式 | 内置连接器和操作支持诸如 Azure 服务总线、Event Hubs、SQL Server、XML、平面文件、转换和 B2B 场景等服务。 |
| 自定义实现逻辑 | .NET 本地函数可在同一项目和应用程序边界内与工作流一起运行工作流范围内的代码。 内联脚本、自定义内置连接器和外部服务还提供其他可扩展选项。 |
| 私人与本地连接 | 专用单租户执行支持虚拟网络集成和私有端点。 |
| 应用程序生命周期管理 | Visual Studio Code 开发、本地测试、基础设施即代码和 CI/CD 将工作流应用的部署与基础设施配置分开。 |
| 部署选择 | 使用 Workflow Service Plan 进行托管式 Azure 托管，或使用 应用服务环境 v3 进行隔离的 Azure 托管。 |
Logic Apps Standard 提供实现 BizTalk 解决方案现代化所需的大部分核心功能，并充当目标体系结构的主要编排和集成平台。 其他服务默认不是必需的。 对于 Azure 托管的解决方案，只有当重构后的解决方案需要独立消息代理、API 生命周期管理或事件分发时，才添加 Azure 服务总线、Azure API 管理 或 Azure 事件网格 等 Azure 服务。
迁移原因
| 好处 | 描述 |
|---|---|
| 现代集成平台 | 构建包含托管编排、企业连接器、B2B能力、API集成以及云原生安全与监控的工作流程。 在支持的情况下评估AI辅助和代理自动化。 |
| 保留部分投资 | 重用或适配许多 BizTalk 的模式、地图、规则、程序和自定义 .NET 组件，而不是重建每一个工件。 |
| 低代码与专业代码开发 | 将可视化工作流设计器与源代码控制的工作流定义、内联脚本、.NET 本地函数、自定义连接器和外部服务结合起来。 |
| 新式运维 | 使用 Azure 基于角色的访问控制（Azure RBAC）、基础结构即代码和自动化管道。 Azure托管的工作流与 Azure Monitor 和 Application Insights 集成。 |
| 成本控制 | 在相关工作流程间共享容量，选择符合工作负载需求的托管模式，并尽可能使用内置操作和本地功能。 |
构建一个成本效益高的目标架构
成本效益取决于工作负载量、所需的隔离、现有基础设施、连接器使用情况以及运营责任。 比较总体拥有成本，而不是只看 Logic Apps 托管费用。 BizTalk基线可以包括BizTalk Server、Windows Server和SQL Server许可证;计算和存储;高可用性和灾难恢复;补丁;监控;部署工具;以及专业的运营支持。
在构建目标成本模型时，请采用以下做法：
- 将具备兼容安全性、生命周期和扩展需求的相关工作流归组在同一标准逻辑应用中，以便共享预留的计算和支持资源。 当工作负载需要独立扩展、隔离、部署或归属时，应将它们彼此分开。
- 当内置连接器操作能够满足你的需求时，请优先使用它们。 标准版包含无限次内置操作执行，而托管连接器操作则按每次调用计费。
- 在适当情况下，将工作流范围的 .NET 代码保留在本地函数中。 本地功能使用Logic Apps Standard应用边界，不需要单独的功能应用、端点、认证流程、部署流水线或监控边界。 标准套餐中该代码仍然占用容量。
- 合理调整工作流服务计划的容量，并在各批次迁移进入生产环境时评估利用率。 即使工作流处于空闲状态，计划也会按预留容量计费。
- 如果出于隔离、专用网络、合规性或整合方面的要求而有必要采用 Isolated v2 App Service 计划，请使用 应用服务环境 v3。 不要以为ASE v3是小负载中成本最低的选择。
- 考虑存储操作、集成账户、网络、监控，以及迁移期间并行运行 BizTalk 和逻辑应用的临时成本。
有关定价详情，请参见 Azure 逻辑应用 定价和计费模型以及 Azure 逻辑应用 定价页面。
选择托管选项
Azure 逻辑应用 有独立的 Consumption 和 Standard 资源类型。 对于 BizTalk 迁移，请使用Azure 逻辑应用标准功能，并根据要求选择Azure托管的托管选项。
Important
如果您目前使用 Azure 逻辑应用 Consumption，并计划迁移 BizTalk Server 工作负载，您必须迁移到 Azure 逻辑应用 Standard。 BizTalk的迁移功能不支持消费类工作流程。
| 托管选项 | 特别适合 | 成本与所有权 | 重要注意事项 |
|---|---|---|---|
| 工作流服务计划 | 对于需要专用 Standard 容量和 Azure 托管功能的 Azure 托管 BizTalk 迁移，这是默认的首选方案。 | 在由 Microsoft 管理的环境中预留 WS1、WS2 或 WS3 容量。 | 支持每个逻辑应用的多工作流、虚拟网络集成、私有端点以及访问 Azure 监控功能。 |
| 应用服务环境 v3 | 需要隔离的 Azure 托管环境、专用网络、合规边界，或需要与其他 App Service 工作负载整合的工作负载。 | 专用环境中的隔离 v2 应用服务计划实例。 | 需要现有或新的ASE v3，并应以隔离、规模或整合要求为依据。 |
将 BizTalk 功能映射到 Logic Apps
BizTalk Server 和 Azure 逻辑应用 采用不同的架构。 使用迁移代理对每个 BizTalk 应用进行盘点，将其产物和集成模式映射到 Logic Apps 的功能，并识别需要重用、重构、替换或重新设计的组件。
| BizTalk 功能 | Logic Apps 现代化路径 | 典型评估 | 相关指南 |
|---|---|---|---|
| 协同编排 | 有状态或无状态的标准工作流 | 将业务流程逻辑重构为工作流。 | 创建标准工作流程 |
| 管道与辅助代码 | 工作流操作、.NET 本地函数、内联代码、自定义连接器或外部服务 | 根据所需的生命周期和规模边界，重用或重构。 | 创建并运行 .NET 本地函数 |
| 消息箱路由 | Azure 服务总线 主题和订阅、RabbitMQ 交换器、Apache Kafka 主题或工作流路由 | 独立于工作流程运行时重新设计消息。 | 服务总线队列、主题和订阅 |
| 架构和映射 | 项目工件、XSLT 映射、Liquid 模板和数据映射器 | 重用兼容的工件并验证转换。 | 架构和映射 |
| 业务规则 | Azure 逻辑应用规则引擎 | 可重用支持的BizTalk商业规则引擎政策或重构未受支持的事实。 | Azure 逻辑应用 规则引擎概述 |
| EDI与B2B | 标准工作流、连接器和集成账户 | 评估合作伙伴、协定、证书、架构和协议要求。 | B2B企业集成工作流程 |
| 适配器 | 内置、托管或自定义连接器和API | 确认连接器的可用性、认证、吞吐量和托管支持。 | 连接器概述 |
| 跟踪与监控 | 运行历史、跟踪属性、Azure Monitor、Application Insights 和 OpenTelemetry | 重构运营和支持模型。 | 监控逻辑应用和工作流程 |
下图提供了常见BizTalk Server能力及其Azure托管现代化路径的另一种视图：
有关详细功能可用性，请参见 Azure 逻辑应用 连接器、Enterprise integration 概览以及 Azure 逻辑应用 限制与配置。
主要迁移考虑因素
架构与可靠性
- 从Azure 逻辑应用 Standard作为目标应用开始。 在适当情况下使用原生工作流程能力、内置连接器和本地功能，只有在特定架构需求需要时才添加其他 Azure 集成服务。
- 对于发布-订阅模式，可以使用消息代理，如 Azure 服务总线、RabbitMQ 或 Apache Kafka，而不是在工作流程中复制 BizTalk 消息框。
- 为重试和至少一次处理而设计。 使用幂等性、去重和安全写入，以防止在操作被重试或运行被重新提交时产生重复影响。
- 查看消息和连接器限制。 对于大型有效载荷，支持时使用连接器分块或实现 声明检查模式。
- 可以使用VPN 网关、ExpressRoute或其他混合连接设计，将本地网络连接到Azure。 虚拟网络对等互连可连接 Azure 虚拟网络；但其本身并不能单独将本地网络连接到 Azure。
自定义代码
BizTalk解决方案中包含自定义代码并不意味着目标架构就必须单独使用Azure Functions资源。 对于属于集成工作流程的代码，可以使用 .NET 的本地函数。 本地功能与工作流处于同一项目中，运行在逻辑应用标准的应用边界内。 工作流程、连接器、配置和代码可以协同构建、部署、扩展和运行。
本地函数适用于按工作流程范围进行消息验证、丰富、计算、自定义解析、格式化以及业务特定处理。 当这些代码属于某个特定的集成应用程序时，他们还可以帮助将 BizTalk 辅助程序集、业务流程编排实用工具以及管道相关逻辑实现现代化。 这种方法避免了仅在运行特定工作流代码时引入独立的端点、认证流程、托管资源、部署流水线和监控边界。
请参考以下指导选择合适的代码托管模型：
| 何时使用局部函数 | 在以下情况下使用单独的 Azure Functions 资源 |
|---|---|
| 该代码针对一个 Logic Apps Standard 应用程序。 | 代码由多个应用程序、工作流程或团队共享。 |
| 该代码用于验证、丰富、解析、格式化或计算工作流程中的数据。 | 该代码提供了独立管理的API、服务或事件驱动的计算能力。 |
| 工作流程和代码应当同步部署、扩展和运行。 | 该代码需要独立扩展、版本控制、部署或运营所有权。 |
| 代码不需要单独的网络端点或认证边界。 | 代码必须暴露并保护自身的端点或身份边界。 |
| BizTalk 辅助工具或与流水线相邻的逻辑属于迁移后的集成流程。 | 代码才是主要的计算负载，而 Logic Apps 工作流只是其中一个使用方。 |
本地函数消耗标准逻辑应用分配的计算容量，并不能替代所有独立功能或服务。 它们的成本和运营优势来自于避免在代码成为工作流程一部分时不必要的资源边界。 标准工作流程还支持内联JavaScript、C#和PowerShell，用于短时间运行代码，以及自定义连接器和外部API调用。 关于架构指导，请参见《 逻辑应用编码标准：本地函数》。
安全性和标识
使用Microsoft Entra ID、Azure RBAC、Azure 密钥保管库、私有网络以及安全的输入输出来保护工作流程和数据。 OAuth 连接使用基于令牌的授权，可能需要交互式登录和同意。 不要把 OAuth 当作在工作流程中存储用户的电子邮件地址和密码。
对于支持的 Azure 托管标准工作流中的连接器，托管身份消除了存储凭证或访问令牌的需求。 在本地开发过程中，Azure 逻辑应用 Standard 扩展可以通过 Azure Identity 凭证链使用登录的开发者身份，而部署的工作流程则使用其系统分配或用户分配的管理身份。 这两种身份都需要对目标资源获得相应权限。 这种 Visual Studio Code 功能并未改变当前连接器操作中托管身份认证的混合限制。 欲了解更多信息，请参见 Logic Apps Standard 扩展中的“使用带管理身份的连接器”。
部署和操作
将工作流定义、配置和工件存储在源码控制中，并使用自动化的构建和部署流水线。 Bicep 编译成 Azure 资源管理器 模板。 Terraform 和 Pulumi 是替代的基础设施即代码工具，通过各自的提供者管理 Azure 资源。
在第一波生产迁移浪潮之前，规划监控、访问控制、环境配置、灾难恢复和支持所有权。 保护敏感动作输入和输出，避免它们出现在运行历史或遥测中。
后续步骤
采用迭代迁移方法来处理库存依赖，优先排序工作负载，验证目标设计，并分批发布。 Azure 逻辑应用 迁移代理可以协助发现、分析、规划、转换、验证和部署，同时您仍可掌控架构和实施决策。