Azure应用服务计划（ASP）不同应用的流量负载均衡机制是怎样的？

首先你的猜想是正确的：该场景和单Web服务器托管多站点的虚拟主机逻辑本质相似，核心就是通过请求URL对应的域名（即HTTP请求的Host头）区分不同应用的流量，只是Azure App Service在此基础上叠加了跨节点的全局负载调度能力，具体流转逻辑如下：

流量处理全流程（对应你给出的场景） #

你提到的场景：2个工作节点的ASP，部署2个应用，每个节点上各运行1个app1实例、1个app2实例，总计4个应用实例，流量会经过两层处理：

1. 前端负载均衡层处理 #

• 入站请求首先到达ASP对应的前端负载均衡集群，集群会先读取请求的Host头，判断目标是app1.azurewebsites.net还是app2.azurewebsites.net
• 前端会实时维护所有应用实例的健康状态，匹配到目标应用后，会按照默认的轮询策略（如果开启了会话关联性则会把同一客户端的请求固定到同一个实例），把请求转发到目标应用的健康实例上，不会出现app1的请求被发送到app2实例的情况

2. 工作节点内部路由 #

• 请求被转发到具体的工作节点后，节点上的Web服务器（Windows计划为IIS，Linux计划为Nginx）会再次通过Host头匹配，把请求路由到节点上对应应用的运行进程中，这一步和你熟悉的单服务器托管多站点的虚拟主机逻辑完全一致

和单服务器多站点的核心差异 #

• 单服务器多站点的路由仅局限在单个节点内，而Azure的这套逻辑是跨多节点的：如果某一个工作节点故障，前端负载均衡会自动把流量调度到其他正常节点上的对应应用实例，不会影响业务可用性
• 同一ASP下的不同应用可以单独配置实例数，比如你可以单独把app1横向扩展到3个实例，app2保持2个实例，前端负载均衡会自动识别每个应用的实例规模做调度，不同应用之间的资源隔离、扩缩容逻辑完全互不干扰

内容的提问来源于stack exchange，提问作者toto'