负载均衡的一点整理

Posted by cwen 2016-11-25
 负载均衡  运维  HaProxy  LVS  Nignx

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

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

解决的问题

  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负载均衡软件