负载均衡的一点整理

Posted by cwen 2016-11-25

刚接到一个调研各云厂商的负载均衡情况的小任务,可是小菜鸟对与负载均衡也是一知半解,就先花点时间冲冲电…

从单机网站到分布式网站,很重要的区别就是业务拆分以及分布式部署,但是每个部署的独立业务还存在单点的问题和访问统一入口问题,为解决单点故障,我们可以采取冗余的方式。将相同的应用部署到多台机器上。解决访问统一入口问题,我们可以在集群前面增加负载均衡设备,实现流量分发。

解决的问题

  1. 解决并发压力,提高应用处理性能(增加吞吐量,加强网络处理能力);

  2. 提供故障转移,实现高可用;

  3. 通过添加或减少服务器数量,提供网站伸缩性(扩展性);

  4. 安全防护;(负载均衡设备上做一些过滤,黑白名单等处理)

原理 : 其实就是根据一些转发算法,讲请求分发到不同的节点上去执行

负载均衡原理

DNS

通过使用域名解析实现负载均衡,配置多个A 记录,这些A记录对应的服务器构成集群。大型网站总是部分使用DNS解析,作为第一级负载均衡。 显而易见,使用这种方式的负载均衡的控制权更在域名商那里,不易拓展,并且用这种方式的负载不能很好的分流,有可能造成所有的请求都集中到一个节点上,但是作为第一层的负载均衡的确是个好办法。    

HTTP

当http代理(比如浏览器)向web服务器请求某个URL后,web服务器可以通过http响应头信息中的Location标记来返回一个新的URL。这意味着HTTP代理需要继续请求这个新的URL,完成自动跳转。

IP

在网络层通过修改请求目标地址进行负载均衡。 用户请求数据包,到达负载均衡服务器后,负载均衡服务器在操作系统内核进程获取网络数据包,根据负载均衡算法得到一台真实服务器地址,然后将请求目的地址修改为,获得的真实ip地址,不需要经过用户进程处理。 真实服务器处理完成后,响应数据包回到负载均衡服务器,负载均衡服务器,再将数据包源地址修改为自身的ip地址,发送给用户浏览器。

示意图

链路层

在通信协议的数据链路层修改mac地址,进行负载均衡。 数据分发时,不修改ip地址,指修改目标mac地址,配置真实物理服务器集群所有机器虚拟ip和负载均衡服务器ip地址一致,达到不修改数据包的源地址和目标地址,进行数据分发的目的。 实际处理服务器ip和数据请求目的ip一致,不需要经过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。也称为直接路由模式(DR模式)。

混合  

其实这就显而易见了,当单一的负载均衡方式无法很好的解决现有的问题,那么我们就可以把他们结合在一起使用,这也很符合当下的发展潮流啊… 具体的结合方式有很多,例如 我们可以考虑分层,在每一层采用不同的方式来进行负载均衡,在最外层使用 DNS负载均衡,在使用反向代理来做缓存以及动态请求分发 ,最后在是应用负载均衡(IP/DR), 分流到对应的应用集群  

混合一

混合二

具体实现   

四层  

  • LVS (Linux Virtual Server) 基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/UDP请求均衡地转移到不同的 服务器,从而将一组服务器构成一个高性能、高可用的虚拟服务器。

    1. 抗负载能力强,因为lvs工作方式的逻辑是非常之简单,而且工作在网络4层仅做请求分发之用,没有流量,所以在效率上基本不需要太过考虑。
    2. 配置性低,这通常是一大劣势,但同时也是一大优势,因为没有太多可配置的选项,所以除了增减服务器,并不需要经常去触碰它,大大减少了人为出错的几率。
    3. 工作稳定,因为其本身抗负载能力很强,所以稳定性高也是顺理成章,另外各种lvs都有完整的双机热备方案,所以一点不用担心均衡器本身会出什么问题,节点出现故障的话,lvs会自动判别,所以系统整体是非常稳定的。
    4. 无流量,上面已经有所提及了。lvs仅仅分发请求,而流量并不从它本身出去,所以可以利用它这点来做一些线路分流之用。没有流量同时也保住了均衡器的IO性能不会受到大流量的影响。
    5. 基本上能支持所有应用,因为lvs工作在4层,所以它可以对几乎所有应用做负载均衡,包括http、数据库、聊天室等等.

