负载均衡的演化史—dns,cdn,nginx, HAProxy在负载均衡中的作用

之前看百度的搞fis的那个工程师，貌似现在在uc了，经常喜欢问这个问题？

从输入url到页面渲染完成，谈谈整个过程发生了什么？

页面渲染，前端工程师可以看看webkit内幕，但是，后台的的网络链路是怎么走的！特别是负载均衡这一块，并不一定非常熟悉！

所谓负载均衡（又称为负载分担），英文名称为Load Balance，其意思就是将负载（工作任务）进行平衡、分摊到多个操作单元上进行执行，从而共同完成工作任务。

通常负载均衡可以分为两个层次：全局负载均衡（Global Server Load Balance, GSLB）和服务器负载均衡（Server Load Balance, SLB）。全局负载均衡是指对分别放置在不同的地理位置的服务器群间作负载均衡。服务器负载均衡是指对本地的服务器群做负载均衡。

5-6年前，刚刚开始做java，那个时候，就是一台pc跑若干台虚拟机，业务规模小用户量还不大，机器数量也少（<10）。所以一开始的负载均衡的结构也是很简单的，类似硬负载只是把硬件换成了免费的开源软件并跑在可用性是有 3 个 9 的廉价 PC Server 上，前面一个 LVS 后面跟着几个应用服务

（  LVS 是 Linux Virtual Server ，Linux 虚拟服务器；是一个虚拟的服务器集群【多台机器 LB IP】。为前淘宝工程师 的啥博士搞出来的，感觉很屌的感觉！）

DR(Direct Routing)模式的网络结构：

具体参考文章： LVS 工作模式以及工作原理

不同的用户，访问LVS服务器，然后分发到单机pc，每台pc上装5-6个tomcat，后来为了方便做按域名的分流和适配切流量上线，中间又加了一层 Nginx。同时单机pc，上面装的都是虚拟机，可以镜像拓展。

这样就变成了两层软负载结构了，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，负载结构就变成了下面这样。

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

DNS负载

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

神奇的解释权机制(SOA)

dns系统本身是一个分布式的网络，它是相对可靠的，起码比你网站本身可靠的多

dns的最终解释是可以受我们自己控制的

DNS负载均衡常见实现方式

常见的GSLB实现方式有三种： DNS轮询、HTTP重定向、IP欺骗（又称三角传输）。这三种实现方式都是在用户通过域名来访问目标服务器时，由GSLB设备进行智能决策，将用户引导到一个最佳的服务IP。

基于DNS的GSLB

用户访问某个网站时，需要首先通过域名解析服务（DNS）获得网站的IP。域名解析通常不是一次性完成的，常常需要查询若干不同的域名服务器才能找到对应的IP。如下图所示，用户首先在本地配置一个本地DNS服务器地址，本地DNS服务器收到DNS请求后若不能解析，会将请求转发给更高一级的DNS服务器直到找到域名对应的IP或确定域名不存在。

Inbound入方向负载均衡

Inbound负载均衡技术是DNS智能解析的一种，外网用户通过域名访问内部服务器时，Local DNS的地址解析请求到达LB设备，LB根据对Local DNS的就近性探测结果响应一个最优的IP地址，外网用户根据这个最优的IP响应进行对内部服务器的访问。

入方向负载均衡

流程简述如下：

(1)外部用户进行资源访问前先进行DNS解析，向其本地DNS服务器发送DNS请求。

(2)本地DNS服务器将DNS请求的源IP地址替换为自己的IP地址，并转发给域名对应的权威服务器——LB device。

(3)LB device根据DNS请求的域名和配置的Inbound链路负载均衡规则进行域名解析。

(4)LB device按照域名解析的结果，将DNS应答发送给本地DNS服务器。

(5)本地DNS服务器将解析结果转发给用户。

(6)用户使用解析结果选择的链路，直接对LB device进行资源访问。

对于加入了GSLB的情况，一个GSLB设备（可能是一个4层交换机）会最终代替DNS服务器完成域名解析。下图展示两种流程的不同。

这种方案的优点是：实现简单、实施容易、成本低。其缺点是：当GSLB设备采用“用户就近访问”的原则作为选择最优服务器的策略时，会存在判断不准的现象。原因是在这种策略下，GSLB设备是根据用户IP地址和内容服务器IP地址比较来判断其就近性的，但由于DNS响应是通过本地DNS服务器到达用户的，GSLB设备实际上只能得到用户的本地DNS服务器地址，若用户指定的DNS服务器IP不能正确代表用户的实际位置，就会出现判断不准的现象。

基于HTTP重定向的GSLB

