作为后端应用的开发者，我们经常开发、调试、测试完我们的应用并发布到生产环境，用户就可以直接访问到我们的应用了。但对于互联网应用，在你的应用和用户之间还隔着一层低调的或厚或薄的负载均衡层软件，它们不显山不露水默默的发挥着重要的作用，以至于我们经常忽略了它们的存在。因为负载均衡层通常不在一般开发人员的问题域内，而且它们一般都是现成且成熟的解决方案，以至于我们习惯性的忽略和认为乏善可陈。其实不然，本文就写写我对负载均衡层次结构的认知和理解。
硬负载
所谓「硬负载」就是采用硬件设备来提供负载均衡。
在七、八年前那时我在做Java的企业软件开发，开发出来的企业级Java应用程序就部署在像Weblogic之类的应用容器中。而这类应用容器软件又跑在Unix的小型机上。把硬件和软件一体打包作为企业应用解决方案卖给客户。这类应用部署的方案十分简单，层级也比较浅。为了保证可靠性，使用两套小型机上各部署一个WeblogicServer，在应用服务前面使用像F5之类的硬件负载均衡器，如下图所示。
由于小型机和前面的F5负载均衡硬件都比较贵，所以出于可靠性、可维护性和成本的综合考虑，一般应用部署两套跑在两台小型机上，在前面共享一个F5做负载均衡。而一般F5和小型机这类硬件设备都至少是5个9的可靠性保障，所以整体的系统可靠性基本有保障。
进入互联网时代后，应用开发拥抱开源，部署使用更廉价的PCServer和免费开源的应用容器。负载均衡也逐步从硬负载向软负载变迁，由于互联网应用的海量特性和部署规模的急剧膨胀，前端负载均衡也开始变得丰富起来。
软负载
进入互联网公司后，我们刚开始开发应用时，业务规模小用户量还不大，机器数量也少（10）。所以一开始的负载均衡的结构也是很简单的，类似硬负载只是把硬件换成了免费的开源软件并跑在可用性是有3个9的廉价PCServer上。
前面一个LVS后面跟着几个应用服务，后来为了方便做按域名的分流和适配切流量上线，中间又加了一层Nginx。
这样就变成了两层软负载结构了，LVS负责4层，Nginx负责7层。但Nginx只负责了单机内多实例的负载均衡，这里主要是因为当时PCServer是物理机，CPU16/32core，内存32/64G不等，为了更充分的利用资源，一台物理机上都部署了多个应用服务实例，而考虑到Nginx工作在7层的开销远高于LVS/DR模式，所以一般在一个Nginx后面挂的实例数也不会超过10个。
但随着业务发展和用户流量上升，机器规模也在不断扩张，导致一个网段内的IP都不够用了，这套负载结构又遇到了横向扩展的瓶颈，因为LVS/DR模式下跨不了网段。所以后来又在LVS和Nginx之间加了一层HAProxy，负载结构就变成了下面这样。
其实加了HAProxy之后，它也是工作在7层，这样Nginx这层看起来就不是很有必要。但三层的负载结构能支撑更大规模的集群，而原本在Nginx层做了一套方便研发切流量上线的运维管理系统，所以牺牲一点性能换取现在的可维护性和将来扩展性，Nginx这层就一直保留下来了。而且Nginx相比HAProxy不是纯粹的负载均衡器，它还能提供cache功能，对于某些HTTP请求实际只走到Nginx这层就可以通过缓存命中而返回。
DNS负载
随着业务发展，公司开始了多个IDC的建设，考虑到IDC级别的容灾，集群开始部署到多个IDC。跨IDC的负载均衡方案可以简单通过DNS轮询来实现，但可控性不好。所以我们没有采用这种，而是采用一主加多子域名的方式来基于业务场景实现动态域名调度和负载。主域名下实际是一个动态流量调度器，跨多个IDC部署，对于HTTP请求基于重定向方式跳子域名，对于TCP方式每次建立长连接前请求分配实际连接的子域名，如下图所示。
CDN负载
最后再加上互联网应用必不可少的CDN将静态资源请求的负载分流，那么整个负载的层次结构就完整了。
SSL带来的负载结构变化
随着互联网的普及，安全问题益发严重，原本早期只有银行网银等使用HTTPS方式访问，现在电商类网站也开始启用全站HTTPS了。引入SSL后对负载结构带来了什么影响么？SSL属于应用层的协议，所以只能在7层上来做，而HAProxy也是支持SSL协议的，所以一种方式是只需简单的让HAProxy开启SSL支持完成对内解密对外加密的处理。
但HAProxy的作者不太赞同这种方案，因为引入SSL处理是有额外的性能开销的。那么在承担确定流量的情况下，假设原本需要M台HAProxy，在开启了SSL后可能需要M+N台HAProxy。随着流量增长，这种方式的横向扩展成本较高（毕竟SSL证书按服务器数量来收费的）。他给出的解决方案是再独立一层SSL代理缓存层，像下面这样。
L4和L7之间独立的SSL代理缓存层只负责SSL协议的处理，把HTTPS转换成HTTP，并检查本地缓存是否命中。若未命中再转发请求到后端的L7层应用负载均衡层。这样的好处是每个层次都可以根据流量来独立伸缩，而且SSL层显然可以跨多个应用共享，更节省成本。如果按这个思路来重新调整我们前面的负载均衡结构层次，将会演变成下面这样。
其实，这时我觉得应用前面的那层Nginx可能就显得多余了点，不是必需的。但如果现实这么演进下来很可能就会有这么一层冗余的东西存在很长一段时间，这就是理想和现实之间的差距吧。
总结
好了，本文到此为止。作为一名后台开发我其实对上面提及的各类开源软件如何配置、调优和管理并不熟悉，这属于运维开发的问题域范畴。但这并不妨碍我去了解我所开发的应用所处的整个环境是怎样的，多了解些你工作领域范围边界外的What和Why，有时也能帮助我们更好的设计和解决自身问题域内的问题，别为自己设限而最终画地为牢。
本来以为负载均衡这个古老的课题已经定型了，在写本文时又看到新闻，在近日举办的第十三届网络系统设计与实现USENIX研讨会上，来自Google的工程师又分享了其自研的Maglev负载均衡器。刚下了论文还没看，回头看了再来写写。
参考
[1]HAProxyDocumentation.[HAProxyManagementGuide](白癜风皮肤健康普查北京治疗白癜风一共要多少钱