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

为什么要从 BizTalk Server 迁移到 Azure 集成服务？

本指南概述了原因和优势、产品比较、功能和其他信息，以帮助你开始从本地 BizTalk Server 迁移到基于云的 Azure 集成服务。 按照本指南，你将找到更多指南，这些指南涵盖如何选择最适合你的场景的服务以及迁移策略、规划注意事项和最佳做法，以帮助你取得成功。

原因和优势

通过将集成工作负荷迁移到 Azure 集成服务，可以获得以下主要优势：

好处	描述
新式集成平台即服务 (iPaaS)	Azure 集成服务提供最初生成 BizTalk Server 时尚未设想的功能，例如： - 创建和管理 REST API 的功能 - 可缩放的云基础结构 - 新式、更安全且更易于实现的身份验证方案 - 简化的开发工具，包括许多基于 Web 浏览器的体验 - 自动进行平台更新并与其他云原生服务集成
基于消耗的定价	使用传统的中间件平台，你必须经常在采购许可证和基础结构方面进行大量资本投资，这迫使你“针对峰值进行构建”，导致效率低下。 Azure 集成服务提供多种定价模型，通常可以让你按使用量付费。 尽管某些定价模型启用更高级的功能并提供对它们的访问权限，但你可以灵活地为使用的东西付费。
降低进入门槛	BizTalk Server 是一个非常强大的中间件中转站，但需要大量时间来学习和熟练掌握。 Azure 集成服务减少了启动、学习、构建和交付解决方案所需的时间。 例如，Azure 逻辑应用包含一个可视化设计器，可为你提供构建声明性工作流的无代码或低代码体验。
SaaS 连接性	随着 REST API 成为应用程序集成的标准，越来越多的 SaaS 公司采用这种方法来交换数据。 Microsoft 构建了一个广泛且不断发展的连接器生态系统，其中包含数百个 API，可与 Microsoft 和非 Microsoft 服务、系统和协议协同工作。 在 Azure 逻辑应用中，你可以使用工作流设计器从这些连接器中选择操作，轻松创建和验证连接，并配置可供它们使用的操作。 此功能可加快开发速度，并在使用 OAuth2 验证对这些服务的访问时提供更高的一致性。
多个地理部署	Azure 目前提供 60 多个已公布的区域，比任何其他云提供商都多，因此你可以轻松选择适合你和你的客户的数据中心和区域。 这种覆盖范围使你能够以一致的方式在许多地区部署解决方案，并从可伸缩性和冗余角度为你提供机会。

什么是 Azure 集成服务？

Azure 集成服务包括以下基于云的、无服务器的、可缩放的且由 Microsoft 管理的构建基块，供你创建全面的集成解决方案并迁移现有的 BizTalk Server 解决方案：

服务	说明
Azure 逻辑应用	创建并运行集成应用、数据、服务和系统的自动化逻辑应用工作流。 可以快速为你的企业和企业到企业 (B2B) 方案开发高度可缩放的集成解决方案。 使用可视化工作流设计器来启用微服务、API 业务流程和业务线集成。 若要在自动化业务关键工作流的同时提高规模和可移植性，请在允许 Kubernetes 运行的任何地方进行部署和运行。 可以创建消耗或标准逻辑应用资源。 消耗型逻辑应用仅包含一个有状态工作流，此工作流在多租户 Azure 逻辑应用中运行。 标准逻辑应用可以包含多个有状态或无状态工作流，这些工作流在单租户 Azure 逻辑应用、应用服务环境 v3 或已启用 Azure Arc 的逻辑应用中运行。 鉴于 Azure 逻辑应用在 Azure 集成服务中的定位，本指南重点介绍标准逻辑应用，这些应用可在企业功能、成本和敏捷性之间实现最佳平衡。 有关详细信息，请参阅 Azure 逻辑应用。
Azure Functions	编写更少的代码，维护更少的基础结构，并节省运行应用程序的成本。 无需你部署和维护服务器，云基础结构提供保持应用程序运行所需的所有最新资源。 有关详细信息，请参阅 Azure Functions。
Azure 数据工厂	使用 90 多个内置的免维护连接器，以可视方式集成所有数据源，无需额外付费。 在直观的环境中以无代码的方式轻松构建提取、转换和加载 (ETL) 以及提取、加载和转换 (ELT) 流程，也可以编写你自己的代码。 若要解锁业务见解，请将集成数据传送到 Azure Synapse Analytics。 有关详细信息，请参阅 Azure 数据工厂。
Azure 服务总线	使用这个高度可靠的企业消息中转站，在应用程序和服务之间以消息形式传输数据，即使在离线时也是如此。 使用结构化的先进先出 (FIFO) 消息传递、发布-订阅功能和异步操作在客户端和服务器之间中转消息时获得更大的灵活性。 有关详细信息，请参阅 Azure 服务总线。
Azure 事件网格	使用事件中转站交付的事件将应用程序集成到订阅者目标，例如 Azure 服务、其他应用程序，或事件网格具有网络访问权限的任何终结点。 事件源可以包括其他应用程序、SaaS 服务和 Azure 服务。 有关详细信息，请参阅 Azure 事件网格。
Azure API 管理	并行部署 API 网关并使用托管在 Azure、其他云和本地的 API 优化通信流。 满足安全性和合规性要求，同时在所有内部和外部 API 中享受统一的管理体验和完全可观测性。 有关详细信息，请参阅 Azure API 管理。

互补的 Azure 服务

除了前面描述的服务之外，Microsoft 还提供以下互补服务，这些服务为 Azure 集成服务提供基础功能，你可能会在迁移项目中使用它们：

服务	说明
Azure 存储	为云中的各种数据对象提供高度可用、可大规模缩放、持久、安全和现代的存储。 可以使用 REST API 通过 HTTP 或 HTTPS 从世界任何地方访问这些数据对象。 Azure 集成服务使用这些功能在事务流经平台时为你安全地存储配置和遥测数据。 有关详细信息，请参阅 Azure 存储。
Azure 基于角色的访问控制 (Azure RBAC)	管理对云资源的访问，这对于任何使用云的组织来说都是一项关键功能。 Azure RBAC 是在 Azure 资源管理器基础上构建的授权系统，针对 Azure 资源提供精细的访问权限管理。 你可以管理谁有权访问 Azure 资源、他们可以对这些资源执行哪些操作，以及他们可以访问哪些区域。 有关详细信息，请参阅 Azure RBAC。
Azure Key Vault	提供的功能可帮助你解决与机密管理、密钥管理和证书管理相关的问题。 Azure 集成服务通过应用程序配置设置和连接器提供与 Azure Key Vault 的集成。 此功能允许你以安全但方便的方式存储机密、凭据、密钥和证书。 有关详细信息，请参阅 Azure Key Vault。
Azure Policy	提供的功能可帮助你以可缩放的方式强制实施组织标准和评估合规性。 使用合规性仪表板，你可以获得一个聚合视图，以便评估环境的整体状态，并深入到每个资源、每个策略的粒度。 Azure 集成服务与 Azure Policy 集成，因此你可以有效地实施广泛的治理。 有关详细信息，请参阅 Azure Policy。
Azure 网络	提供广泛的网络功能，包括连接性、应用程序保护服务、应用程序交付服务和网络监视。 Azure 集成服务使用这些功能通过虚拟网络和专用终结点提供跨服务的连接。 有关详细信息，请参阅 Azure 网络。
Azure 事件中心	通过这种简单、可信且可缩放的完全托管的实时数据引入服务，每秒从任何源流式传输数百万个事件，从而构建动态数据管道并立即应对业务挑战。 API 管理使用事件中心执行自定义日志记录，这是在 Azure 中实施分离跟踪解决方案时的最佳解决方案之一。 有关详细信息，请参阅 Azure 事件中心。
Azure SQL 数据库	在某些时候，你可能需要创建自定义日志记录策略或自定义配置来支持集成解决方案。 虽然 SQL Server 通常在本地用于此目的，但在将本地 SQL Server 数据库迁移到云时，Azure SQL 数据库可能会提供可行的解决方案。 有关详细信息，请参阅 Azure SQL 数据库。
Azure 应用程序配置	集中管理应用程序设置和功能标志。 新式程序（特别是在云中运行的程序）通常具有在本质上呈分布式的许多组件。 在这些组件之间分布配置设置可能会导致在应用程序部署期间难以排查错误。 使用应用配置，你可以在一个位置存储应用程序的所有设置并保证其访问安全性。 有关详细信息，请参阅 Azure 应用配置。
Azure Monitor	Application Insights 是 Azure Monitor 的一部分，提供应用程序性能管理和实时应用监视。 存储应用程序遥测数据并监视集成平台的整体运行状况。 你还可以设置阈值并在性能超过配置的阈值时收到警报。 有关详细信息，请参阅 Application Insights。
Azure 自动化	在 Azure 中跨外部系统自动执行 Azure 管理任务和协调操作。 基于 PowerShell 工作流构建，因此你可以使用该语言的众多功能。 有关详细信息，请参阅 Azure 自动化。

支持的开发人员体验

本部分介绍 BizTalk Server 和 Azure 集成服务支持的开发人员工具：

产品/服务	包含受支持工具的产品或服务
BizTalk Server	每个 BizTalk Server 版本都支持特定版本的 Visual Studio。 例如，BizTalk Server 2020 支持 Visual Studio 2019 Enterprise 或 Professional。 但是，不支持 Visual Studio Community Edition。
Azure Integration Services	- Azure 逻辑应用（标准）：Azure 门户和 Visual Studio Code - Azure 逻辑应用（消耗）：Azure 门户、Visual Studio Code和 Visual Studio 2019、2017 或 2015 - Azure Functions：Azure 门户、Visual Studio Code 和 Visual Studio 2022 - Azure API 管理：Azure 门户和 Visual Studio Code - Azure 服务总线：Azure 门户和服务总线资源管理器 - Azure 数据工厂：Azure 门户和 Visual Studio 2015 或 2013

BizTalk Server 与 Azure 集成服务

为了比较 BizTalk Server 和 Azure 集成服务并讨论如何进行迁移，我们先简单总结一下 BizTalk Server 的功能。 BizTalk Server 最初于 2000 年推出，是一个稳定的本地中间件平台，可使用适配器连接各种系统。 该平台充当业务、系统或应用程序之间的中转站，现在是一个完善的集成平台。 为了简化不同系统在组合方面的挑战（这些系统以不同的语言开发并且可以使用不同的协议和格式进行连接），BizTalk Server 提供了以下主要功能：

• 业务流程（业务流）

  提供创建和运行业务流程或以图形方式定义的业务流程的功能。

• Messaging

  提供与各种软件应用程序通信的功能。 适配器允许 BizTalk Server 的消息传送组件与各种协议和数据格式进行交互。

