BizTalk Server 提供了一组广泛的功能，可用于发送、接收、转换和处理消息。 其中部分功能包括：
能够使用多种行业标准传输（如 HTTP、SMTP、FTP/FTPS 和 WCF）发送和接收消息。 使用 BizTalk Server 适配器完成发送和接收消息的传输级别支持。 BizTalk Server 消息处理与各种“业务线”（LOB）应用程序的集成是使用许多可用的 BizTalk Server 加速器或适配器之一完成的，例如 BizTalk Accelerator for HIPAA、BizTalk Accelerator for SWIFT 或 BizTalk SAP 适配器。 这些加速器和适配器符合行业标准，反过来又适应了 BizTalk Server 与符合特定行业标准的系统直接集成。
能够处理多种消息格式，例如纯文本、XML、二进制文件和其他格式。 此功能对于提供 BizTalk Server 与各种贸易合作伙伴的集成至关重要。
支持消息转换或文档映射。 映射可适应不同架构之间的数据转换。 例如，映射可用于将收到的客户采购订单的内容转换为收据，并发送回客户的发货通知。
BizTalk Server 业务流程编排提供功能，可用于创建跨越时间、组织、应用程序和人员的业务流程。 BizTalk Server 提供业务流程设计器图形界面，用于开发业务流程，包括对事务的支持（传统“原子”MSDTC 类型和长时间运行）、异常处理、调试、跟踪和扩展性，以调用外部代码。
注释
有关在 BizTalk Server 中使用业务流程时要遵循的最佳做法的指南，请参阅 优化业务流程性能 。 有关使用业务流程设计器的详细信息，请参阅 BizTalk Server 文档中的主题 ：使用业务流程设计器创建 业务流程（https://go.microsoft.com/fwlink/?LinkId=158997）。
本主题的其余部分介绍了与 BizTalk Server 环境中处理的消息的大小、复杂性和分发配置文件相关的性能注意事项。
消息大小注意事项
尽管 BizTalk Server 对消息大小没有限制，但实际限制和依赖项可能需要最大程度地减少消息的大小，因为大型消息需要更多的处理资源。 随着消息大小的增加，总吞吐量（每秒处理的消息数）会减少。 在设计方案并规划容量时，请考虑 BizTalk Server 进程的平均消息大小、消息类型和消息数。 不要使用不必要的长属性和标记名称;如果可能，请将长度保留为 50 个字符。 例如，不要为仅有 1 字节大小的消息使用长度为 200 个字符的标签名称。
如果收到的消息的内存中大小超过为大型消息片段指定的字节数（可在 BizTalk Server 管理控制台中 BizTalk 组的“组属性”页上进行配置），消息将拆分为指定大小的片段。 此外，这些片段将写入 Microsoft 分布式事务处理协调器（MSDTC）事务上下文下的消息框，如下所示：
如果在现有 MSDTC 事务的上下文中发布传入消息，则会在将消息片段写入 BizTalk MessageBox 数据库时使用此事务。 例如，如果传入消息由配置为需要事务的事务适配器发布，则会在将消息片段写入 MessageBox 数据库时使用现有事务。
如果未在现有 MSDTC 事务的上下文中发布传入消息，则会创建一个新的 MSDTC 事务以将消息片段写入 MessageBox 数据库。 在此方案中，需要注意以下事项：
增加 大型消息片段大小 的值，以减少大型消息被分段的频率，并减少创建关联的 MSDTC 事务的发生。 应该这样做，因为从性能的角度来看，过度使用 MSDTC 事务的成本很高。 请注意，增加此值也可能增加使用的可用内存量。
如果向 MessageBox 写入消息所需的最大 MSDTC 事务超时时间超过 60 分钟，则事务超时、发生错误，并且尝试写入消息失败并回滚。 应将大消息片段尺寸值增加到足够大，以避免处理非常大消息时出现此问题。 根据可用内存，此值应增加到最大值 1000000 字节。
消息中的每个消息片段都会针对 MessageBox 数据库创建一个或多个 SQL Server 数据库锁。 当锁的数量超过几十万时，SQL Server 可能会生成“锁不足”错误。 如果出现此问题，请增加 大型消息片段大小 的值以减少片段数（这减少了针对 MessageBox 数据库进行的 SQL Server 数据库锁数），或者考虑将 MessageBox 数据库放在 64 位版本的 SQL Server 上。 64 位版本的 SQL Server 上的可用锁数明显高于 32 位版本的 SQL Server。 当 MessageBox 数据库位于 32 位版本的 SQL Server 上时，以下公式可用于估计每个交换的最大消息数：
200,000 / (Number of CPUs * BatchSize * MessagingThreadPoolSize)
有关 BizTalk Server 如何处理大型消息的详细信息，包括处理大型消息的准则，请参阅 BizTalk Server 如何处理大型消息 （https://go.microsoft.com/fwlink/?LinkID=154680）。
消息类型注意事项
消息以两种主要格式之一在 BizTalk Server 中接收：XML 文件或平面文件。 由于 XML 和平面文件消息的资源要求不同，消息类型应始终纳入消息分发配置文件中。
XML 文件 为了使 BizTalk Server 对传递路由以外的消息执行任何处理，该消息必须采用 XML 文件格式。
平面文件 平面文件必须解析为 XML 格式，然后 BizTalk Server 才能执行传递路由以外的任何处理。 将平面文件分析为 XML 文件可以大大增加文件的大小。 平面文件不包含包含有关其数据的描述性信息的 XML 标记。 另一方面，XML 文件将其所有数据包装在描述性 XML 标记中。 在某些情况下，分析可能会将平面文件的大小增加 10 倍或更多，具体取决于文件的 XML 标记中包含的描述性数据量。
包装在 XML 文档的单个 CDATA 节节点中的平面文件文档 这种类型的文档是 XML 和平面文件的组合，并且通常是内存密集型文档，因为 BizTalk Server 在处理文档之前必须将整个包装的平面文件文档加载到内存中。
重载注意事项
大多数 BizTalk Server 应用程序不会以特定的固定速率接收消息。 通常，消息处理受峰值和谷的约束。 例如，网上银行应用程序可能先在早上处理更多的消息量，然后在一天中和一天结束。 应测试 BizTalk Server 解决方案，以确保它们能够处理这些重载方案。 若要确定 BizTalk Server 解决方案如何处理重载方案，应确定 BizTalk Server 解决方案的最大可持续吞吐量（MST）。 MST 是系统可以在生产环境中无限期处理的消息流量的最大负载。 有关 MST 的详细信息，请参阅 规划持续性能 （https://go.microsoft.com/fwlink/?LinkID=158065）和 什么是可持续性能？ （https://go.microsoft.com/fwlink/?LinkID=132304） BizTalk Server 文档中。
架构复杂性
消息分析（尤其是平面文件分析）的吞吐量受架构的复杂性影响。 随着架构复杂性的增加，整体性能会降低。 设计架构时，请减少节点名称的长度，并将提升的属性移动到架构顶部。 这样可以缩短检索时间，从而提高性能。
地图复杂性
根据地图的复杂性，地图转换可能占用大量资源。 随着地图复杂性的增加，整体性能会降低。 若要提高整体性能，请尽量减少地图中使用的链接和函数组件的数量，尤其是调用外部资源（例如 DB Lookup 函数组件）的那些。
平面文件分析注意事项
对平面文件分析性能影响最大的两个因素是文件大小和架构复杂性。 不明确的架构是包含许多可选字段的架构。 当处理较大的文件时，具有许多可选字段的架构可能会降低性能，因为较大的文件可能匹配架构的不同分支。 架构复杂性对较小的文件的影响比对较大的文件的影响要小。