若要横向扩展 BizTalk 层，请将更多硬件添加到现有拓扑。 建议在以下方案中添加硬件：
BizTalk Server 成为瓶颈。 瓶颈本身可能是由以下问题之一引起的：
CPU：如果方案使用 CPU 密集型的管道、映射或业务流程，BizTalk 服务器将没有任何额外的 CPU 余量。
内存和 I/O：如果现有计算机已达到内存和 IO 的最大限制，则添加资源的唯一方法是添加另一个物理计算机。
扩展规模太贵了。 例如，请考虑一种 BizTalk Server 拓扑，在该拓扑中，BizTalk CPU 达到最大容量。 如果添加额外的双处理器计算机比将双处理器升级为四核处理器更便宜，那么应该选择水平扩展系统。
纵向扩展无法解决瓶颈。 在以下情况下，纵向扩展可能不起作用：
IO 已达到 BizTalk 计算机的最大容量，因此你需要另一台计算机来扩展 IO。
内存已达到您的操作系统的最大容量。 在此方案中，缩放系统的唯一方法是向拓扑添加额外的 BizTalk 计算机机器。
在某些情况下，你可能希望专用服务器接收消息、发送消息和处理消息。 拥有专用服务器时，可以更轻松地隔离问题并在一台计算机上执行维护，而不会影响其他计算机。 可以通过扩展 BizTalk 层来添加这些计算机。
无法横向扩展 BizTalk 层时
MessageBox 数据库是瓶颈。
适配器成为瓶颈。 例如，如果使用 SQL 适配器，在增加 BizTalk 接收器数量后，在从中拉取 BizTalk SQL 适配器的 SQL 数据库上锁定争用会增加。 这限制了横向扩展 SQL 适配器的能力。
下图显示了如何横向扩展 BizTalk 层的示例。
下图显示了横向扩展的 BizTalk 拓扑，从一台 BizTalk 服务器扩展到 2 台 BizTalk 服务器。 在一个 BizTalk 服务器拓扑中，三个主机实例共享 BizTalk 计算机资源。 在两个 BizTalk 服务器拓扑中，传输主机分离到不同的服务器上，这可实现更多的吞吐量。
横向扩展 BizTalk 层时的注意事项
在添加另一台 BizTalk Server 计算机之前，必须考虑以下问题：
在横向扩展 BizTalk 层时，如何为系统配置负载均衡和容错？
负载均衡和容错技术的选择取决于方案中使用的适配器。 对于 SOAP 和 HTTP 适配器，建议使用 NLB。 有关更多详细信息，请参阅 NLB 文档。
如何重构主机实例？
在横向扩展 BizTalk 层时，没有任何规则可以确定应如何重构主机实例。 在考虑主机实例时，需要根据方案的复杂性来决定。 下面是一些关于如何分解主机实例的示例。
方案 1
一个 BizTalk 服务器配置，接收和传输主机实例位于同一台计算机上。
假设存在 CPU 瓶颈。 将另一台相同的 BizTalk 计算机添加到组以横向扩展，从而提供两种方法来考虑主机实例。
下面是此问题的两种解决方案：
解决方案 1：在此方案中进行分解的最简单方法是将主机实例从第一台计算机克隆到第二台计算机。 因此，第二台计算机是功能方面第一台计算机的确切副本;它还可以同时具有接收和发送主机。 假设没有其他瓶颈，可能会得到 2 的缩放系数，因为 CPU 资源翻了一番。
解决方案 2：另一种对主机实例进行分解的方法是将接收和发送功能分离到不同的计算机上。 因此，BizTalk 服务器之一专用于接收，其他服务器用于发送。
比较解决方案 1 和解决方案 2
在解决方案 1 中，主机实例数量相较于单机 BTS 配置增加了一倍。 这意味着 SQL Server 上的锁竞争会增加。 锁争用增加的量将决定缩放系数。 如果锁争用远远超出了成为瓶颈的限制，则可以看到缩放系数为 2。
解决方案 2 的优点是只有两个主机实例，因此与解决方案 1 相比，SQL Server 上的锁争用应该更少。 但是，缩放系数完全取决于接收和发送主机实例的复杂性。 请考虑解决方案 2 中的以下情况：
假设接收和传输主机实例同样密集，并且每个实例在一个 BizTalk 服务器拓扑中使用 50% CPU。 在两个 BizTalk 服务器拓扑中，将传输主机实例移动到不同的计算机，现在接收和传输将获取两倍的资源。 这应该提供一个缩放因子为2的效果，前提是没有其他瓶颈。 此情况优于解决方案 1，因为只有两个主机实例，因此锁争用较少。
假设传输比接收更密集，并在一个 BizTalk 服务器拓扑中使用 80% CPU 资源。 通过将传输主机实例移动到另一台计算机，只需获得 20 个% 更多的 CPU 资源，因此最大缩放系数为 1.2。 此外，具有接收主机实例的计算机将仅使用 20-30% CPU 资源，因此横向扩展的优势要少得多。
请考虑下图，其中包含四台 BizTalk 服务器。 每台计算机都是接收方和发送方，总共提供每种类型的四个主机实例（接收和传输）。
此拓扑可能不是可能的最佳拓扑。 还应测试其他因素排列，具体取决于方案的复杂性。 例如：
将两台计算机用于接收，两台计算机用于传输。 当接收和发送的密集性相同时，这可提供最佳缩放效果。
如果接收比传输更密集，请指定三台计算机用于接收和一台用于传输。
如果传输比接收更密集，请指定一台计算机进行接收，3 台计算机用于传输。
建议你在所有方案中，最大限度地减少每个主机的实例数量，以减少 MessageBox 数据库上的争用，并充分使用计算机资源。 最佳分解排列取决于方案和瓶颈类型的复杂性。 在最终排列之前，务必测试因式分解。
另请参阅
纵向扩展 BizTalk Server 层
纵向扩展 SQL Server 层
横向扩展 SQL Server 层
Scaled-Out 接收主机
Scaled-Out 处理器主机
Scaled-Out 发送主机
使用 Windows Server 群集为 BizTalk Server Hosts2 提供高可用性
Scaled-Out 数据库
集群化 BizTalk Server 数据库