BizTalk Server 引擎包括以下组件：

组件	说明
业务规则引擎 (BRE)	评估复杂的规则集。
企业单一登录 (SSO)	提供在 Windows 系统和非 Windows 系统之间映射身份验证信息的功能。
业务活动监视 (BAM)	使信息工作者能够监视正在运行的业务流程。
组中心	使支持人员能够管理引擎和运行的业务流程。

BizTalk Server 的工作原理？

BizTalk Server 使用以 MessageBox 数据库为核心的发布-订阅消息传送引擎体系结构。 MessageBox 负责存储消息、消息属性、订阅、业务流程状态、跟踪数据和其他信息。

当 BizTalk Server 收到消息时，服务器将通过管道传递并处理该消息。 此步骤规范化消息并将其发布到 MessageBox。 然后，BizTalk Server 根据消息上下文属性评估任何现有订阅并确定消息的预期收件人。 最后，BizTalk Server 根据订阅或筛选器将消息路由到目标收件人。 此收件人是业务流程或发送端口，它是 BizTalk Server 发送消息的目标或 BizTalk Server 可以从中接收消息的源。 BizTalk Server 通过发送管道传递消息，从而通过发送端口传输消息。 在通过适配器发送消息之前，发送管道将消息序列化为接收方期望的本机格式。

MessageBox 数据库具有以下组件：

• 消息代理

  BizTalk Server 使用此代理与 MessageBox 交互，它提供用于发布消息、订阅消息、检索消息等的接口。

• 一个或多个 SQL Server 数据库

  这些数据库为消息、消息部件、消息属性、订阅、业务流程状态、跟踪数据、用于路由的主机队列等提供持久性存储。

下图显示了 BizTalk Server 消息传送引擎的工作原理：

接收端口收到消息后，MessageBox 会存储该消息，以便供业务流程处理或路由到任何订阅了特定消息的发送端口。

有关详细信息，请参阅本指南后面的发布-订阅体系结构。

业务流程

本部分介绍用于设计和构建可在 BizTalk Server 和 Azure 集成服务中运行的业务流程的选项。

BizTalk Server

在 BizTalk Server 中，业务流程是可执行的业务过程，可以通过 MessageBox 数据库来订阅（接收）消息和发布（发送）消息。 业务流程可以构造新消息，并且可以使用订阅和路由基础结构来接收消息。 当 MessageBox 填充业务流程的订阅时，新的实例（业务流程运行）会激活，并且 MessageBox 会传送消息。 必要时将解除冻结实例，然后传送消息。 当消息从业务流程发送时，它们会发布到 MessageBox，其方式与到达接收位置的方式相同，并会将适当的属性添加到数据库进行路由。

为了启用发布-订阅消息传送，业务流程使用有助于创建订阅的绑定。 业务流程端口是说明交互的逻辑端口。 为了传送消息，必须将这些逻辑端口绑定到物理端口，但是此绑定进程只不过是为消息路由配置订阅。

BizTalk Server 具有以下优势（示例）：

• 设计器优先（声明性）

  通过使用易于理解的设计工具来设计复杂的流程，以实施可能难以在代码中实施的模式和工作流。

• 使用最终系统进行抽象

  设计流程的重点是消息，而不是最终系统。 例如，在开发解决方案时，你不必担心是要使用 FILE 适配器还是要使用 FTP 适配器， 而只需关注通信类型（是单向还是请求-响应），以及要处理的消息类型。 稍后在部署解决方案时，可以指定适配器和最终系统。

Azure Integration Services

在 Azure 逻辑应用中，你可以使用可视化设计器的“构建块”编程方式和来自数百个连接器的预建操作，将可执行业务流程和应用程序创建为逻辑应用工作流，只需最少的代码。 逻辑应用工作流从一个触发器操作开始，后跟一个或多个措施操作，每个操作都作为工作流实现过程中的一个逻辑步骤。 工作流可以使用操作来调用外部软件、服务和系统。 一些操作执行编程任务，例如条件（if 语句）、循环、数据操作、变量管理等。

Azure 逻辑应用具有以下优势（示例）：

• 设计器优先（声明性）

  通过使用易于理解的设计工具来设计复杂的流程，以实施可能难以在代码中实施的模式和工作流。

• 灵活且可缩放

  Azure 逻辑应用是一种基于云的、无服务器的、高度可缩放的计算服务，可自动缩放和适应，以满足不断变化的业务需求。

• 连接到任何对象

  从具有数百个预生成连接器的不断扩展的库中进行选择，以生成工作流。 连接器提供操作，你可以将其用作工作流中的步骤。 你可以为来自 Microsoft 和合作伙伴的大多数服务和系统（包括 BizTalk Server、Salesforce、Office 365、SQL 数据库、大多数 Azure 服务（例如 Azure Functions、Azure 存储、Azure 服务总线、许多其他服务以及本地应用程序或系统）、大型机、SaaS 和 API）构建集成解决方案。 如果你要访问的资源不存在预生成的连接器，则可以使用通用 HTTP 操作与服务通信，也可以创建自定义连接器。

可重复使用的组件

集成平台提供了以一致且统一的方式解决问题的方法，你通常可以通过可重用组件来实现这一点。 本部分介绍如何重用 BizTalk Server 和 Azure 集成服务中的组件。

BizTalk Server

• 业务流程

  可以在同一应用程序内部或多个应用程序中创建和共享通用业务逻辑，作为跨不同工作流的业务流程。 可通过以下方式之一触发业务流程：使用 BizTalk Server 中的原生发布-订阅机制（以分离方式）；使用名为“调用业务流程”的业务流程形状进行同步调用；使用名为“启动业务流程”的业务流程形状进行异步调用。

• 适配器

  适配器是使用公认的数据协议和文档格式在 BizTalk Server 和贸易合作伙伴之间提供连接的软件组件。 这些组件通过使用符合公认标准（如 SMTP、FTP、HTTP 等）的传送机制，使发送和接收消息变得更加容易。 适配器是核心平台的一部分，因此所有现有应用程序都共享它们。 还可以通过使用 BizTalk 适配器框架创建自定义适配器（原生的或基于 Windows Communication Foundation (WCF) 的）来扩展该层。

• 架构

  XML 架构定义 (XSD) 架构在 BizTalk Server 中启用基于协定的消息传送。 为避免创建冗余架构，可以从已编译的程序集中引用架构。 若要使用共享架构，必须从 BizTalk 项目中添加对共享程序集的引用。

  虽然此步骤听起来可能很简单，但由于存在依赖链，管理对共享程序集的更改可能会变得很困难。 如果共享程序集需要更新，则必须从 BizTalk Server 中删除引用共享程序集的所有项目才能安装更新。 但是，若要避免这些约束，可以实施程序集版本控制，在不破坏现有解决方案的情况下为架构或共享架构部署新版本。

• 映射和自定义 Functoid

  映射在 BizTalk Server 中启用 XML 消息翻译或转换。 可以共享映射，但与共享架构一样，类似的注意事项也适用于共享映射。 由于存在依赖链，请谨慎行事，确保你有一个成熟的软件开发生命周期来管理变更。

  在映射中，Functoid 使用预定义的公式和特定值（称为参数）来执行计算。 BizTalk Server 提供了许多 Functoid 来支持一系列不同的操作。 自定义 Functoid 提供的方法可扩展 BizTalk Server 映射环境中可用操作的范围。

  如果开始创建许多映射，你会发现自己在重复实现类似的逻辑。 因此，你会发现自己需要花时间维护多个等效代码片段，你通常将这些代码片段复制并粘贴到映射内的或映射之间的多个位置。 考虑将此类代码片段转换为自定义 Functoid。 这样，你只需创建一次 Functoid，就可以根据需要在任意多个映射中重用 Functoid，仅在一个地方更新 Functoid。 每个自定义 Functoid 都可以部署为使用从 Microsoft.BizTalk.BaseFunctoids 命名空间派生的类的 .NET 程序集。 单个程序集可包含多个自定义 Functoid。

• .NET Fx 程序集

  可以在 BizTalk Server 项目之间共享这些程序集。 从依赖项的角度来看，这些程序集更易于管理。 如果不存在中断性变更，则更新 .NET Fx 程序集需要更新全局程序集缓存 (GAC) 中的 DLL，这会自动使变更可用于其他程序集。 如果存在中断性变更，则还必须更新依赖项目以适应 .NET Fx 程序集中的变更。

• 自定义管道和管道组件

  当 BizTalk Server 接收和发送消息时，由于业务原因，服务器可能需要为进入和退出准备和转换消息。 在 BizTalk Server 中，管道提供管道和过滤器集成模式的实现，并包含许多功能，例如 JSON 编码器和解码器、MIME 或 SMIME 解码器等。

  当你需要将信息添加到需要管道自定义的消息上下文时，可以使用 BizTalk Server 提供的通过创建自定义管道组件来自定义这些管道的功能。 自定义管道组件是一个 .NET 类，可用于实现多个 BizTalk 接口，然后在任何自定义管道的不同阶段使用。 若要为此类组件编写代码，可以使用 C# 或 Visual Basic for .NET。

• 规则引擎策略

  业务规则引擎策略是另一种可在同一 BizTalk 组中部署 BizTalk Server 应用程序之间共享的项目。 如果你有通用的业务规则引擎规则（例如与消息路由相关的规则），则可以在一个位置管理这些规则，并在已安装的 BizTalk 应用程序中广泛共享这些规则。 业务规则引擎缓存这些规则，因此，如果对这些规则进行任何更新，则必须重启业务规则引擎更新服务。 否则，更改要等到下一个缓存超时时才会生效。

Azure Integration Services

• 集成帐户

  对于 Azure 逻辑应用，集成帐户是基于云的容器和 Azure 资源，提供对可重用生成工件的集中访问。 对于消耗逻辑应用工作流，这些生成工件包括贸易合作伙伴、协议、XSD 架构、XSLT 映射、基于 Liquid 模板的映射、证书、批配置和 .NET Fx 程序集。

  对于标准逻辑应用工作流，Azure 逻辑应用最近引入了对从 XSLT 转换调用 .NET Fx 程序集的支持，无需集成帐户。 也可将架构、映射和程序集添加到 Visual Studio Code 中的标准逻辑应用项目，然后部署到 Azure。

• API

  API 支持数字体验，使数据和服务可重用且可普遍访问，简化应用程序集成，并支持新的数字产品。 随着对 API 的依赖日益增加，组织需要在整个生命周期中将其作为一流资产进行管理。

  你可以在 Azure 集成服务中重复使用 API，尤其是那些使用 Azure API 管理进行管理的 API。 将 API 添加到 Azure API 管理后，可以将 API 管理连接器与消耗逻辑应用工作流结合使用，以托管和受监管的方式轻松访问 API。 Azure 逻辑应用还支持创建和使用自定义 API，以便你的组织可以促进它在整个企业的重用，避免开发人员可能创建的不必要的冗余连接器。 自定义 API 还使得大众可以使用这些 API，不需要开发人员弄清楚特定 API 的使用机制。

