Azure App Service Plan横向扩展的负载均衡机制及请求溯源问询

Great question—let’s break this down clearly since App Service’s PaaS nature makes its load balancing work a bit differently than traditional IaaS setups.

1. Azure如何实现App Service Plan的负载均衡？ #

Azure App Service relies on a platform-managed load balancing layer (built on Azure’s internal infrastructure and Front Door) to distribute traffic across your scaled-out instances. Here’s the breakdown:

• Default distribution: By default, it uses a round-robin algorithm to spread requests evenly across all healthy instances, ensuring no single instance gets overloaded with consistent traffic.
• Health check integration: The platform continuously monitors each instance’s health. If an instance becomes unresponsive or fails health checks, it’s automatically removed from the traffic pool until it recovers.
• Optional session affinity: You can enable ARR Affinity (Application Request Routing Affinity) in your App Service settings. When turned on, the load balancer sets a ARRAffinity cookie on client requests, making sure subsequent requests from the same client land on the same instance. Keep in mind this can reduce load uniformity for long-lived sessions, so only use it if your app requires sticky sessions.

2. 为什么看不到对应的负载均衡器资源？ #

This is a core trait of PaaS services! The load balancer powering App Service is a managed Azure infrastructure component—it’s not exposed as a visible resource in your subscription or resource group. Azure handles all maintenance, scaling, and configuration of this LB behind the scenes. Just like you don’t see the physical servers hosting your app, this abstraction lets you focus on your code instead of managing low-level infrastructure.

3. 如何追踪具体请求由哪个实例处理？ #

There are several simple ways to pinpoint which instance handled a request:

• Add a custom response header: Modify your app to include a header like X-App-Instance-ID that returns the value of the WEBSITE_INSTANCE_ID environment variable (this is unique to each instance). For example, in ASP.NET Core, you could add middleware to inject this header automatically for every response.
• Check App Service logs: Enable HTTP logs or application logs in your App Service’s monitoring settings. These logs include the instance ID tied to each request—you can view them directly in the Azure Portal, download them, or stream them in real time.
• Leverage Application Insights: If you’ve integrated Application Insights with your app, every request trace includes a cloud_RoleInstance property showing the instance ID. You can filter and visualize this data in the Application Insights portal to track instance usage over time.
• Use the Kudu (SCM) tool: Navigate to <your-app-name>.scm.azurewebsites.net to access the Kudu dashboard. Here you can:
  • Go to Process Explorer to see the current instance’s ID.
  • Check the Environment tab to view the WEBSITE_INSTANCE_ID value for the instance you’re connected to.
  • Browse the Logs section to find request details linked to specific instances.

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