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