• 自定义连接器

  如果要使用的 API 不存在预生成的连接器，则可使用 OpenAPI 架构来包装外部 API 以创建自定义连接器，并通过适当的权限从消耗逻辑应用工作流访问该连接器。 自定义连接器在 Azure 逻辑应用和 API 之间创建协定，该协定可以让你轻松汇编请求消息，并让 Azure 逻辑应用可以接收允许你在下游操作中使用的类型化响应。 REST API 和 SOAP API 均受支持，它们可以引用本地网络上存在的公共 API 或专用 API。 你还可以将自定义连接器与 Microsoft Power Automate 和 Microsoft Power Apps 配合使用。

  对于标准逻辑应用工作流，你可以创建自己的基于服务提供商的内置自定义连接器。

  通过实现自定义连接器，可以通过创建用于发送请求消息和接收类型化响应的通用接口来简化开发体验。 有关详细信息，请参阅自定义连接器概述。

适配器和连接器

以下部分分别介绍 BizTalk Server 和 Azure 集成服务中的适配器和连接器的概念。

BizTalk Server

为了与外部系统、应用程序和实体交换消息，BizTalk Server 提供了适配器，这些适配器是 COM 或 .NET Fx 组件，通过使用各种通信协议将消息传输到业务终结点（例如文件系统、数据库和自定义业务应用程序）或从业务终结点传输消息。 BizTalk Server 提供支持各种协议的原生适配器，例如：

• 支持从文件位置发送和接收消息的文件适配器
• 用于 EDI、FTP、HTTP、MSMQ、SMTP、POP3 和 SOAP 协议的适配器
• 适用于 Windows SharePoint Services 的适配器

BizTalk 适配器框架为所有适配器提供了一种稳定、开放的机制，以实现或访问来自 BizTalk Server 消息传送引擎的工作。 Microsoft.BizTalk.Adapter.Framework 命名空间中的接口使适配器能够修改配置属性页。 BizTalk 适配器框架还提供将服务和架构导入 BizTalk 项目的功能。 合作伙伴适配器也可从各供应商和社区成员处获得。 有关已知适配器的列表，请参阅 BizTalk Server：第三方适配器列表。

Azure Integration Services

使用 Azure 逻辑应用构建工作流时，可以使用预构建的连接器来帮助你轻松快速地处理其他应用、服务、系统、协议和平台中的数据、事件和资源，通常无需编写任何代码。 Azure 逻辑应用提供了一个不断扩展的库，其中包含数百个你可以使用的连接器。 你可以为来自 Microsoft 和合作伙伴的许多基于云的或本地的服务和系统（例如 BizTalk Server、Salesforce、Office 365、SQL 数据库、大多数 Azure 服务、大型机、API 等）构建集成解决方案。 一些连接器提供了执行编程操作的操作，例如条件 (if) 语句、循环、数据操作、变量管理等。 如果没有可用于所需资源的连接器，你可以使用通用 HTTP 操作与服务通信，也可以创建自定义连接器。

从技术上讲，连接器是一个代理或封装 API 的包装器，基础服务或系统使用它与 Azure 逻辑应用通信。 此连接器提供在工作流中用于执行任务的操作。 操作以触发器或操作方式提供，你可以配置其中的属性。 一些触发器和操作还要求首先创建和配置底层服务或系统的连接。 如有必要，你还将验证对用户帐户的访问权限。

Azure 逻辑应用中的大多数连接器都是内置连接器或托管连接器。 某些连接器在两个版本中都可用。 可用的版本取决于你创建的是消耗逻辑应用工作流还是标准逻辑应用工作流。

• 内置连接器设计为在 Azure 逻辑应用运行时上以原生方式运行，与任何托管连接器对应物相比，通常具有更好的性能、吞吐量、容量或其他优势。

• 托管连接器由 Microsoft 在 Azure 中部署、托管和管理。 这些连接器提供用于云服务和/或本机系统的触发器和操作。 在标准逻辑应用工作流中，所有托管连接器都被分组为 Azure 连接器。 但是，在消耗型逻辑应用工作流中，托管连接器根据其定价级别分为“标准”或“企业”。

有关详细信息，请参阅以下文档：

• 内置连接器概述
• 托管连接器概述
• Azure 逻辑应用中可用的托管连接器

应用程序连接

以下部分描述了从 BizTalk Server 和 Azure 集成服务连接其他应用程序的选项。

BizTalk Server

适配器在 BizTalk Server 中提供连接功能，并在执行发送或接收操作的 BizTalk Server 上以本地方式运行。 大约有 30 个现成的适配器可用，而 ISV 适配器的小型生态系统提供了额外的功能。 由于这些适配器在本地运行，Windows 身份验证是一种常用的身份验证方法。 常用的适配器包括 FILE、SFTP、SQL、WCF (Basic-HTTP)、HTTP 和 SMTP。 从这个列表中，你可以确定 BizTalk Server 中的适配器主要是协议适配器。 因此，适配器通常使用面向消息的消息传送模式，与其他系统交换完整的消息，这些系统负责在将数据加载到最终数据存储之前解析数据。

Azure Integration Services

连接器在 Azure 逻辑应用中提供连接功能，并在通常由底层 SaaS 系统拥有的 API 之上提供抽象。 例如，SharePoint 之类的服务是使用 API 优先方法构建的，在这种方法中，API 为最终用户提供服务功能，但其他系统也可以通过 API 调用相同的功能。 为了简化对这些 API 的调用，连接器使用元数据来描述消息传送协定，以便开发人员了解请求和响应中需要哪些数据。

以下屏幕截图显示了单租户 Azure 逻辑应用中标准逻辑应用工作流的连接器搜索体验。 选择“内置”标签时，可以找到内置连接器，例如 Azure Functions、Azure 服务总线、SQL Server、Azure 存储、文件系统、HTTP 等。 在“Azure”标签上，可以找到 800 多个连接器，包括其他 Microsoft SaaS 连接器、合作伙伴 SaaS 连接器等。

Web 服务和 API 连接性

以下部分介绍了 BizTalk Server 和 Azure 集成服务中对 Web 服务和 API 连接性的支持。

BizTalk Server

Web 服务支持是 BizTalk Server 中的一项常用功能，可通过与 Windows Communication Foundation (WCF) 集成获得。 BizTalk 中的这种支持分为两类：发布 WCF 服务和使用 WCF 服务。

WCF 适配器支持 WS-* 标准，例如 WS-Addressing、WS-Security 和 WS-AtomicTransaction。 但是，此版本 WCF 适配器中不支持 WS-ReliableMessaging。

WCF 适配器通过模拟来支持单一登录 (SSO)，并获取企业 SSO 票证以将 SSO 与 WCF 适配器一起使用。 此功能使用户上下文可以跨系统流动。 从身份验证的角度来看，服务身份验证支持以下类型：无、Windows 和证书。 客户端身份验证支持以下类型：匿名、UserName、Windows 和证书。 支持的安全模式包括以下类型：传输、消息和混合。

WCF 支持那些使用 WS-AutomicTransaction 协议的事务，你可以在 WCF-WsHttp、WCF-NetTcp 和 WCF-NetMsmq 等 WCF 适配器中找到该协议。 以下方案支持此功能：

• 将消息以事务方式提交到 MessageBox 数据库
• 将来自 MessageBox 的消息以事务方式提交到事务性目标

事务范围受 MessageBox 组件限制。 例如，一个 BizTalk 业务流程无法参与一个客户端的事务。 与此类似，一个目标终结点无法参与由 BizTalk 业务流程启动的事务。

WCF 扩展性通过 WCF 自定义绑定提供。 你需要编译自定义代码并将其添加到全局程序集缓存 (GAC)。 还需要更新 machine.config 文件，使之包含新扩展。 安装绑定后，WCF-Custom 和 WCF-CustomIsolated 适配器将可以看到该扩展。

当你使用 BizTalk 管理控制台时，BizTalk Server 可以将 WCF-BasicHTTP 接收位置公开为 Azure API 管理中的终结点。 你还可以使用 Azure 门户中的 API 管理，通过 BizTalk Server 的 API 管理公开 SOAP 终结点。 有关详细信息，请参阅在 API 管理中发布 BizTalk WCF-BasicHTTP 终结点。

Azure Integration Services

Azure 集成服务中的连接模型不同于 BizTalk Server，部分原因在于 API 经济的发展。 随着越来越多的组织公开对底层系统和数据的访问方式，需要一种与平台无关的方法。 REST 现在是设计新式 Web 服务的主要体系结构方法。

在 Azure 逻辑应用中，REST 是连接系统的默认方法。 由于 Microsoft 和其他软件供应商在其系统和数据的基础上公开 RESTful 服务，因此 Azure 逻辑应用可以公开和使用此类信息。 OpenAPI 规范能够实现此功能，使人类和计算机都可以通过元数据了解客户端和服务器之间的交互。 可以这样理解：请求和响应有效负载都是派生的，这意味着你可以使用动态内容来填充工作流操作的输入，并在下游操作中使用响应的输出。

身份验证方案取决于实现基础服务（由连接器调用）的软件供应商，因连接器而异。 通常，这些方案包括以下类型：

• 基本
• 客户端证书
• Active Directory OAuth
• 原始
• 托管标识

Microsoft 通过在传输过程中加密数据和进行静态数据加密来提供强大的保护层。 当 Azure 客户流量在数据中心之间（在不受 Microsoft 控制或代表 Microsoft 的某方控制的物理边界之外）移动时，会在底层网络硬件上点对点应用使用 IEEE 802.1AE MAC 安全标准 (MACsec) 的数据链路层加密方法。

Microsoft 允许你选择使用传输层安全性 (TLS) 协议来保护在云服务和客户之间传输的数据。 Microsoft 的数据中心与连接到 Azure 服务的客户端系统协商建立 TLS 连接。 TLS 提供严格的身份验证，消息隐私性和完整性强（允许检测消息篡改、拦截和伪造），此外还有良好的互操作性，算法灵活，易于部署和使用。

虽然本部分重点介绍通过连接器进行的 RESTful 连接，但你可以通过自定义连接器体验实现 SOAP Web 服务连接。

块适配器或连接器使用情况

以下部分介绍了分别在 BizTalk Server 和 Azure 集成服务中防止使用适配器或连接器的选项。

BizTalk Server

