How a Unified Layer‑7 Load Balancer Powers Hybrid Cloud Traffic Management
This article explains the design, features, and deployment architecture of a unified Layer‑7 load‑balancing service that supports both classic and VPC networks, offering intelligent routing, session persistence, health checks, hot‑config reload, and high availability for cloud‑native environments.
Project Background
Layer‑7 load balancing operates at the application layer of the OSI model, parsing HTTP/HTTPS protocols and supporting advanced forwarding rules. Existing solutions lacked VPC support and cloud‑native backend types, prompting the development of a unified service that accommodates hybrid network architectures and multiple instance types.
Intelligent routing decisions : parses HTTP headers (User‑Agent, Cookie), URL paths, SSL session IDs, etc., for fine‑grained traffic scheduling.
Session persistence : injects cookies or generates SessionIDs to keep a user’s requests directed to the same backend.
Active health checks : probes upstream health to avoid request failures caused by unhealthy backends.
Hot configuration reload : real‑time application of configuration changes, reducing maintenance complexity.
High availability : cluster disaster recovery, session stickiness, and multi‑AZ deployment ensure instance reliability.
1. Overall Service Architecture
The unified Layer‑7 load‑balancer consists of a control plane and a forwarding plane (see image). The control plane adds an Apisix admin API for rule distribution, stores configurations in an ETCD cluster with millisecond‑level change notifications, and assigns a unique IP to each VPC upstream to replace the real VPC IP. The forwarding plane handles client requests, providing authentication, certificate offloading, logging, and observability without storing data; in VPC scenarios it reuses the FNAT gateway, encapsulating traffic with VXLAN before sending it to the upstream host.
2. Service Deployment Architecture
The deployment architecture (see image) features a unified API entry (stack platform) exposing OpenAPI for business calls, region‑level deployment of the control plane and storage, and AZ‑granular cluster deployment of the forwarding plane. It also supports mixed Layer‑4/Layer‑7 deployment, reusing existing Layer‑4 capabilities to reduce development effort.
3. Traffic Path
Traffic flows differ for classic and VPC scenarios (see image). Classic network: Public EIP → Layer‑4 LB cluster (IDC VIP) → Layer‑7 LB gateway → IDC‑reachable IPs (VMs, PODs). VPC cloud: Public EIP → Layer‑4 LB cluster (VPC VIP) → Layer‑7 LB gateway (VXLAN encapsulation) → VPC internal IPs (VMs, PODs).
Conclusion and Outlook
The unified Layer‑7 load‑balancing service is now live in three regions and fully integrated with container services. While basic functions are available, future enhancements will include SSL offload optimization, advanced forwarding rules (redirection, traffic mirroring), support for more protocols, and progressive intelligence to evolve from a simple traffic distributor to a smart scheduling hub.
Signed-in readers can open the original source through BestHub's protected redirect.
This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactand we will review it promptly.
360 Zhihui Cloud Developer
360 Zhihui Cloud is an enterprise open service platform that aims to "aggregate data value and empower an intelligent future," leveraging 360's extensive product and technology resources to deliver platform services to customers.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.