为了解决基于DNS实现方式判断不准的问题，又出现了基于HTTP重定向的GSLB。这种方案中GSLB使用HTTP重定向技术，将用户访问重定向到最合适的服务器上。

       使用基于HTTP重定向方案，首先在DNS中将GSLB设备的IP地址登记为域名的A记录（既域名对应的IP）。如上图所示，用户首先通过DNS得到GSLB设备的IP地址，此时用户以为这就是站点服务器的IP，并向其发送HTTP请求。GSLB设备收到HTTP请求后使用一定策略选择一个最合适的服务器，然后GSLB设备向用户发送一个HTTP重定向指令（HTTP302），并附上选出的服务器的IP地址。最后，用户根据重定向IP访问站点的服务器。

       这一方案的优点是：由于直接向用户发送HTTP重定向指令，可以得到用户的真实IP，从而解决了判断不准确的问题。其缺点是只能为HTTP访问重定向。

基于IP欺骗的GSLB

HTTP重定向方案解决了判断不准确的问题，但只能针对HTTP协议应用使用。对于HTTP协议以外的访问，就需要使用基于IP欺骗（又称三角传输）的GSLB。

 基于IP欺骗的方案同样需要首先将GSLB设备的IP地址在DNS中登记为域名的A记录，这样用户对该域名的请求包都会先发送到GSLB设备。如上图所示，GSLB设备首次收到服务请求包后，会选择一个最合适的服务器，并将服务请求包发送到该服务器。服务器在向用户发送响应包时，将其源IP地址字段改为GSLB设备的IP，发送给用户。

这样，整个过程对用户来说，感觉到的只是GSLB设备在为其提供服务，并不知道其中经历这样一个三角传输的过程。而且这种方案可以对所有类型的访问如HTTP、FTP等进行重定向，但其速度和效率相对比前两种方案要差一点，因为用户所有的访问请求都通过三个点才能响应，经历了更多的路径和处理，所以其主要作为HTTP重定向方案的补充方案在同一GSLB设备中实现。

使用GSLB设备可以为用户选择最合适的服务器群，但受Web服务器的负荷和传输距离等因素的影响，响应速度依然经常不能满足用户的需求。这一问题的解决方案就是在传输网络上利用缓存技术使得Web服务数据流能够就近访问。内容分发网络（CDN）正是这种思想的一个实现，CDN使用GSLB设备将用户引导到最合适的缓存节点（距离近，负载低），使得用户在访问静态内容时获得更好的体验。

CDN负载

内容分发网络（Content Delivery Network, CDN）其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决Internet网络拥塞状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。

CDN组成

一个CDN网络主要由以下几部分组成：内容缓存设备、内容分发管理设备、本地负载均衡交换机、GSLB设备和CDN管理系统，其网络结构如下图所示：

其中，内容缓存设备Cache用于缓存内容实体和对缓存内容进行组织和管理。当有用户访问该客户内容时，直接由各缓存服务器响应用户的请求。

内容分发管理设备主要负责核心Web服务器内容到CDN网络内缓存设备的内容推送、删除、校验以及内容的管理、同步。

GSLB设备则实现CDN全网各缓存节点之间的资源负载均衡，它与各节点的SLB设备保持通信，搜集各节点缓存设备的健康状态、性能、负载等，自动将用户指引到位于其地理区域中的服务器或者引导用户离开拥挤的网络和服务器。还可以通过使用多站点的内容和服务来提高容错性和可用性，防止因本地网或区域网络中断、断电或自然灾害而导致的故障。

CDN管理系统实现对全网设备的管理，对系统的配置。它不仅能对系统中的各个设备进行实时监控，对各种故障产生相应的告警，还能实时观测到系统中总的流量以及各节点的流量，并保存在系统的数据库中，作为统计分析的基础数据，并对日志文件进行管理、报告，作为计费的基础数据。

CDN工作流程

CDN网络结合了GSLB与缓存技术，其工作流程如下图所示：

用户访问某个站点的内容时，若该站点使用了CDN网络，则在用户会在域名解析时获得CDN网络GSLB设备的IP地址。GSLB设备根据其预设的选择策略（如，地理区域、用户时间等）为用户选择最合适的内容缓存节点，并且使用某种方式（如，基于DNS、基于HTTP重定向、基于IP欺骗的方式等）导引用户访问所选的内容缓存节点。

用户继续向缓存节点发出请求，若缓存中包含请求的内容，则直接返回给用户，否则从核心Web服务器中获取该内容，缓存后返回给用户。这样当用户再次访问相同内容或其他用户访问相同内容时，可以直接从缓存中读取，提高了效率。

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 可能就显得多余了点，不是必需的。但如果现实这么演进下来很可能就会有这么一层冗余的东西存在很长一段时间，这就是理想和现实之间的差距吧。

本文基本是网络摘抄而来，和大学写论文一个鸟样，但是，觉得写的，把负载均衡的链路，解构，基本理顺了吧。

参考文章：

http://blog.csdn.net/mindfloating/article/details/51020767

http://blog.jobbole.com/86066/

http://www.cnblogs.com/CasonChan/p/4837227.html

转载本站文章《负载均衡的演化史—dns,cdn,nginx, HAProxy在负载均衡中的作用》,
请注明出处：https://www.zhoulujun.cn/html/theory/ComputerScienceTechnology/network/2016_1226_7927.html