在大型Web系统部署中，单独使用一层负载均衡往往难以同时满足弹性扩容、精细路由和运维可控等需求。将阿里云SLB放在流量最前端，后方接Nginx集群再做一次应用层转发，能够有效解耦基础设施与业务逻辑。SLB处理来自公网的并发连接，Nginx则面向具体服务做反向代理与策略控制，两者配合可以形成清晰的多层负载均衡架构。
网络拓扑与流量路径设计
典型的多层负载均衡拓扑以阿里云SLB作为第一层入口，它可以是四层TCP/UDP监听，也可以是七层HTTP/HTTPS监听。SLB后端挂载多个ECS实例，这些ECS上运行Nginx，由Nginx再把请求转发给本机或同可用区内的应用服务（如Tomcat、Node.js、Go服务）。这样的结构让SLB只关心实例级别的健康状态，而Nginx可以针对URL、Header或客户端IP做更细粒度的分发。
从流量路径看，用户请求先到达SLB的VIP，SLB依据调度算法选出一台ECS，把报文转发过去。Nginx收到请求后，根据server_name和location规则决定上游服务，并通过proxy_pass完成代理。由于SLB到Nginx一般为内网通信，延迟极低，因此增加这一层并不会明显拖慢响应，却换来了灵活的运维手段。例如可在Nginx层做AB测试，而不必改动SLB配置。
需要注意的是，如果SLB使用七层监听，它已经做了一次HTTP解析，Nginx收到的可能是经过改写头的请求。此时要确认X-Forwarded-For等字段的传递方式，避免后端应用获取到错误的客户端真实IP。建议在Nginx中通过real_ip模块还原来源地址，保持日志与风控逻辑准确。
SLB与Nginx的配置差异和协同要点
阿里云SLB的控制台配置偏向基础设施维度：设定监听端口、后端服务器组、健康检查阈值和会话保持方式。它的优势在于与云网络深度集成，支持跨可用区容灾，且扩容时只需往服务器组添加ECS。Nginx的配置则集中在nginx.conf及conf.d下的站点文件，强调单台机器内的请求处理流程，比如限流、重写、缓存和TLS终止。
两者协同时要特别关注超时与保活参数。SLB的连接超时若短于Nginx向上游请求的等待时间，就会出现服务端还在处理、前端已被断开的假错误。通常把SLB的空闲超时设为略大于Nginx的proxy_read_timeout，例如SLB设60秒、Nginx设55秒。同时开启SLB的健康检查，使其只转发到Nginx进程正常的机器，而Nginx自身用max_fails与fail_timeout屏蔽异常上游。
下面是一段Nginx反向代理到本地应用的精简配置，展示了关键参数如何书写：
upstream app_cluster {
server 127.0.0.1:8080 max_fails=3 fail_timeout=30s;
server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
}
server {
listen 80;
server_name example.ipipp.com;
location / {
proxy_pass http://app_cluster;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_connect_timeout 5s;
proxy_read_timeout 55s;
proxy_send_timeout 55s;
}
}
这段配置中，upstream定义了两个本地应用端口，Nginx会在它们之间进行负载均衡。即便前面有SLB再做一层分发，Nginx这一层仍能避免单应用进程过载。若某端口连续失败三次且在30秒内，Nginx会暂时摘除它，这与SLB的健康检查形成双重保护。
常见故障排查与性能优化思路
多层架构带来排查复杂度。当用户反馈访问变慢，首先要分清瓶颈在SLB还是在Nginx。可以通过SLB的监控查看流入带宽、新建连接数和后端响应时间；若SLB指标正常但Nginx机器CPU偏高，则问题多在Nginx或上游应用。此时应检查Nginx的worker_connections是否过小，以及是否开启了对静态资源的缓存。
另一个典型问题是会话保持错乱。若SLB开启了基于Cookie的会话保持，而Nginx又做了URL哈希，可能导致用户请求被不同机制拉扯。一般建议只在其中一层做会话保持：对外用SLB的会话保持保证用户落到固定ECS，Nginx层则无状态转发；或者关闭SLB会话保持，由Nginx的ip_hash来稳定路由。选择哪种取决于应用是否依赖本地会话。
性能方面，可以让SLB终止SSL，Nginx与SLB之间走HTTP，减少ECS的加解密开销。如果业务要求端到端加密，则在Nginx上也配置证书，但要注意SLB健康检查路径不能因为HTTPS重定向而失败。此外，Nginx的gzip压缩和proxy_cache能显著降低回源率，下面的配置展示了基础缓存开启方式：
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=one:10m max_size=1g inactive=60m;
server {
listen 80;
server_name example.ipipp.com;
location /static/ {
proxy_pass http://app_cluster;
proxy_cache one;
proxy_cache_valid 200 302 10m;
proxy_cache_valid 404 1m;
add_header X-Cache-Status $upstream_cache_status;
}
}
通过缓存静态资源，Nginx能直接返回命中内容，不必每次都穿透到应用，这减轻了SLB后端整体压力。结合云监控与Nginx的stub_status模块，运维人员能够清楚看到每一层的吞吐与命中率，从而精准扩容或调参。多层负载均衡不是简单堆叠，而是让每层各司其职，最终达到稳定与效率的平衡。