BizTalk Server 不包含阻止来自不同应用程序的特定适配器的概念，但你可以通过从环境中删除这些适配器来“阻止”它们在应用程序中的使用。 BizTalk Server 中的适配器是平台设置的一部分，因此安装的适配器可供任何人使用。 你还可以为每个适配器定义特定的接收和发送处理程序，适配器定义属于 BizTalk 组的计算机，后者可以执行或处理这些处理程序。

Azure Integration Services

如果你的组织不允许在 Azure 逻辑应用中使用托管连接器连接到受限的或未批准的资源，则可阻止在逻辑应用工作流中创建和使用这些连接的功能。 可以使用 Azure Policy 定义并强制实施策略来阻止创建或使用你要阻止的连接器的连接。 例如，出于安全原因，你可能想要阻止与特定社交媒体平台或其他服务和系统的连接。

消息持久性

以下部分介绍 BizTalk Server 和 Azure 集成服务中的消息持久性。

BizTalk Server

MessageBox 数据库提供的另一个好处是充当持久点，确保消息在尝试发送到终结点之前持久保存在存储中。 如果消息在用尽所有已配置的重试尝试后仍未能发送，则消息会被挂起并存储在 MessageBox 中。

作为管理员，你可以从 BizTalk 管理控制台恢复挂起的消息。 使用业务流程时，也会出现相同的行为。 业务流程运行时会保留业务逻辑，你可以在出现问题时恢复该业务逻辑。 例如，可以在以下情况下恢复业务流程中的消息：

• 在非原子范围内发送消息
• 在事务范围结束时
• 在启动新的业务流程实例（“启动业务流程”形状）时
• 在调试断点中
• 在引擎确定要进行冻结时
• 在业务流程完成时
• 在系统关闭时

BizTalk Server 提供所有这些现成的功能。 无需担心如何实现持久性，因为 BizTalk Server 会为你处理。

Azure Integration Services

Azure 逻辑应用通过以下方式提供消息持久性：

• 有状态工作流是消耗逻辑应用中的默认设置，在标准逻辑应用中可用，其提供的检查点用于跟踪工作流状态并在消息通过工作流操作时存储消息。 此功能提供对存储在触发器和工作流实例运行历史记录中的丰富数据的访问，你可以在其中查看详细的输入和输出值。

  可以通过 Azure 门户 或 API 重新处理某个运行实例。 此时整个运行实例都会执行，而不管上一次运行的失败发生在何处。 此行为意味着消息传递至少一次，且幂等处理发生在使用者处。

• 借助 Azure 服务总线中提供的速览锁定消息传送，你可以在成功执行消息后提交消息，也可以在发生故障时放弃消息。 若要在 Azure 逻辑应用中使用此功能，请选择 Azure 服务总线连接器。 提交的消息会被从消息队列中删除，而放弃的消息会在解锁后供客户端处理。 速览锁定是实现“恰好一次”消息传送的好方法。

发布-订阅体系结构

以下部分介绍了在 BizTalk Server 和 Azure 集成服务中实现发布-订阅模式的选项。

BizTalk Server

发布-订阅 (pub-sub) 功能因 MessageBox 数据库而存在，这在前面的 BizTalk Server 工作原理部分有所描述。 创建订阅的一种常用方法是使用“升级的属性”，它允许你将定义的消息架构中的特定元素或属性标识为“升级的属性”。 然后，你可以建立订阅，以根据特定标准针对“升级的属性”来筛选消息。 例如，如果升级了一个名为 City 的架构元素，则可以创建一个订阅，通过筛选 City 元素来获取特定城市。 如果满足你的条件，则你的订阅、发送端口或业务流程会收到消息的副本。

Azure Integration Services

由于体系结构与 BizTalk Server 完全不同，Azure 集成服务中的大多数服务都是基于事件的。 如果需要实现发布-订阅解决方案，可以使用 Azure 服务总线。 此服务是一个完全托管的企业消息中转站，在命名空间中包含消息队列和发布-订阅主题。 可以使用 Azure 服务总线来分离应用程序和服务，它具有以下优势：

• 跨争用辅助角色实现工作负载均衡。
• 通过控件跨服务和应用程序边界安全地路由和传输数据。
• 协调需要高度可靠性的事务性工作。

Azure 逻辑应用包括一个可用于发布和订阅消息的 Azure 服务总线连接器。 使用服务总线的好处是，可以独立于工作流使用消息传送。 与 BizTalk Server 不同，消息传送与工作流平台是分离的。 尽管消息传送和工作流功能在 Azure 集成服务中是分离的，但你可以在支持消息属性（用户属性）的 Azure 服务总线中创建消息订阅。 使用这些属性提供由在主题订阅上创建的筛选器评估的键值对。 可以在设置 Azure 服务总线操作时定义这些用户属性，方法是添加一个或多个键值对。 有关演示，请参阅以下视频：使用 Azure Integration Services 的发布订阅消息传送 - 第 2 部分：基于内容的路由。

在 Azure Integration Services 外部，还可以使用实现发布-订阅方案，也可以使用 Azure Cache for Redis。

业务规则引擎

以下部分介绍了在 BizTalk Server 和 Azure 集成服务中设置业务规则的选项。

BizTalk Server

BizTalk Server 包括一个前向链接规则引擎，允许你使用可视化编辑器构造“if-then-else”规则。 可以将这些规则捆绑在一个策略中，该策略可传输到 IT 环境中的其他环境。 这些策略还可以访问 XSD 架构、.NET Fx 代码和 SQL Server 数据库表以查找数据和扩充输出。

Azure Integration Services

尽管 Azure 中目前不存在等效的规则引擎功能，但客户通常使用 Azure Functions 通过自定义代码来实施规则。 然后，客户使用 Azure 逻辑应用中的内置 Azure Functions 连接器访问这些规则。

有关此领域未来投资的详细信息，请参阅本指南后面的路线图部分。

数据转换

以下部分介绍 BizTalk Server 和 Azure 集成服务中的数据转换功能。

BizTalk Server

为你提供丰富的工具，将 XML 消息从一种格式转换为另一种格式。 数据转换使用 XSLT 映射，后者支持允许将自定义 .NET Fx 代码注入这些映射中间的扩展对象。 你还可以使用现成的 Functoid，它们提供可帮助你构建丰富映射的可重用功能。

除了核心 XML 转换之外，BizTalk Server 还提供 CSV 和 JSON 格式的编码和解码，因此你可以在这些格式和 XML 之间进行转换，从而支持不同的格式。

Azure Integration Services

• Enterprise Integration Pack

  该组件遵循 BizTalk Server 中的类似概念，使 B2B 功能易于在 Azure 逻辑应用中使用。 但是，一个主要区别是 Enterprise Integration Pack 在体系结构上是基于集成帐户的。 这些帐户简化了你为 B2B 方案存储、管理和使用生成工件（例如贸易合作伙伴、协议、映射（XSLT 或 Liquid 模板）、架构和证书）的方式。

• Liquid 模板

  对于逻辑应用工作流中的基本 JSON 转换，可以使用内置数据操作，例如“撰写”操作或“分析 JSON”操作。 但是，某些方案可能需要高级且复杂的转换，这些转换包括迭代、控制流、变量等元素。 对于 JSON 到 JSON、JSON 到文本、XML 到 JSON 或 XML 到文本之间的转换，可以使用 Liquid 开源模板语言创建描述所需映射或转换的 Liquid 模板。

• EDI 架构

  EDI 文档架构用于定义 EDI 事务文档类型的正文。 对于逻辑应用工作流，Microsoft 集成 GitHub 存储库中的所有 BizTalk EDI 架构都公开供你使用。

• 标准型逻辑应用

  在 Azure 门户中，可以将映射和架构直接上传到标准逻辑应用资源。 如果你在 Visual Studio Code 中使用标准逻辑应用项目，则可以将这些生成工件上传到它们各自在 Artifacts 文件夹中的文件夹，而无需使用集成帐户。 还可以从 XSLT 映射调用自定义编译程序集。

• Azure Functions

  可以使用 C# 或任何其他编程语言执行 XSLT 或 Liquid 模板转换，以创建可以使用 Azure API 管理或 Azure 逻辑应用调用的 Azure 函数。

网络连接

以下部分介绍了 BizTalk Server 和 Azure 集成服务中的网络连接功能。

BizTalk Server

由于 BizTalk Server 始终安装在服务器环境中，因此网络连接性取决于基础服务器的网络配置。 为 BizTalk Server 设置网络连接性时，通常必须配置以下区域：

• 依赖项
• 与最终系统的入站和出站连接

依赖项配置

若要在多服务器环境中完全配置 BizTalk Server，需要特别注意所有网络连接性依赖项（这通常涉及防火墙配置），以便为众所周知的服务或协议启用 TCP 和 UDP 端口。 例如，此类服务和协议（包括对 SQL Server 引擎、Microsoft 分布式事务处理协调器 (MSDTC)、群集网络驱动器、SSO 服务（如果安装在不同的服务器上）和 SharePoint 的访问）都是必须配置的服务（配置方法是通过创建入站和出站规则来实现连接性）。

入站和出站连接性配置

完全设置 BizTalk Server 并准备好部署应用程序后，请确保实施允许主机实例连接和访问不同服务的防火墙规则，无论它们是属于内部网络还是外部网络。 考虑连接到组织网络外部的最终系统时，还必须考虑安全因素。 各种系统依赖于定义一个允许的 IP 地址的列表作为其第一道防线，因此理想情况下，BizTalk Server 通过一个定义明确的公共 IP 地址列表路由其所有出站通信。

当合作伙伴服务尝试联系 BizTalk Server 时，请确保它们不会到达组织的网络或内层（可能在其中提供核心组织服务）中的实例。 相反，请让合作伙伴服务访问存在于外围网络（也称为外围安全区域 (DMZ)）内的终结点，这是组织网络的最外边界。 但是，必须由 BizTalk Server 将消息路由到其中的服务通常存在于组织的网络中，因此它们应该可以访问该内层。

为了实现这些方案，可以使用多种方法，例如：

• 在外围网络中实现 BizTalk Server，只允许它自己的服务或主机实例访问组织的网络
• 设置两个 BizTalk Server，一个在外围网络中，另一个在组织的网络中。 然后，外围网络中的服务器会发布组织网络中的服务器使用的消息。
• 开发自定义应用程序或设备软件（例如 NetScaler 和 F5），它们可以充当反向代理，在外围网络中代表 BizTalk 接收消息，并将这些调用重定向到 BizTalk Server。

Azure Integration Services