日PV小于1000万,的时候不需要考虑 LVS , 大多时候LVS + Keepalived配合使用(阿里云),LVS提 供负载均衡,keepalived提供健康检查,故障转移,提高系统的可用性!采用这样的架构以后 很容易对现有系统进行扩展,只要在后端添加或者减少realserver,只要更改lvs的 配置文件,并能实现无缝配置变更!。  

七层 

  • HaProxy

    1. HAProxy是工作在网络7层之上。
    2. 能够补充Nginx的一些缺点比如Session的保持,Cookie的引导等工作
    3. 支持url检测后端的服务器出问题的检测会有很好的帮助。
    4. 更多的负载均衡策略比如:动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)已经实现
    5. 单纯从效率上来讲HAProxy更会比Nginx有更出色的负载均衡速度。
    6. HAProxy可以对Mysql进行负载均衡,对后端的DB节点进行检测和负载均衡。
  • Nignx

    1. 工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构;
    2. Nginx对网络的依赖比较小;
    3. Nginx安装和配置比较简单,测试起来比较方便;
    4. 也可以承担高的负载压力且稳定,一般能支撑超过1万次的并发;
    5. Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测;
    6. Nginx对请求的异步处理可以帮助节点服务器减轻负载;
    7. Nginx能支持http和Email,这样就在适用范围上面小很多;
    8. 不支持Session的保持、对Big request header的支持不是很好,另外默认的只有Round-robin和IP-hash两种负载均衡算法。
  • F5 … 牛逼的物理负载均衡设备  土豪配备,性能那是必须的  

选择  

第一阶段:利用Nginx或者HAProxy进行单点的负载均衡,这一阶段服务器规模刚脱离开单服务器、单数据库的模式,需要一定的负载均衡,但是 仍然规模较小没有专业的维护团队来进行维护,也没有需要进行大规模的网站部署。这样利用Nginx或者HAproxy就是第一选择,此时这些东西上手快, 配置容易,在七层之上利用HTTP协议就可以。这时是第一选择

第二阶段:随着网络服务进一步扩大,这时单点的Nginx已经不能满足,这时使用LVS或者商用F5就是首要选择,Nginx此时就作为LVS或者 F5的节点来使用,具体LVS或者F5的是选择是根据公司规模,人才以及资金能力来选择的,这里也不做详谈,但是一般来说这阶段相关人才跟不上业务的提升,所以购买商业负载均衡已经成为了必经之路。

第三阶段:这时网络服务已经成为主流产品,此时随着公司知名度也进一步扩展,相关人才的能力以及数量也随之提升,这时无论从开发适合自身产品的定制,以及降低成本来讲开源的LVS,已经成为首选,这时LVS会成为主流。 最终形成比较理想的状态为:F5/LVS<—>Haproxy<—>Squid/Varnish<—>AppServer。

LVS/HaProxy/Nignx 的相关介绍摘自网上, 感谢作者,其实网上的介绍都是这样, 我也不知道谁是第一作者了,所以此处就不标注出处了, 望作者原谅

负载均衡算法  

  • 随机

请求随机分配到各个服务器。

  • 轮询

将所有请求,依次分发到每台服务器上,适合服务器硬件同相同的场景。

  • 最少连接

优先将请求发给拥有最少连接数的后端服务器,常用于长连接服务,例如数据库连接等服务。

  • 源地址

将请求的源地址进行hash运算,并结合后端的服务器的权重派发请求至某匹配的服务器,这可以使得同一个客户端IP的请求始终被派发至某特定的服务器。该方式适合负载均衡无cookie功能的TCP协议。

  • 加权  

在轮询,随机,最少链接,Hash’等算法的基础上,通过加权的方式,进行负载服务器分配。  

又到凌晨一点,说好今天早睡的…   

参考 

  1. Wikipedia)
  2. 大型网站架构系列:负载均衡详解
  3. Nginx/LVS/HAProxy负载均衡软件