Azure ASE前端负载均衡机制及Worker节点负载分配方式咨询

Great question—ASE’s frontend and worker layer mechanics can feel a bit tricky at first, so let’s break this down clearly.

1. How Requests Are Distributed Across Multiple Frontend Nodes #

To address your core concern first: you’re right that a single entry point is critical for avoiding the "problem we’re trying to solve" with load balancing. Here’s how it works:

• Your ASE’s frontend nodes aren’t directly exposed to end-users. All incoming requests first hit an Azure-managed load balancer (public for external ASEs, internal ILB for private ASEs). This is the single logical entry point that handles traffic distribution to your multiple frontend nodes.
• The underlying load balancer uses a source IP hash algorithm (combining the client’s source IP address and port) to map requests to specific frontend nodes. This ensures session affinity (same client requests stick to the same frontend node) while evenly distributing load across available frontend nodes.
• The auto-scaling of frontend nodes (triggered by worker node count increases) is handled entirely by Azure’s infrastructure—you don’t need to manage the distribution logic here, as the upstream load balancer seamlessly incorporates new frontend nodes into the pool.

2. Worker Node Load Allocation: Is It Simple Round-Robin? #

Short answer: No, it’s not simple round-robin. Here’s the actual mechanism:

• Frontend nodes track the current request queue length and load of each worker node in your ASE. When a new request comes in, the frontend uses a least connections algorithm to route it to the worker node with the shortest active request queue (i.e., the least loaded node at that moment).
• This approach is far more efficient than round-robin because it accounts for real-time worker load. Round-robin would blindly send requests to workers in sequence, which can lead to uneven load if some workers process requests slower than others. The least connections method ensures requests are routed to the most available worker.
• If your application relies on session state, you can enable ARR Affinity in your App Service configuration. This will make the frontend node stick a client’s requests to the same worker node for the duration of the session (or until the worker becomes unavailable).

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