• 入站和出站连接

  Azure 提供了多种方法来隔离网络边界内的服务并连接本地工作负荷和云工作负荷。 以下列表描述了将 Azure 资源与网络边界内的资源集成的不同方式：

  • 本地数据网关

    此网关充当 Azure 与网络外围内资源之间的桥梁，在本地数据和各种 Microsoft 云服务之间提供快速且安全的数据传输。 这些服务包括 Azure 逻辑应用、Microsoft Power BI、Microsoft Power Apps、Microsoft Power Automate 和 Azure Analysis Services。 使用此网关，你可以将数据库和其他数据源保留在其本地网络中，并在云服务中安全地使用该本地数据。

  • 混合连接

    混合连接是一项 Azure 服务，同时也是 Azure 应用服务中的一项功能，支持方案，并且提供的功能超出了 Azure 应用服务中使用的功能。 若要详细了解如何在 Azure 应用服务之外使用，请参阅 Azure 中继混合连接。 在 Azure 应用服务中，可以使用混合连接来访问任何网络中的应用程序资源，这些网络可以通过端口 443 对 Azure 进行出站调用。 混合连接提供从应用到 TCP 终结点的访问权限，而不会启用新的访问应用的方式。 在 Azure 应用服务中，每个混合连接都与单个 TCP 主机和端口组合相关联。 此功能使应用能够访问任何 OS 上的资源，前提是存在 TCP 终结点。 混合连接不知道或不关心应用程序协议或你要访问的内容。 此功能只提供网络访问。

  • 虚拟网络集成

    通过 Azure 虚拟网络集成，可以将 Azure 资源连接到 Azure 中配置的虚拟网络，使应用能够访问该虚拟网络中的资源。 Azure 逻辑应用中的虚拟网络集成仅用于从 Azure 资源向虚拟网络发出出站调用。

    使用虚拟网络对等互连，你可以将本地网络连接到 Azure，从而在本地资源和 Azure 服务之间提供双向连接。 Azure 集成服务提供虚拟网络连接，允许混合集成。 下图显示了标准逻辑应用资源，其中打开了“网络”页面并启用了虚拟网络集成，如“出站流量”框中突出显示的那样。 此配置可确保所有出站流量都从此虚拟网络离开。

    

  • 专用终结点

    专用终结点是使用虚拟网络中的专用 IP 地址的网络接口。 此网络接口通过专用且安全的方式连接到由 Azure 专用链接提供支持的 Azure 资源。 通过启用专用终结点，你将该 Azure 资源引入虚拟网络并允许网络中的资源对 Azure 资源进行入站调用。

下表显示了每个 Azure 集成服务资源可以使用的网络连接方法：

资源	本地数据网关	混合连接	虚拟网络集成	专用终结点
Azure API 管理	✅		✅	✅
Azure 逻辑应用（消耗）	✅
Azure 逻辑应用（标准）	✅ （使用 Azure 连接器）	✅ （使用内置连接器）	✅ （使用内置连接器）	✅
Azure 服务总线			✅	✅
Azure 事件网格

自定义代码

以下部分介绍了在 BizTalk Server 和 Azure 集成服务中创作和运行你自己的代码的选项。

BizTalk Server

可以使用自定义 .NET Fx 代码以多种方式扩展 BizTalk，例如：

功能	说明
内联代码	可以在业务流程形状内编写内联 C# 代码。 还可以在 BizTalk 映射中编写内联代码。 在这两种情况下，代码片段在性质上一般都很简单，无法调试。
已编译的程序集	可以从以下位置调用这些程序集： - 业务流程中的表达式形状 - 使用脚本 Functoid 的 BizTalk 映射 - 业务规则引擎策略 - 作为自定义管道组件的管道 可以通过将 Visual Studio 调试程序附加到适当的主机实例 Windows 进程，来调试已编译的程序集。
自定义适配器	BizTalk Server 包括许多现成的适配器，但你始终可以根据需要创建自己的适配器。
自定义 WCF 行为	BizTalk Server 包括许多现成的适配器，其中大部分基于 Windows Communication Foundation (WCF)。 在某些情况下，可能需要通过开发自定义行为来扩展它们的功能，例如将 OAuth 标头应用于系统通信。
BizTalk Server 映射中的扩展性	- 可以使用 C#、JScript、Visual Basic、XSLT 或 XSLT 调用模板创建内联代码，以消除使用现成的 Functoid 带来的一些限制或困难。 - 可以使用脚本 Functoid 来调用外部程序集。 - 可以创建要在所有映射中使用的自定义 Functoid。

Azure Integration Services

Azure Functions 使你能够编写可从 Azure 逻辑应用中的 Azure Functions 连接器运行的代码。 Functions 平台支持各种编程语言和运行时，具有很大的灵活性。 这些函数通常被设计为具有较短的执行时间。存在一组丰富的开发人员工具来支持本地开发和调试。

在 Azure 逻辑应用中，“内联代码”连接器提供名为“执行 JavaScript 代码”的操作。 可以使用此操作在 JavaScript 中编写小代码片段。 这些代码片段也有望具有较短的执行时间，并支持动态内容输入和输出。 代码运行后，输出可用于工作流中的下游操作。 尽管目前没有对此操作的直接调试支持，但你可以在工作流实例的运行历史记录中查看输入和输出。

如可重用组件部分所述，当你将这些程序集上传到集成帐户时，消耗逻辑应用工作流中目前支持从 XSLT 映射调用 .NET Fx 程序集。 此功能有助于支持自定义数据转换规则。 对于标准逻辑应用工作流，Azure 逻辑应用团队最近发布了在无需集成帐户的情况下对从 XSLT 映射调用 .NET Fx 代码的支持。 你还可以将程序集和映射添加到 Visual Studio Code 中的标准逻辑应用项目，然后部署到 Azure。 有关详细信息，请参阅添加到 Azure 逻辑应用（标准）XSLT 转换的 .NET Framework 程序集支持和“路线图”部分。

还可以通过包含 Azure API 应用或使用 Azure 应用服务创建的 Web 应用来扩展工作流。 当需要托管 Web 应用、REST API 和移动后端时，Azure 应用服务是基于 HTTP 的首选解决方案。 可以将托管在 Azure 应用服务中的应用与本地服务或云服务集成。 该平台支持使用基于 Windows 和 Linux 的环境来运行和缩放应用程序以及各种语言和框架，例如 ASP.NET Core、Java、Ruby、Node.js、PHP 和 Python。

应用程序组

以下部分介绍了在 BizTalk Server 和 Azure 集成服务中组织工作负荷的选项。

BizTalk Server

软件开发生命周期的一部分包括构建和管理逻辑包中的代码和生成工件。 BizTalk Server 支持应用程序的概念，因此你可以将 Visual Studio 解决方案部署到 BizTalk 应用程序中。 所以，如果你有需要共享资源的场景，可以引用其他应用程序。

BizTalk Server 使用显式共享模型，你可以在其中添加对已编译程序集的引用。 如果这些程序集位于全局程序集缓存 (GAC) 中，BizTalk 运行时会根据需要查找和加载程序集。 一个缺点是，当你需要更新共享程序集时，除非实施版本控制方案，否则必须在进行更新之前卸载所有引用程序集的 BizTalk 项目。 此限制可能会导致部署时间线过长以及管理多个安装和卸载时过于复杂。

Azure Integration Services

在 Azure 逻辑应用中，消耗逻辑应用资源仅包含一个有状态工作流，这意味着工作流和逻辑应用资源（即应用程序）始终具有一对一的关系。 应用程序概念通过标准逻辑应用资源得到了发展。 尽管标准逻辑应用资源仍然是应用程序，但你可以使用此资源包含并运行多个工作流，从而形成一对多关系。 如果你在本地处理 Visual Studio Code 中的标准逻辑应用项目，你的逻辑应用资源将映射到此单个项目。 使用这种方法，你可以轻松且合乎逻辑地将同一项目中的相关工作负荷、代码和生成工件分组，并将该项目作为一个单元进行部署。

云体系结构的工作方式不同于基于服务器的范例，例如 BizTalk。 Azure 逻辑应用（标准）使用拉取模型引入代码和生成工件。 因此，你需要将任何额外的必要生成工件复制到项目中，随后将它们与代码和其他生成工件一起部署。 在某些情况下，你可能希望避免复制所有必要的代码和生成工件。 如果是这样，可以考虑将此功能转变为一项可以单独管理但可以从工作流调用的服务。

例如，假设你有一个被组织广泛使用的数据转换。 你可以实现一个将转换作为服务提供的接口，而不是包括跨多个逻辑应用项目的转换映射。 然后，你可以独立于逻辑应用项目管理该服务的生命周期，并从工作流中调用该服务。

由于能够在标准逻辑应用项目中包含多个工作流，你可能会问：如何在一个项目内或跨多个项目组织这些工作流？ 答案通常取决于你的要求，例如：

• 业务流程相关性
• 端到端监视和支持
• 安全性、基于角色的访问控制和网络隔离
• 性能和业务关键性
• 地理位置和异地冗余

有关详细信息，请参阅在 Azure 逻辑应用（标准）中组织逻辑应用工作流。

安全和调控

在构建集成解决方案时，安全性和治理自然很重要。 根据定义，中间件位于两个或多个系统之间。 若要在建立连接时连接和访问这些系统，通常需要传递凭据或机密，因此需要慎重考虑如何管理该敏感信息。

BizTalk Server

BizTalk 包括企业单一登录 (SSO)，它允许你存储、映射和传输适配器使用的加密凭据。 此加密信息存储在 SSO 数据库中。 你还可以配置 SSO 关联应用程序，这些应用程序是代表你要连接的系统或业务线系统的逻辑实体。

Azure Integration Services

Azure 逻辑应用支持以下安全功能：

• Azure Key Vault

  可以使用 Azure 密钥保管库存储凭据、机密、API 密钥和证书。 在 Azure 逻辑应用中，可以使用 Azure 密钥保管库连接器访问此信息，并可使用安全输入和输出功能从平台的日志和运行历史记录中排除此信息。

  在跟踪部分的后面部分，本指南介绍运行历史记录功能，该功能提供工作流执行的分步重播。 尽管 Azure 逻辑应用提供了捕获工作流运行中的每个输入和输出的价值主张，但有时你需要更精细地管理对敏感数据的访问。 可以通过对触发器和操作使用安全输入和输出功能来为此数据设置模糊处理，以在运行历史记录中隐藏此类内容，并防止将此数据发送到 Azure Monitor，特别是 Log Analytics 和 Application Insights。 下图显示了在运行历史记录中启用安全输入和安全输出的示例结果。

  

• 基于 OAuth 的集成

  大多数连接器在创建连接时使用此身份验证类型。 这种方法使得与许多 SaaS 服务的集成就像提供电子邮件地址和密码一样简单。 Azure API 管理还支持 OAuth，因此你可以通过提供统一的身份验证方案来同时使用这两种服务。

  BizTalk Server 本身不提供此功能。

