这些 Web 前端会将 HTTP(S) 流量发送到一组地区内部应用负载均衡器。若要让外部应用负载均衡器将流量转发到内部应用负载均衡器，外部应用负载均衡器必须将具有 Web 服务器软件（例如 Netscaler 或 NGINX）的后端实例配置为将流量转发内部应用负载均衡器的前端。
内部应用负载均衡器将流量分配到中间件实例组。
这些中间件实例组将流量发送到内部直通式网络负载均衡器，进而对流向数据存储集群的流量进行负载均衡。
多层应用中内部层的基于第 7 层的路由（点击放大）。
多区域负载均衡
在优质层级中配置外部应用负载均衡器时，它会使用全局外部 IP 地址，并且可以根据邻近度，智能地将用户的请求路由到最近的后端实例组或 NEG。例如，如果您在北美、欧洲和亚洲设置实例组，并将其关联到负载均衡器的后端服务，则系统会自动将世界各地的用户请求发送到离用户最近的虚拟机，其中假设虚拟机通过健康检查并具有足够的容量（由平衡模式定义）。如果最近的虚拟机都运行状况不佳，或者最近的实例组已达到容量上限，而另一个实例组未达到容量上限，则负载均衡器会自动将请求发送到具有容量的次近地区。
Cloud Load Balancing 支持将流量代理到 Google Cloud之外的外部后端。如果您想从外部后端传送内容，但希望 Google Cloud 负载均衡器作为前端，则可以使用此类部署。负载均衡器在其大部分旅程中通过使用 Google 高度可靠的骨干网将流量代理到您的外部端点，并且仅移交到靠近目的地的公共互联网。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-04。"],[],[],null,["# External Application Load Balancer use cases\n\nThe external Application Load Balancers address many use cases. This page provides some\nhigh-level examples.\n\nThree-tier web services\n-----------------------\n\nYou can use an external Application Load Balancer to support traditional\nthree-tier web services. The following example shows how you can use three types\nof Google Cloud load balancers to scale three tiers. At each tier, the\nload balancer type depends on your traffic type:\n\n- **Web tier:** Traffic enters from the internet and is load balanced by using\n an [external Application Load Balancer](/load-balancing/docs/https).\n\n- **Application tier:** The application tier is scaled by using a regional\n internal Application Load Balancer.\n\n- **Database tier:** The database tier is scaled by using an\n [internal passthrough Network Load Balancer](/load-balancing/docs/internal).\n\nThe diagram shows how traffic moves through the tiers:\n\n1. An external Application Load Balancer (the subject of this overview) distributes traffic from the internet to a set of web frontend instance groups in various regions.\n2. These web frontends send the HTTP(S) traffic to a set of regional, internal Application Load Balancers. For the external Application Load Balancer to forward traffic to an internal Application Load Balancer, the external Application Load Balancer must have backend instances with web server software (such as Netscaler or NGINX) configured to forward the traffic to the frontend of the internal Application Load Balancer.\n3. The internal Application Load Balancers distribute the traffic to middleware instance groups.\n4. These middleware instance groups send the traffic to internal passthrough Network Load Balancers, which load balance the traffic to data storage clusters.\n\n[](/static/load-balancing/images/ilb-l7-tiers.svg) Layer 7-based routing for internal tiers in a multitier app (click to enlarge).\n\nMulti-region load balancing\n---------------------------\n\nWhen you configure an external Application Load Balancer in Premium Tier, it uses a global\nexternal IP address and can intelligently route requests from users to the\nclosest backend instance group or NEG, based on proximity. For example, if you\nset up instance groups in North America, Europe, and Asia, and attach them to a\nload balancer's backend service, user requests around the world are\nautomatically sent to the VMs closest to the users, assuming the\nVMs pass health checks and have enough capacity (defined by the balancing mode).\nIf the closest VMs are all unhealthy, or if the closest instance group is at\ncapacity and another instance group is not at capacity, the load balancer\nautomatically sends requests to the next closest region with capacity.\n\nIn Premium Tier, the external Application Load Balancer provides\nmulti-region load balancing, using multiple backend services,\neach with backend instance groups or NEGs in multiple regions.\n[](/static/load-balancing/images/https-load-balancer-diagram.svg) Representation of multiregion load balancing (click to enlarge).\n\nWorkloads with jurisdictional compliance\n----------------------------------------\n\nSome workloads with regulatory or compliance requirements require that network\nconfigurations and traffic termination reside in a specific region. For these\nworkloads, a regional external Application Load Balancer is often the preferred\noption to provide the jurisdictional controls these workloads require.\n\nAdvanced traffic management\n---------------------------\n\nWith global external Application Load Balancers and regional external Application Load Balancers, you can add\nadvanced traffic management capabilities that give you fine-grained control over\nhow traffic is handled. These capabilities help you to meet your availability\nand performance objectives. One of the benefits of using\nexternal Application Load Balancers for these use cases is that you can update how\ntraffic is managed without needing to modify your application code.\n\nFor more details, see the following:\n\n- [Traffic management\n overview for global external Application Load Balancer](/load-balancing/docs/https/traffic-management-global).\n- [Traffic management\n overview for regional external Application Load Balancer](/load-balancing/docs/https/traffic-management-regional).\n\nLoad balancing with request routing\n-----------------------------------\n\nThe external Application Load Balancer supports request routing by using URL maps\nto select a backend service based on the requested host name, request path, or\nboth. For example, you can use a set of instance groups or NEGs to handle your\nvideo content and another set to handle everything else.\n\nYou can also use external Application Load Balancers with [Cloud Storage](/storage)\n[buckets](/storage/docs/json_api/v1/buckets). After you have your load balancer\nset up, you can [add Cloud Storage\nbuckets](/load-balancing/docs/https/ext-load-balancer-backend-buckets) to\nit.\n\nFor more information, see [URL map\nconcepts](/load-balancing/docs/url-map-concepts).\n\nLoad balancing for GKE applications\n-----------------------------------\n\nThere are two ways to deploy external Application Load Balancers for GKE clusters:\n\n- **[GKE Gateway\n controller](/kubernetes-engine/docs/concepts/gateway-api).** Supported by the global external Application Load Balancer and the classic Application Load Balancer. For setup instructions, see [Deploying\n gateways](/kubernetes-engine/docs/how-to/deploying-gateways).\n- **[GKE Ingress\n controller](/kubernetes-engine/docs/concepts/ingress-xlb).** Supported by the classic Application Load Balancer and the regional external Application Load Balancer. For setup instructions, see [Configuring Ingress for\n external Application Load Balancers](/kubernetes-engine/docs/how-to/load-balance-ingress).\n\nLoad balancing for Cloud Run, Cloud Run functions, and App Engine applications\n------------------------------------------------------------------------------\n\nYou can use a global external Application Load Balancer as the frontend for your\nCloud Run, Cloud Run functions, and\nApp Engine applications. To set this up, you use a serverless NEG for\nthe load balancer's backend.\n\nThis diagram shows how a serverless NEG fits into the external Application Load Balancer\nmodel.\n[](/static/load-balancing/images/lb-serverless-simple-ext-https.svg) HTTPS load balancing for serverless apps (click to enlarge).\n\nRelated documentation:\n\n- [Serverless NEGs overview](/load-balancing/docs/negs/serverless-neg-concepts)\n- [Setting up an external Application Load Balancer with\n Cloud Run, Cloud Run functions, or\n App Engine](/load-balancing/docs/https/setting-up-https-serverless)\n\nProxying traffic to external backends with internet connectivity\n----------------------------------------------------------------\n\nCloud Load Balancing supports proxying traffic to external backends\noutside Google Cloud. You can use this type of deployment when you want to serve\ncontent from an external backend, but you want your Google Cloud load\nbalancer to be the frontend. The load balancer proxies traffic to your external\nendpoint by using Google's highly reliable backbone network for most of its\njourney, and only hands off to the public internet close to the destination.\n[](/static/load-balancing/images/internet-neg-sample-arch.svg) Internet network endpoint groups in load balancing (click to enlarge).\n\nRelated documentation:\n\n- [Set up a global external Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setup-global-ext-https-external-backend)\n- [Set up a classic Application Load Balancer with an internet\n NEG](/load-balancing/docs/https/setting-up-https-external-backend-internet-neg)\n\nLoad balancing with hybrid connectivity\n---------------------------------------\n\nCloud Load Balancing supports load-balancing traffic to endpoints that extend\nbeyond Google Cloud, such as on-premises data centers and other public clouds\nthat you can use [hybrid connectivity](/hybrid-connectivity) to reach.\n\nThe following diagram demonstrates a hybrid deployment with a\nglobal external Application Load Balancer.\n[](/static/load-balancing/images/ext-https-hybrid.svg) Hybrid connectivity with an external Application Load Balancer (click to enlarge).\n\nRelated documentation:\n\n- [Hybrid connectivity NEGs overview](/load-balancing/docs/negs/hybrid-neg-concepts)\n- [Setting up an external Application Load Balancer with on-premises or other cloud\n backends](/load-balancing/docs/https/setting-up-ext-https-hybrid)\n\nLoad balancing with Private Service Connect\n-------------------------------------------\n\nYou can use a global external Application Load Balancer to access services that are\npublished using Private Service Connect.\n\nFor more information, see\n[About Private Service Connect backends](/vpc/docs/private-service-connect-backends)."]]
