本文介绍流量分发如何与应用程序代理部署配合使用。 了解流量如何在用户和连接器之间分布，以及优化连接器性能的提示。 了解连接器和后端应用服务器之间的流量如何流动，并建议在多个后端服务器之间进行负载均衡。
跨连接器的流量分布
连接器根据高可用性原则建立其连接。 不能保证流量均匀分布在连接器之间，并且没有会话相关性。 但是，使用情况会有所不同，请求会随机发送到应用程序代理服务实例。 因此，流量通常几乎均匀地分布在连接器中。 此图和步骤说明了如何在用户和连接器之间建立连接。
- 客户端设备上的用户尝试访问通过应用程序代理发布的本地应用程序。
- 请求通过 Azure 负载均衡器来确定应由哪个应用程序代理服务实例处理。 有数十个实例可用于接受区域中所有流量的请求。 此方法有助于在服务实例之间均匀分配流量。
- 请求将发送到 服务总线。
- 服务总线向可用连接器发送信号。 然后，连接器从服务总线选取请求。
- 在步骤 2 中，请求转到不同的应用程序代理服务实例，因此更有可能使用不同的连接器建立连接。 因此，连接器几乎在组内被均匀使用。
- 连接器将请求传递给应用程序的后端服务器。 然后，应用程序会将响应发送回连接器。
- 连接器通过从请求所在的服务实例打开出站连接来完成响应。 然后，此连接将立即关闭。 默认情况下，每个连接器限制到 200 个并发的出站连接。
- 然后，响应会从服务实例传回客户端。
- 来自同一连接的后续请求重复这些步骤。
应用程序通常具有许多资源，并在负载不足时打开多个连接。 每个连接都会经过步骤最终被分配给一个服务实例。 如果连接未与连接器配对，请选择新的可用连接器。
连接器高可用性的最佳做法
由于流量在连接器之间分布以实现高可用性的方式，因此必须始终在连接器组中至少有两个连接器。 首选三个连接器在连接器之间提供额外的缓冲区。 若要确定所需的连接器数量正确，请遵循容量规划文档。
将连接器放置在不同的出站连接上，以避免单一故障点。 如果连接器使用相同的出站连接，则连接出现问题会影响使用该连接的所有连接器。
避免在连接到生产应用程序时强制连接器重启。 这样做可能会对跨连接器的流量分布产生负面影响。 重启连接器会导致更多连接器不可用，并强制连接到剩余的可用连接器。 结果是连接器在初期使用不均衡。
避免对连接器与 Azure 之间的出站传输层安全性（TLS）通信进行任何形式的内联检查。 这种类型的内联检查会导致通信流降低。
请确保让连接器的自动更新持续运行。 如果专用网络连接器 Updater 服务正在运行，连接器会自动更新并接收最新升级。 如果在服务器上看不到连接器更新程序服务，则需要重新安装连接器以获取任何更新。
连接器和后端应用程序服务器之间的流量流
高可用性的另一个关键领域是连接器与后端服务器之间的连接。 当应用程序通过 Microsoft Entra 应用程序代理发布时，从用户到应用程序的流量流经三个跃点：
- 用户连接到 Azure 上的 Microsoft Entra 应用程序代理服务公共终结点。 客户端的公共发起者 IP 地址与应用程序代理终结点的 IP 地址之间建立连接。
- 专用网络连接器从应用程序代理服务拉取客户端的 HTTP 请求。
- 专用网络连接器连接到目标应用程序。 连接器使用自己的 IP 地址建立连接。
X-Forwarded-For 标头字段注意事项
在某些情况下（例如审核、负载均衡等），需要将外部客户端的发起 IP 地址与本地环境共享。 为了满足要求，Microsoft Entra 专用网络连接器在 HTTP 请求中添加了包含发起客户端 IP 地址（公共）的 X-Forwarded-For 标头字段。 然后，相应的网络设备（负载均衡器、防火墙）或 Web 服务器或后端应用程序可以读取和使用信息。
在多个应用程序服务器之间进行负载均衡的最佳做法
当分配给应用程序代理应用程序的连接器组具有两个或多个连接器时，负载均衡非常重要。 在多台服务器上运行后端 Web 应用程序时，负载均衡也很重要。
方案 1：后端应用程序不需要会话持久性
最简单的方案是后端 Web 应用程序不需要会话粘性（会话持久性）。 后端应用程序实例处理服务器场中的用户请求。 可以使用第 4 层负载均衡器并将其配置为没有相关性。 某些选项包括Microsoft网络负载均衡和 Azure 负载均衡器或来自其他供应商的负载均衡器。 或者，配置轮循机制域名系统（DNS）策略。
方案 2：后端应用程序需要会话持久性
在此方案中，后端 Web 应用程序需要在经过身份验证的会话期间保持会话粘性（会话持久性）。 后端应用程序实例处理用户请求。 请求在服务器场中的同一服务器上运行。 此方案可能更为复杂，因为客户端通常与应用程序代理服务建立多个连接。 通过不同连接发出的请求可能到达场中的不同连接器和服务器。 由于每个连接器使用此通信的自己的 IP 地址，因此负载均衡器无法确保基于连接器的 IP 地址的会话粘性。 不能使用源 IP 相关性。 下面是方案 2 的一些选项：
选项 1：将会话持久性以负载均衡器设置的会话 Cookie 为基础。 建议使用此选项，因为它允许在后端服务器之间更均匀地分布负载。 它需要具有此功能的第 7 层负载均衡器，并且可以处理 HTTP 流量并终止 TLS 连接。 可以使用 Azure 应用程序网关（会话相关性）或来自其他供应商的负载均衡器。
选项 2：根据 X-Forwarded-For 头字段设置会话持久性。 此选项需要具有此功能的第 7 层负载均衡器，并且可以处理 HTTP 流量并终止 TLS 连接。
选项 3：将后端应用程序配置为不需要会话持久性。
若要了解后端应用程序的负载均衡要求，请参阅软件供应商的文档。