• 托管标识

  某些连接器支持使用托管标识对 Microsoft Entra ID 保护的资源的访问权限进行验证。 使用托管标识对连接进行身份验证时，无需提供凭据、密码或 Microsoft Entra 令牌。

应用程序管理和访问管理

以下部分描述了在 BizTalk Server 和 Azure 集成服务中管理应用程序和访问的选项。

BizTalk Server

管理员使用 BizTalk Server 管理员控制台来管理 BizTalk Server 应用程序。 此工具是一个 Microsoft 管理控制台 (MMC) 胖客户端应用程序，管理员可以使用它来部署应用程序，查看以前的、活动的和排队的事务，以及执行深入的故障排除活动（例如查看跟踪和重新提交事务）。

Azure Integration Services

Azure 门户是管理员和支持人员用来查看和监视接口运行状况的常用工具。 对于 Azure 逻辑应用，此体验包括可通过运行历史记录获得的丰富事务跟踪。

此外还提供精细的基于角色的访问控制 (RBAC)，因此你可以管理和限制对各个级别的 Azure 资源的访问。

存储

以下部分介绍了 BizTalk Server 和 Azure 集成服务中的数据存储选项。

BizTalk Server

BizTalk Server 严重依赖 SQL Server 进行数据存储和数据持久化。 BizTalk Server 中的所有其他组件和主机在集成不同的业务应用程序（例如接收、处理或路由消息）时具有特定的角色。 但是，数据库计算机会捕获此工作并将其保存到磁盘。 例如，在 BizTalk Server 收到传入消息后，接收主机会在其他主机检索该消息供业务流程处理和发送之前，先将该消息保存到 MessageBox 数据库中。

由于你负责预配和管理 SQL 数据库，因此高可用性是确保正常运行时间的重要架构组件。 为了为 BizTalk Server 数据库提供高可用性，客户通常使用 Windows 群集创建一个服务器群集，其中包含两台或多台运行 SQL Server 的计算机。 此服务器群集为 BizTalk Server 数据库提供冗余和容错。 与负载平衡群集（其中一个计算机组共同作用以提高可用性和可伸缩性）不同，服务器群集通常只包含两台采用主动-被动配置的数据库计算机，以便其中一台计算机可为另一台计算机提供备份资源。

Azure Integration Services

Azure 逻辑应用依靠 Azure 存储来存储和自动加密静态数据。 此加密可保护数据，并帮助你履行组织的安全性和符合性承诺。 默认情况下，Azure 存储使用 Microsoft 托管密钥来加密数据。 有关详细信息，请参阅静态数据的 Azure 存储加密。

当通过 Azure 门户使用 Azure 存储时，所有事务都通过 HTTPS 发生。 还可以通过 HTTPS 使用存储 REST API 来使用 Azure 存储。 若要在调用 REST API 以访问存储帐户中的对象时强制使用 HTTPS，请启用存储帐户所需的安全传输。

数据配置

当你希望在环境之间移动集成解决方案而无需重新编译或重组代码时，配置和代码之间的分离变得很重要。 配置信息通常是特定于环境的，因此你可以定义在整个环境中部署解决方案时需要更改的终结点和其他详细信息。

BizTalk Server

• BizTalk NT 服务可执行文件

  此可执行文件调用名为 BTSNTSvc.exe.config 的 app.config 文件。此文件提供键值对，以便你可以存储明文配置信息。 但是，请根据以下注意事项谨慎处理此文件：

  • 确保在 BizTalk 组内的所有计算机上仔细复制配置。

  • 配置更改要求你重启主机实例以获取此配置文件中的最新值。

  • 此配置文件中引入的任何语法错误都会阻止主机实例启动，导致停机。

• 企业 SSO 工具

  还可以将此工具用作配置存储。 社区工具也可用于通过企业 SSO 进行数据管理。 你随后可以通过 SDK 工具访问此数据，以在运行时检索此数据。

• 自定义缓存组件

  通常会引入这些组件，以便可以解决键值对以外的用例问题。 例如，假设你要将表格数据存储在 SQL Server 数据库中，并在主机实例启动时将该数据加载到内存中。 此实现允许 BizTalk Server 通过运行自定义 .NET Fx 代码在运行时获取此信息。 然后，你可以从业务流程、BizTalk 映射和自定义管道组件访问此数据。

• 自定义数据库

  数据库是开发人员和管理员都熟知的技术和语言，因此自定义数据库是存储应用程序配置数据的另一种常见选择。

• 业务规则引擎 (BRE)

  BRE 也可以充当配置存储，虽然不是主要用例。 无论是从业务流程还是从管道组件调用引擎，你都可以在 BRE 策略中定义特定于环境的信息，然后将相应的策略部署到相关环境。 在运行时，业务流程或管道组件可以在下游功能（例如映射）或路由情况下访问和使用此信息。

• 自定义配置文件

  你可以使用自定义配置 (.config) 文件来存储应用程序配置数据，但这种方法并不常见，因为你可能必须在所有环境中为这些文件维护一个静态和固定的位置。

• Windows 注册表

  你可以使用 Windows 注册表作为存储应用程序配置值的有效选项。 此注册表是 Microsoft Windows 操作系统使用的中央分层数据库，用于存储为一个或多个用户、应用程序和硬件设备配置系统所需的信息。 注册表包含以下基本元素：配置单元、键和值。 但是，在具有多个注册表的大型环境中维护存储在注册表中的值可能会很困难，而且备份单个应用程序设置也很困难。

Azure Integration Services

• Azure Key Vault

  此服务存储和保护应用程序和云服务使用的加密密钥和其他机密。 由于安全密钥管理对于保护云中的数据至关重要，因此请使用 Azure Key Vault 来加密和存储密钥和机密，例如密码。

• Azure 应用程序配置

  此服务集中管理应用程序设置和功能标志。 可以将所有 Azure 应用的配置存储在一个通用的托管位置。 通过避免耗时的重新部署，在不影响客户的情况下，实时、有效且可靠地管理配置。 Azure 应用配置专为速度、可伸缩性和安全性而构建。

• Azure Cosmos DB

  此服务是一个完全托管的 NoSQL 数据库，用于现代应用程序开发，个位数毫秒响应时间，并具有自动和即时可扩展性，可确保任何规模的速度。 可以将配置数据加载到 Azure Cosmos DB 中，然后使用 Azure 逻辑应用中的 Azure Cosmos DB 连接器访问该数据。

• Azure 表存储

  此服务提供另一种存储设施，以较低的成本保留配置数据。 可以使用 Azure 逻辑应用中的 Azure 表存储连接器轻松访问此数据。 有关详细信息，请参阅 Azure 表存储。

• 自定义缓存

  你还可以使用 Azure 集成服务实现自定义缓存解决方案。 常用方法包括在 Azure API 管理和 Azure Cache for Redis 中使用缓存策略。

• 自定义数据库

  数据库是开发人员和管理员都熟知的技术和语言，因此自定义数据库是存储应用程序配置数据的另一种常见选择。

大型文件处理

以下部分介绍了在 BizTalk Server 和 Azure 集成服务中处理大型文件的选项。

BizTalk Server

为解决大型文件处理问题，BizTalk Server 包括基于以下配置文件的优化：

• 仅消息路由

  如果仅将 BizTalk Server 用于基于提升的消息属性来路由消息，则消息将使用 .NET XmlReader 接口流式传输到 MessageBox 数据库。 BizTalk Server 不会将单独的消息部分加载到内存中，因此在这种情况下，内存不足错误不是问题。 但是，主要考虑因素是将非常大的消息（超过 100 MB）写入 MessageBox 数据库所需的时间。 BizTalk Server 开发团队成功测试了在仅执行路由操作的情况下对最大为 1 GB 的消息进行的处理。 有关详细信息，请参阅优化管道性能。

• 使用映射进行数据转换

  当 BizTalk Server 使用映射转换文档时，这种可能会占用大量内存的操作会将消息传递给 .NET XslCompiledTransform 类，该类加载 XSL 样式表。 加载操作成功完成后，多个线程可以同时调用 Transform 方法。 有关详细信息，请参阅 XslCompiledTransform 类。

  通过在转换过程中对将文档加载到内存的操作应用可配置消息大小阈值，BizTalk Server 显著地提高了大型文档的内存管理。 默认情况下，消息大小阈值为 1 MB。 对于大小低于此阈值的任何消息，BizTalk Server 会在内存中处理该消息。 为了减少任何大小超过此阈值的消息的内存要求，BizTalk Server 将消息缓冲到文件系统。

Azure Integration Services

使用 BizTalk Server 之类的本地中间件平台处理大型文件与使用 Azure 逻辑应用之类的 PaaS 产品/服务处理大型文件存在一些基本差异。 例如，仔细检查大型消息方案以找到正确的解决方案，因为在新式云环境中可能存在解决此问题的不同方法。

文件大小限制

在 Azure 中，存在文件大小限制是为了确保一致和可靠的体验。 若要验证方案，请务必查看 Azure 逻辑应用的服务限制文档。 某些连接器支持对超过默认消息大小限制的消息进行消息分块，该限制因连接器而异。 消息分块是指将大消息拆分为较小的消息。

Azure 逻辑应用不是唯一具有消息大小限制的服务。 例如，Azure 服务总线也有此类限制。 若要详细了解如何在 Azure 服务总线中处理大型消息，请参阅大型消息支持。

认领凭证模式

为避免文件大小限制，可以实现认领凭证模式，该模式的工作方式是将大消息拆分为认领凭证和有效负载。 请将认领凭证发送到消息传送平台，并将有效负载存储到外部服务。 这样你就可以处理大型消息，同时保护消息总线和客户端，使之免于过载。 此模式还有助于降低成本，因为存储通常比消息传送平台使用的资源单位更便宜。

Azure 数据工厂

Azure 数据工厂提供了另一个处理大型文件的选项。 此服务是 Azure 的 ELT 产品/服务，用于可缩放的无服务器数据集成和数据转换，具有无代码的可视化体验，可实现直观的创作和单一窗格监视和管理。 还可以将现有 SQL Server Integration Services (SSIS) 包直接迁移到 Azure，并在 Azure 数据工厂中以完全兼容的方式运行它们。 SSIS Integration Runtime 提供完全托管的服务，因此无需担心基础结构管理。 有关详细信息，请参阅将 SQL Server Integration Services 工作负荷直接迁移到云。

在本地体系结构中，SSIS 是管理将大型文件加载到数据库中的常用选项。 作为该体系结构的云等效项，Azure 数据工厂可以解决跨各种数据源（例如文件系统、数据库、SAP、Azure Blob 存储、Azure 数据资源管理器、Oracle、DB2、Amazon RDS 等）转换和移动大型数据集的问题。 当你有大数据处理要求时，考虑使用 Azure 数据工厂作为一个比 Azure 逻辑应用和 Azure 服务总线更好的选择。

