应用负载均衡和网络负载均衡的区别：从OSI七层模型看技术选型
阿里云的负载均衡产品有好几种，应用型（ALB）、网络型（NLB）、传统型（CLB），光看名字就容易搞混。其中最常纠结的是ALB和NLB该选哪个，功能介绍一堆专业术语，七层负载、四层负载、会话保持、SSL卸载，听着都差不多。实际上两者的技术原理和适用场景完全不同，选错了可能导致性能浪费或功能不足。本文从底层原理讲起，帮你彻底搞懂这两种负载均衡的差异。
四层 vs 七层：工作在不同的网络层次
NLB是四层（传输层）负载均衡，工作在TCP/UDP协议层，只看IP和端口，不解析应用层内容。就像一个交通指挥，根据车牌号（IP）分配车道，不管车里装的是什么货物。ALB是七层（应用层）负载均衡，工作在HTTP/HTTPS协议层，能解析请求的URL、Header、Cookie等内容，根据应用层信息做智能分发。就像一个快递分拣中心，打开包裹看收件地址再决定送到哪个仓库。这个差异决定了两者的性能和功能边界：NLB性能高延迟低，但功能简单；ALB功能丰富，但要解析HTTP协议，性能稍低。
性能和吞吐量：NLB的极致性能
NLB因为只处理四层协议，不需要解析应用层数据，性能非常高。单实例可以处理百万级并发连接，吞吐量可达数十Gbps，延迟在微秒级。适合对性能要求极高的场景，比如游戏服务器、消息队列、数据库集群、实时音视频。ALB需要解析HTTP请求，建立完整的HTTP连接，性能相对较低，单实例处理十万级并发，延迟在毫秒级。但对于普通Web应用，ALB的性能完全够用，瓶颈通常在后端服务器而不是负载均衡。如果你的业务QPS超过10万，或者需要极低延迟（如高频交易），优先考虑NLB。
协议支持：HTTP之外的世界
ALB只支持HTTP和HTTPS协议，这是它的天然限制。如果你的应用用的是TCP、UDP、WebSocket、gRPC over HTTP2，ALB都能处理（WebSocket和HTTP2都基于HTTP）。但如果是原生TCP协议（如MySQL、Redis、MongoDB）、UDP协议（如DNS、QUIC、游戏），就必须用NLB。NLB支持所有四层协议，包括TCP、UDP、TCP SSL。举个例子，做一个实时对战游戏，客户端和服务器用UDP通信，只能用NLB；做一个Web应用，用HTTP/HTTPS，ALB和NLB都行，但ALB的七层功能更有用。
七层功能：ALB的智能路由
ALB的核心优势是基于HTTP内容的智能路由。可以根据域名、URL路径、HTTP方法、Header、Cookie把请求分发到不同的后端服务器组。比如/api/*的请求发到API服务器，/static/*的请求发到静态资源服务器，不同子域名发到不同应用。还支持HTTP重定向、重写URL、自定义响应头，在负载均衡层面就能做很多流量控制。NLB没有这些功能，只能根据IP和端口做简单的负载分发，无法感知应用层内容。如果你的架构是微服务、需要按路径分流、或者做灰度发布，ALB是必选。单体应用或非HTTP协议，用NLB就够了。
SSL卸载和证书管理
ALB支持SSL卸载，可以在负载均衡层面终结HTTPS连接，后端服务器只需要处理HTTP，减轻加解密压力。支持SNI（一个IP多个证书）、HTTP/2、强制HTTPS跳转。NLB也支持TCP SSL卸载，但功能比ALB简单，不支持SNI和HTTP/2。如果你的应用是HTTPS服务，用ALB更方便，证书管理、协议升级都在负载均衡层面搞定。如果是TCP加密连接（如MySQL over TLS），NLB的TCP SSL也能用，但要注意NLB不解析HTTP，无法根据域名选择证书。
会话保持：实现方式不同
两种负载均衡都支持会话保持（Session Sticky），但实现方式不同。NLB的会话保持基于源IP，同一个IP的请求始终发到同一台后端服务器，简单粗暴但有局限：如果用户IP变了（如移动网络切换），会话就断了。ALB的会话保持可以基于Cookie，更精准也更灵活，即使IP变了，只要Cookie在就能保持会话。对于需要会话保持的应用（如有状态的WebSocket、游戏房间），ALB的Cookie方案更可靠。但如果后端服务器本身就支持分布式会话（如Redis存储session），不需要会话保持，NLB和ALB都行。
成本和计费：按性能付费
NLB和ALB的计费模式类似，都是按实例费+流量费。但NLB的实例费稍便宜，因为功能简单资源消耗少。如果只是做简单的TCP负载，用NLB能省一点钱。但差异不大，几十块钱的差别。真正影响成本的是流量费和实例规格。如果业务流量大，选对规格（小型、中型、大型）更重要，规格太小会限速，规格太大浪费钱。建议先用按量付费跑一段时间，看实际流量和连接数，再选择合适规格并切换到包年包月，能便宜20-30%。
常见问题
gRPC微服务应该用ALB还是NLB？
gRPC基于HTTP/2，两种都支持。如果需要根据gRPC方法名路由（需要解析HTTP2 Header），用ALB；如果只是简单负载分发，NLB性能更高。大部分情况推荐ALB，功能更灵活。
WebSocket长连接用哪个负载均衡？
两种都支持WebSocket。ALB能识别Upgrade Header自动切换协议，配置更简单；NLB把WebSocket当普通TCP处理，需要确保会话保持。推荐用ALB，对WebSocket支持更友好。
已经有Nginx做七层负载，还需要ALB吗？
看规模和需求。小规模业务自建Nginx够用；流量大了ALB的高可用、弹性扩容、健康检查更省心，不用担心Nginx本身的单点问题。可以ALB+Nginx双层架构，ALB做接入层，Nginx做应用层路由。
总结
应用负载均衡ALB和网络负载均衡NLB的核心差异在于工作层次：ALB在七层能感知HTTP内容，适合Web应用和微服务；NLB在四层性能极致，适合非HTTP协议和高性能场景。选型的关键是看协议类型和功能需求：HTTP/HTTPS应用优先ALB，享受智能路由和SSL卸载；TCP/UDP应用或追求极致性能用NLB。大部分Web业务ALB是更好的选择，功能丰富覆盖面广。非要在性能和功能之间二选一，先确认瓶颈在哪里，别过早优化。理解底层原理，选型就不会错。