用户投稿Okay, let's break down the implementation of a unified Layer 7 load balancer at 360 (Qihoo 360). It's important to understand that a large company like 360, especially one heavily involved in security, search, and online services, would likely deploy a sophisticated, multi-faceted load balancing strategy rather than relying on a single monolithic solution for everything.
Here's a plausible scenario for how they might have approached "unified Layer 7 load balancing"落地 (landing/deployment):
"1. Understanding the "Unified" Goal in 360's Context:"
"Multiple Needs:" They need to balance traffic for web applications, APIs, microservices, internal services, and potentially large-scale user-facing services (like search or news feeds).
"Multiple Domains:" Traffic might come from different sources (web portals, mobile apps, specific partners) requiring potentially different routing logic.
"Multiple Requirements:" Needs vary – high availability, performance, security filtering, rate limiting, SSL offloading, complex path-based routing.
"Unified Ideally Means:" Centralized management, consistent policies where appropriate, leveraging shared infrastructure and skills, potentially integrating with other internal systems (like monitoring, logging, security intelligence).
"2. Likely Technologies Used (A Plausible Mix):"
Given 360's scale and focus areas, they would likely use a combination of solutions:
"Commercial Enterprise LB (Primary for High-Performance/Complex Needs):
相关内容：
一. 项目背景
七层负载均衡工作在OSI模型的应用层，支持HTTP/HTTPS等协议深度解析，支持丰富的高级转发规则。与四层负载均衡单纯关注IP+端口不同，七层负载均衡能够理解应用层协议内容，实现更精细化的流量控制。
公司原有七层负载均衡存在以下两点问题：
1）适用于经典网络场景，不支持专有网络(Virtual Private Cloud，简称VPC)，无法满足云上租户需求
2）后端主机组支持裸金属和虚拟机，缺失了云原生场景
基于上述问题，统一七层负载均衡项目产生，旨在通过一套负载均衡服务，支持混合网络架构，后端主机适配多种实例类型。服务主要有以下特点：
- 智能路由决策：通过解析HTTP头信息（User-Agent、Cookie）、URL路径、SSL会话ID等参数实现精细化流量调度
- 会话保持机制：通过注入Cookie或生成SessionID确保用户请求持续指向同一后端服务器
- 主动健康检查：主动探活后端upstream存活状态，避免upstream异常引发请求异常
- 配置热加载：配置统一变更可实时生效，减少配置维护复杂度
- 高可用：通过集群容灾、会话保持、可用区多活等机制保障实例的可用性
二. 统一七层负载均衡服务架构设计
1. 服务整体架构
统一七层负载均衡架构分为控制面和转发面两部分，如图2.1所示。
控制面除原有LBC-API(四七层共用)外，还引入apisix admin API用于七层规则的下发。存储使用ETCD集群，毫秒级的变化通知机制，使得配置变更达到实时的效果，支持集群管理，更好的适配容器场景。VPC场景下，控制面为VPC内upstream分配一个唯一IP用于替换upstream的真实VPC IP。
第二部分是转发面，真正去处理来自客户端请求，转发用户的真实流量，支持多种功能，如身份验证、证书卸载、日志分析和可观测性等，不做数据的存储。VPC场景中，转发面复用FNAT网关转发逻辑，根据唯一IP和真实VPC IP的映射关系，将流量封装VXLAN后发送至upstream所在宿主机。
图2.1 服务架构图
七层相关资源如service、route、upstream等可通过调用LBC-API创建/删除/修改
1. API会继续调用admin api vip将请求写入ETCD集群
2. LBC-AGENT程序监听ETCD变更，将VPC映射配置通过命令下发至FNAT转发面
3. 转发面监听ETCD变更，使得七层转发规则生效
4. IDC流量直接转发至对应IP，VPC内流量经过额外封装转发至对应宿主机
5. 业务申请域名解析，将域名解析到对应的VIP(EIP/VPC内VIP)即可访问使用
2.服务部署架构
服务部署架构如图2.2所示
- 统一接口：stack平台为统一请求入口，对外提供openAPI供业务方调用，容器云通过该入口进行七层负载均衡资源的接口操作，后续其他业务统一走openAPI接入。
- 高可用：控制面/存储地域级别部署，转发面可用区(AZ)粒度集群模式部署，单台服务器宕机，请求自动切到集群其他台。
- 四七层混合部署：复用四层已有能力，减少额外开发
图2.2 统一七层服务部署架构图
三. 统一七层负载均衡流量路径
如图3.1所示，流量分为云上云下两种场景：
- 经典网络七层流量：公网EIP -> 四层负载均衡集群(idc vip) -> 七层负载均衡网关 -> IDC可达IP(包括虚机/POD等)
- VPC云上七层流量：公网EIP -> 四层负载均衡集群(vpc vip) -> 七层负载均衡网关(vxlan封装) -> VPC内IP(包括虚机/POD等)
3.1 七层负载均衡流量路径图
四. 总结展望
当前统一七层负载均衡服务已经在公司三个地域全部上线，容器服务也适配完成。目前统一七层负载均衡仅支持了较为基础的功能，还有更多的功能扩展，如：SSL卸载优化、转发规则支持重定向、流量镜像、支持更多协议类型等，并逐步向智能化发展，从单纯的流量分发工具演变成智能调度中枢。
更多负载均衡技术和产品，尽在360智汇云。360智汇云官网：智汇云-企业数智化核心引擎
微信扫一扫打赏
支付宝扫一扫打赏