监视和警报

BizTalk Server

• BizTalk 运行状况监视器

  此工具是一个 MMC 管理单元，可用于监视 BizTalk Server 环境的运行状况并执行维护任务。 功能包括 MsgBox 查看器 (MBV) 报表、Terminator 工具任务、电子邮件通知、报表收集和 perfmon 集成。

• BizTalk 管理控制台

  该工具也是一个 MMC 管理单元，供管理员发现故障、暂停的实例、当前正在重试的事务、状态等。 工具体验本质上是非常被动的，因为必须不断刷新控制台才能查看最新信息。

• BizTalk360

  一个提供对 BizTalk Server 环境的完全控制的外部 Web 解决方案。 这个单一的工具为 BizTalk Server 提供操作、监视和分析功能。

Azure Integration Services

• Azure Monitor

  若要监控 Azure 资源，可以将此服务和 Log Analytics 功能用作综合解决方案，以便收集、分析和处理来自云和本地环境的遥测数据。

• 在 Azure 逻辑应用中，可以使用以下选项：

  • 对于消耗逻辑应用工作流，可以在 Azure 门户中安装逻辑应用管理解决方案（预览版）并设置 Azure Monitor 日志以收集诊断数据。 设置逻辑应用以将该数据发送到 Azure Log Analytics 工作区后，遥测数据将流向逻辑应用管理解决方案可以提供运行状况可视化效果的位置。 有关详细信息，请参阅为 Azure 逻辑应用设置 Azure Monitor 日志并收集诊断数据。 启用诊断后，还可以使用 Azure Monitor 根据不同的信号类型发送警报，例如在触发器或运行失败时这样做。 有关详细信息，请参阅监视 Azure 逻辑应用的运行状态、查看触发器历史记录并设置警报。

  • 对于标准逻辑应用工作流，可以在创建逻辑应用资源时启用 Application Insights，以从逻辑应用的工作流发送诊断日志记录和跟踪。 在 Application Insights 中，可以查看应用程序映射以更好地了解接口的性能和运行状况特征。 Application Insights 还包括可用性功能，供你配置综合测试来主动调用终结点，然后评估特定 HTTP 状态代码或有效负载的响应。 根据配置的条件，你可以向利益干系人发送通知或调用 Webhook 以获得额外的业务流程功能。

• Serverless 360 是来自 Kovai 的外部解决方案，它通过映射 Azure 服务（例如 Azure 逻辑应用、Azure 服务总线、Azure API 管理和 Azure Functions）来提供监视和管理。 你可以使用 Azure 服务总线中的死信队列重新处理消息、启用自我修复以解决间歇性服务中断问题，以及通过综合事务设置主动监视。

  你可以在门户体验中配置自定义监视规则和查看日志。 你可以通过各种渠道（例如电子邮件、Microsoft Teams 和 ServiceNow）发送通知。 若要直观地确定接口的运行状况，可以使用服务映射。

业务活动监视

以下部分介绍的选项用于监视和收集 BizTalk Server 和 Azure 集成服务中的工作负荷的遥测数据。

BizTalk Server

BizTalk Server 包括一个称为业务活动监视 (BAM) 的功能，它允许开发人员和业务分析师定义可以应用于业务流程的跟踪配置文件。 当消息通过接收和发送端口时，数据属性被捕获并存储在 BAM 数据库中。 自定义实现也可通过 .NET Fx API 获得。

Azure Integration Services

尽管 Azure 中不存在等效的业务活动监视功能，但你可以使用 Application Insights 或其他数据平台之类的功能构建自定义解决方案。 在整个工作流执行过程中，你可以检测代码或配置以将相关信息发送到这些数据存储，而在数据存储中，你可以使用 Power BI 执行额外的分析和可视化操作。 有关此领域未来投资的详细信息，请参阅本指南后面的路线图部分。

另一种选择是你可以使用来自 Kovai 的名为 Serverless 360 的外部解决方案。 除了监视平台，还可以使用业务活动监视功能，该功能为跨云原生集成和混合集成的业务流程提供端到端跟踪。 该功能包括一个托管连接器，开发人员可以使用它来检测代码和捕获重要的业务数据。 管理员随后可以构建仪表板并将其与业务分析师共享。

跟踪

以下部分介绍了用于跟踪生成工件以在 BizTalk Server 和 Azure 集成服务中进行性能监视和运行状况分析的选项。

BizTalk Server

• 消息跟踪

  BizTalk Server 管理员可以使用消息正文跟踪来指示何时将消息正文保存到存储中，用于故障排除和审计目的。 从性能和存储的角度来看，消息跟踪都是一项昂贵的操作，因此请有选择地使用此功能以避免性能问题。 当你在接收和发送端口上启用消息正文跟踪时，BizTalk Server 会使用名为 TrackedMessages_Copy_<message-box-name> 的 SQL Server 代理作业将数据复制到 BizTalk 跟踪数据库 (BizTalkDTADb)。

  

  你可以将跟踪应用于几乎所有 BizTalk Server 生成工件，包括业务流程、管道、接收端口、发送端口、架构和业务规则。 这些选项在运行时启用或禁用，不会影响你的代码（解决方案），也不需要重启。

• 运行状况与活动跟踪 (HAT)

  尽管从 2009 版开始，HAT 工具已从 BizTalk Server 中删除，但该功能仍然存在于 BizTalk 管理控制台中。 管理员可以通过“组概述”体验中的“新建查询”界面搜索数据。 你可以根据不同的条件（包括事件类型、端口名称、URI、架构名称等）定制查询。 如果要查看通过接收或发送端口移动的消息正文，可以访问此信息，前提是启用了端口级别跟踪。 有关详细信息，请参阅运行状况和活动跟踪。

• 与 Application Insights 和 Azure 事件中心集成

  从 BizTalk Server 2016 功能包 1 开始，你可以将遥测数据发布到 Azure Monitor 中的 Application Insights 或 Azure 事件中心。 这种方法避免了 SQL Server 磁盘容量问题，因此你可以改用基于云的弹性数据存储，例如 Application Insights、Log Analytics 以及 Azure 逻辑应用中的运行历史记录。

Azure Integration Services

Azure 逻辑应用提供了丰富的运行历史记录，以便开发人员和支持分析师可以按操作查看遥测数据，包括所有已处理的输入和输出。 为帮助保护任何敏感数据，你可以对工作流中的各个操作启用安全输入和输出。 此功能会对日志和工作流运行历史记录中的数据进行模糊处理或将其隐藏，以避免泄漏。

除了对数据进行模糊处理之外，还可以使用 Azure RBAC 规则来保护数据访问。 Azure RBAC 包含两个专用于 Azure 逻辑应用的内置角色，即逻辑应用参与者和逻辑应用操作员。

除了 Azure RBAC 之外，还可以按 IP 地址范围限制对 Azure 逻辑应用中的运行历史记录的访问。

Hosting

以下部分介绍了 BizTalk Server 和 Azure 集成服务的托管选项。

BizTalk Server

BizTalk Server 2020 支持以下 Microsoft 平台和产品：

• Windows Server 2019、Windows Server 2016 和 Windows 10
• Visual Studio 2019 Enterprise 和 Visual Studio 2019 Professional
• SQL Server 2019、SQL Server 2017 和 SQL Server 2016 SP2
• Office 2019 和 Office 2016

可以在自己的硬件、本地虚拟机或 Azure 虚拟机上安装和运行 BizTalk Server。 Azure 虚拟机可让你针对广泛的计算解决方案灵活地实施虚拟化，支持 BizTalk Server、Windows Server、SQL Server 等。 当前这一代的所有虚拟机均免费包含负载均衡和自动缩放功能。

Azure Integration Services

Azure 逻辑应用

• 托管计划

  在单租户 Azure 逻辑应用中，标准逻辑应用类似于 Azure 函数或 Web 应用，你可以在其中使用单个工作流服务计划来托管多个标准逻辑应用。 这种相似性意味着你不必在单个标准逻辑应用资源中部署所有工作流， 而是可以将这些工作流组织成逻辑组（逻辑应用），以便更好地管理解决方案的其他方面。 这种方法可帮助你充分利用工作流服务计划并使应用程序面向未来，你可以实现这些应用程序，使它们可以单独缩放。

  标准逻辑应用具有以下定价层：WS1、WS2 和 WS3。 从功能上讲，每一层都提供相同的功能。 你对计算和内存的要求决定了什么最适合你的方案，例如：

  定价层	虚拟 CPU (vCPU)	内存 (GB)
  WS1	1	3.5
  WS2	2	7
  WS3	4	14

  有关最新信息，请参阅标准模型中的定价层。

• 可用性和冗余

  在 Azure 中，可用性区域提供复原能力、分布式可用性以及主动-主动-主动-主动区域可伸缩性。 若要提高逻辑应用工作负载的可用性，可以启用可用性区域支持，但前提是你要创建逻辑应用。 在任何支持和启用区域冗余的 Azure 区域中，至少需要三个单独的可用性区域。 Azure 逻辑应用平台跨这些区域分发这些区域和逻辑应用工作负载。 如果某个区域发生数据中心故障，此功能是启用可复原体系结构和提供高可用性的关键要求。 有关详细信息，请参阅使用可用性区域构建高可用性解决方案。

• 隔离的专用环境

  对于标准逻辑应用，你可以为部署环境选择应用服务环境 (ASE) v3。 使用 ASE v3，你将获得一个完全隔离的专用环境，以可预测的价格大规模运行应用程序。 无论你创建和运行多少逻辑应用，都只需为 ASE 应用服务计划付费。

Azure 服务总线

Azure 服务总线提供各种定价层，以便你可以选择满足需求的最佳层。 对于企业环境，客户通常选择高级层或标准层。 对于需要高吞吐量且要求其性能可预测且支持高级网络的的客户，高级层是更好的选择。 如果你可以接受可变吞吐量和较小的消息处理，标准层可能更有意义。 下表总结了这两个层：

高级层	标准层
高吞吐量	可变吞吐量
可预测性能	可变滞后时间
固定定价	即用即付可变定价
增加和减少工作负荷的能力	不可用
消息大小最大为 100 MB。 请参阅大型消息支持。	消息大小最大为 256 KB

有关最新信息，请参阅服务总线高级和标准消息传送层。

Azure API 管理

Azure API 管理提供各种定价层，以便你可以选择满足需求的最佳层。 每个层都有自己的功能，分别命名为“消耗”、“开发人员”、“基本”、“标准”和“高级”。

这些层的功能包括 Microsoft Entra ID 集成、Azure 虚拟网络支持、内置缓存、自承载网关等。 有关这些层及其功能的详细信息，请参阅 Azure API 管理层的基于功能的比较。

