转载

LB 负载均衡的层次结构

作为后端应用的开发者，我们经常开发、调试、测试完我们的应用并发布到生产环境，用户就可以直接访问到我们的应用了。但对于互联网应用，在你的应用和用户之间还隔着一层低调的或厚或薄的负载均衡层软件，它们不显山不露水默默的发挥着重要的作用，以至于我们经常忽略了它们的存在。因为负载均衡层通常不在一般开发人员的问题域内，而且它们一般都是现成且成熟的解决方案，以至于我们习惯性的忽略和认为乏善可陈。其实不然，本文就写写我对负载均衡层次结构的认知和理解。

硬负载

所谓「硬负载」就是采用硬件设备来提供负载均衡。

在七、八年前那时我在做 Java 的企业软件开发，开发出来的企业级 Java 应用程序就部署在像 Weblogic 之类的应用容器中。而这类应用容器软件又跑在 Unix 的小型机上。把硬件和软件一体打包作为企业应用解决方案卖给客户。这类应用部署的方案十分简单，层级也比较浅。为了保证可靠性，使用两套小型机上各部署一个 Weblogic Server，在应用服务前面使用像 F5 之类的硬件负载均衡器，如下图所示。

LB 负载均衡的层次结构

由于小型机和前面的 F5 负载均衡硬件都比较贵，所以出于可靠性、可维护性和成本的综合考虑，一般应用部署两套跑在两台小型机上，在前面共享一个 F5 做负载均衡。而一般 F5 和小型机这类硬件设备都至少是 5 个 9 的可靠性保障，所以整体的系统可靠性基本有保障。

进入互联网时代后，应用开发拥抱开源，部署使用更廉价的 PC Server 和免费开源的应用容器。负载均衡也逐步从硬负载向软负载变迁，由于互联网应用的海量特性和部署规模的急剧膨胀，前端负载均衡也开始变得丰富起来。

软负载

进入互联网公司后，我们刚开始开发应用时，业务规模小用户量还不大，机器数量也少（<10）。所以一开始的负载均衡的结构也是很简单的，类似硬负载只是把硬件换成了免费的开源软件并跑在可用性是有 3 个 9 的廉价 PC Server 上。

LB 负载均衡的层次结构

前面一个 LVS 后面跟着几个应用服务，后来为了方便做按域名的分流和适配切流量上线，中间又加了一层 Nginx。

LB 负载均衡的层次结构

这样就变成了两层软负载结构了，LVS 负责 4 层，Nginx 负责 7 层。但 Nginx 只负责了单机内多实例的负载均衡，这里主要是因为当时 PC Server 是物理机，CPU 16/32 core，内存 32/64G 不等，为了更充分的利用资源，一台物理机上都部署了多个应用服务实例，而考虑到 Nginx 工作在 7 层的开销远高于 LVS/DR 模式，所以一般在一个 Nginx 后面挂的实例数也不会超过 10 个。

但随着业务发展和用户流量上升，机器规模也在不断扩张，导致一个网段内的 IP 都不够用了，这套负载结构又遇到了横向扩展的瓶颈，因为 LVS/DR 模式下跨不了网段。所以后来又在 LVS 和 Nginx 之间加了一层 HAProxy，负载结构就变成了下面这样。

LB 负载均衡的层次结构

其实加了 HAProxy 之后，它也是工作在 7 层，这样 Nginx 这层看起来就不是很有必要。但三层的负载结构能支撑更大规模的集群，而原本在 Nginx 层做了一套方便研发切流量上线的运维管理系统，所以牺牲一点性能换取现在的可维护性和将来扩展性，Nginx 这层就一直保留下来了。而且 Nginx 相比 HAProxy 不是纯粹的负载均衡器，它还能提供 cache 功能，对于某些 HTTP 请求实际只走到 Nginx 这层就可以通过缓存命中而返回。

DNS负载

随着业务发展，公司开始了多个 IDC 的建设，考虑到 IDC 级别的容灾，集群开始部署到多个 IDC。跨 IDC 的负载均衡方案可以简单通过 DNS 轮询来实现，但可控性不好。所以我们没有采用这种，而是采用一主加多子域名的方式来基于业务场景实现动态域名调度和负载。主域名下实际是一个动态流量调度器，跨多个 IDC 部署，对于 HTTP 请求基于重定向方式跳子域名，对于 TCP 方式每次建立长连接前请求分配实际连接的子域名，如下图所示。

LB 负载均衡的层次结构

CDN负载

最后再加上互联网应用必不可少的 CDN 将静态资源请求的负载分流，那么整个负载的层次结构就完整了。

LB 负载均衡的层次结构

SSL 带来的负载结构变化

随着互联网的普及，安全问题益发严重，原本早期只有银行网银等使用 HTTPS 方式访问，现在电商类网站也开始启用全站 HTTPS 了。引入 SSL 后对负载结构带来了什么影响么？SSL 属于应用层的协议，所以只能在 7 层上来做，而 HAProxy 也是支持 SSL 协议的，所以一种方式是只需简单的让 HAProxy 开启 SSL 支持完成对内解密对外加密的处理。

但 HAProxy 的作者不太赞同这种方案，因为引入 SSL 处理是有额外的性能开销的。那么在承担确定流量的情况下，假设原本需要 M 台 HAProxy，在开启了 SSL 后可能需要 M + N 台 HAProxy。随着流量增长，这种方式的横向扩展成本较高（毕竟 SSL 证书按服务器数量来收费的）。他给出的解决方案是再独立一层 SSL 代理缓存层，像下面这样。

LB 负载均衡的层次结构

L4 和 L7 之间独立的 SSL 代理缓存层只负责 SSL 协议的处理，把 HTTPS 转换成 HTTP，并检查本地缓存是否命中。若未命中再转发请求到后端的 L7 层应用负载均衡层。这样的好处是每个层次都可以根据流量来独立伸缩，而且 SSL 层显然可以跨多个应用共享，更节省成本。如果按这个思路来重新调整我们前面的负载均衡结构层次，将会演变成下面这样。

LB 负载均衡的层次结构

其实，这时我觉得应用前面的那层 Nginx 可能就显得多余了点，不是必需的。但如果现实这么演进下来很可能就会有这么一层冗余的东西存在很长一段时间，这就是理想和现实之间的差距吧。

总结

好了，本文到此为止。作为一名后台开发我其实对上面提及的各类开源软件如何配置、调优和管理并不熟悉，这属于运维开发的问题域范畴。但这并不妨碍我去了解我所开发的应用所处的整个环境是怎样的，多了解些你工作领域范围边界外的 What 和 Why，有时也能帮助我们更好的设计和解决自身问题域内的问题，别为自己设限而最终画地为牢。

本来以为负载均衡这个古老的课题已经定型了，在写本文时又看到新闻，在近日举办的第十三届网络系统设计与实现 USENIX 研讨会上，来自 Google 的工程师又分享了其自研的 Maglev 负载均衡器。刚下了论文还没看，回头看了再来写写。