Azure 数据工厂

Azure 数据工厂提供各种定价模型，以便你可以选择满足自身需求的最佳模型。 选项因运行时类型而异，其中包括 Azure Integration Runtime、Azure 托管 VNET 集成运行时和自承载集成运行时。 在每个运行时产品/服务中，请考虑对业务流程、数据移动活动、管道活动和外部管道活动的支持。 有关成本规划和定价的详细信息，请参阅计划管理 Azure 数据工厂的成本和通过示例了解数据工厂定价

部署

BizTalk Server

BizTalk Server 中的原生部署打包基于结合了环境配置文件或绑定文件的 Microsoft 安装程序 (MSI) 文件。 这两个文件在组件安装之间创建分离，这些组件部署到以下 BizTalk Server 存储库并定义端口和管道级别的设置，其中包括终结点、机密、管道配置等。

• 管理 DB
• BizTalk Server 本地文件夹
• .NET 全局程序集缓存

虽然这个过程可以证明是有效的，但你还必须将每个单独的环境配置与代码分开管理。 BizTalk 部署框架 (BTDF) 开源项目为此问题提供了一种解决方案。 使用此工具，你可以通过使用在设计时创建的标记化绑定文件和作为 Excel 文件创建的标记矩阵为每个环境维护环境配置作为 BizTalk Server 解决方案的一部分。

然后，构建过程会创建一个统一且版本化的 MSI 文件。 此文件支持来自同一包的组件部署和环境配置，这使你可以更好地控制要跨环境实施的解决方案的版本。

BizTalk Server 2020 中提供了对持续集成-持续部署 (CI/CD) 管道中的 BTDF 包的支持，其中包括随 BizTalk Server 2016 功能包引入的此功能。 可以使用此功能和 Azure DevOps 平台来简化跨环境的 BizTalk Server 解决方案的自动部署。

Azure Integration Services

将 Azure 集成服务组件或解决方案部署到 Azure 时，必须管理以下项：

• 充当要部署的解决方案的容器或基础结构的 Azure 资源，例如，API 管理实例、标准逻辑应用资源、服务总线命名空间或事件网格主题

• 每个组件实现的实际逻辑，例如 API、工作流、队列和订阅

• 与每个组件关联的特定于环境的配置，例如权限、机密、警报等

将基础结构定义与代码分开时，可以将基础结构定义视为另一段代码，可以对其进行版本控制、将其安全地存储在源代码管理存储库中，并在定义更改时触发部署。 这种做法通常称为基础结构即代码 (IaC)，可以提高环境质量，因为你可以为每个环境创建版本并将更改回溯到源代码管理。

Azure 集成服务通过提供使用 Azure 资源管理模板创建基础结构资源的功能来支持 IaC。 尽管 ARM 模板作为一个统一的解决方案来理解和实现似乎很复杂，但你可以使用抽象工具（例如 Bicep、Terraform 或 Pulumi），它们为创建基础结构定义提供了类似代码的体验。 尽管这些工具提供了基于 ARM 模板的抽象层，但这些工具最终会生成 ARM 模板并可为你部署这些模板。

基础结构就绪后，可以部署实现端到端工作流程的逻辑。 由于 Azure 集成服务为你提供了一组工具来实现集成工作流，因此你必须部署每个组件。 对于使用 Azure 集成服务构建的解决方案，CI/CD 管道通常基于组件业务流程的部署。 DevOps 工程师可以使用会抽象部署活动的内置操作，也可以使用运行 CLI 命令或自动化脚本（如 PowerShell 和 Bash）的通用操作。 在大多数情况下，工程师会根据应用程序的需求自定义管道、查看官方文档中的指南，并从使用示例存储库着手。

若要使每个组件都做好部署准备，通常需考虑以下步骤：

• 持续集成阶段

  1. 获取源代码的最新版本。

  2. 使用特定于环境的配置来准备代码。

     此步骤的细节取决于每种技术是否支持外部注入环境变量。 基本前提是基于环境的配置信息（例如连接字符串和对外部资源的引用）被抽象为引用应用程序设置存储库。 因此，在这种情况下，请直接在应用程序设置存储库中存储可以明文形式存在的引用，但需存储敏感值（例如机密）作为指向机密存储（例如 Azure 密钥保管库）中条目的引用指针。

     Azure 逻辑应用通过支持对应用程序设置存储库的引用，使标准逻辑应用资源可以采用这种方法，然后你就可以将名称-值对映射到密钥保管库中的条目。

     对于 Azure API 管理，你可以通过使用名称-值配置获得类似的结果，该配置也支持 Azure Key Vault。

  3. 打包代码以在各种环境中进行部署。

• 持续部署阶段

  1. 在目标环境中部署打包的代码。

  2. 使用正确的环境值更新应用程序设置存储库，这些值可以是明文形式，也可以是对密钥保管库中条目的引用。

  3. 更新任何依赖于代码的必需权限。

  4. 让应用程序准备好执行（如果需要）。

特性匹配

下面的表和图粗略显示了 BizTalk Server 与 Azure 集成服务之间的资源、生成工件、特性和功能如何匹配，尽管匹配不会是一对一的。 虽然 Azure 集成服务是集成工作负荷的关键平台，但请确保将所有可用的 Azure 功能作为一个整体来考虑。

特性或功能	BizTalk Server	Azure
业务流程	- BizTalk Server 业务流程 - C# 代码（帮助程序类或 Web 服务）	- Azure 逻辑应用工作流 - Azure Functions 函数应用 - Azure API 应用
管道	- BizTalk Server 管道 - 管道组件	- Azure 逻辑应用工作流（作为管道） - Azure API 管理（作为管道） - Azure Functions 或 Azure API 应用
消息路由	- MessageBox - 属性升级 - 筛选器	- Azure 服务总线队列和主题（消息标头、消息属性和订阅） - Azure 事件网格或 Azure API 管理 - SQL Server 或 Azure Cache for Redis
应用程序连接性	- BizTalk Server 的现成适配器和自定义适配器 - Internet Information Services (IIS) 和 Azure API 管理（混合功能）	- Azure 逻辑应用连接器 - Azure API 管理（作为连接器） - Azure Functions 或 Azure API 应用
交叉引用	BizTalk 管理数据库 (BizTalkMgmtDb) 上的 xref_ * 表	- Azure Functions - SQL Server - Custom
架构 (XSD)	- BizTalk Server 架构 - XML、JSON 和平面文件架构	- Azure 逻辑应用（消耗）和 Azure 集成帐户 - Azure Functions 和 Azure 存储帐户 - Azure 逻辑应用和 Azure API 应用 - Azure 逻辑应用（标准）
地图	- BizTalk 映射器 - XSLT 映射 - Azure API 管理（混合功能）	- Azure 逻辑应用（消耗）和 Azure 集成帐户（XSLT 映射、Liquid） - Azure Functions 和 Azure 存储帐户 - Azure 逻辑应用和 Azure API 应用 - Azure 逻辑应用（标准）
业务规则	BizTalk Server 业务规则引擎	- Azure Functions - SQL Server - 自定义数据库
业务活动监视	BizTalk Server 业务活动监视	- SQL Server - Azure Monitor (Application Insights) - Power BI
EDI	- BizTalk Server 的现成功能 - 参与方、合作伙伴、协议、AS2、X12、EDIFACT	Azure 逻辑应用和 Azure 集成帐户（合作伙伴、协议、AS2、X12、EDIFACT）
HL7、RosettaNet 和 SWIFT	用于 HL7、RosettaNet 和 SWIFT 的 BizTalk Server 加速器	- Azure 逻辑应用、RosettaNet 和 SWIFT 连接器以及 Azure 集成帐户 - 用于 FHIR (HL7) 的 Azure API 管理 - Azure 蓝图，可在 Azure 上实现 SWIFT CSP 合规性
机密	企业单一登录 (SSO)	- Azure 密钥保管库 - SQL Server - 应用程序配置
安全和调控	- 企业单一登录 (SSO) - SSO 关联应用程序 - Active Directory - 签名证书 - IIS 安全身份验证 - 网络安全	- Microsoft Entra ID - Azure 网络安全 - Azure 基于角色的访问控制 (Azure RBAC) - 声明、令牌 - 共享访问策略
数据配置	- 配置文件 - 企业 SSO 应用程序配置 - 自定义缓存组件 - 自定义数据库 - 业务规则引擎 - Windows 注册表	- Azure 密钥保管库 - Azure 应用配置 - Azure Cosmos DB - Azure 表存储 - Azure 逻辑应用（标准）配置 - Azure Functions 配置 - Azure API 管理命名值和后端 - SQL Server - 自定义缓存 - 自定义数据库
部署	- BizTalk Server 绑定文件	- Azure DevOps 管道 - Bicep 脚本 - Terraform
跟踪	- BizTalk Server 跟踪功能（接收端口、发送端口、管道、业务流程） - IIS 跟踪 - Azure API 管理内置分析（混合功能）	- Azure 逻辑应用运行历史记录和跟踪的属性 - Azure 存储帐户 - Azure Monitor (Application Insights) - Azure API 管理内置分析 - 自定义解决方案，例如 Azure 事件中心 + Azure Functions + SQL Server + Azure 数据资源管理器
监视	- BizTalk 管理控制台 - BizTalk 运行状况监视器	Azure Monitor（Application Insights、Log Analytics）
Operations	- BizTalk Server 管理控制台 - Azure DevOps Pipelines - MSI、PowerShell - BizTalk 部署框架	- Azure 门户 - Azure Monitor - Azure 资源管理器模板 - Azure DevOps 管道 - PowerShell、CLI、Bicep

路线图

为了帮助满足 BizTalk 客户将其工作负荷和接口迁移到 Azure 集成服务的需求，Microsoft 目前优先考虑以下投资：

时间范围	功能投资
短期	- XSLT + .NET Framework 支持（公共预览版） - SWIFT MT 编码器和解码器（公共预览版） - 从 Azure 逻辑应用（标准）调用自定义 .NET Framework 代码
中期	- EDI 和集成帐户增强功能 - 原生 XML 支持 - WCF 和 SOAP 支持 - 业务规则引擎支持
长期	业务事件跟踪

若要及时了解最新投资，请订阅 Azure 博客上的集成 - 技术社区。

后续步骤

你已经详细了解了 Azure 集成服务与 BizTalk Server 的比较情况。 接下来，请了解如何为方案选择最佳 Azure 功能。 也可以直接跳到前面来查看建议的方法和资源、规划注意事项以及迁移的最佳做法。

为你的方案选择最佳的 Azure 集成服务产品/服务

将 BizTalk Server 迁移到 Azure Integration Services 的迁移方法