【负载均衡】
大量用户发起请求的情况下，服务器负载过高，导致部分请求无法被响应或者及时响应。
负载均衡根据一定的算法将请求分发到不同的后端，保证所有的请求都可以被正常的下发并返回。
【主流实现-LVS】
LVS 是 Linux Virtual Server 的简称，也就是 Linux 虚拟服务器，已经是 Linux 标准内核的一部分。
采用IP负载均衡技术和基于内容请求分发。
调度器具有很好的吞吐率，将请求均衡得转移到不同的服务器上执行，且调度器可以自动屏蔽掉故障的服务器，从而将一组服务器构成一个高可用，高性能的服务器集群。
*负载均衡机制
1. LVS是四层负载均衡，也就是说在传输层上，LVS支持TCP/UDP。由于是四层负载均衡，所以相对于其他的高层负载均衡而言，对于DNS域名轮流解析，应用层负载的调度，客户端的调度等，它的效率是相对较高的。
2. 四层负载均衡，主要通过报文的目标地址和端口。（七层负载均衡又称为"内容交换"，主要是通过报文中真正有意义的应用层内容）
3. LVS的转发主要通过修改IP地址（NAT模式，包括SNAT和DNAT），修改目标MAC（DR模式）来实现。
*负载均衡模式-NAT模式
NAT（Network Address Translation）是一种外网和内网地址映射的技术。
NAT模式下，网络数据包的进出都要经过LVS的处理。LVS需要作为RS（真实服务器）的网关。
当包从Client到达LVS时，LVS做DNAT（目标地址转换），将D-IP（目的地址）改变为RS的IP。
RS处理完成，将包返回的时候，S-IP（源地址）是RS，D-IP是Client的IP。
到达LVS做网关中转时，LVS会做SNAT（源地址转换），将包的S-IP改为VIP。
*负载均衡模式-DR模式
DR（直接路由）模式下需要LVS和RS绑定同一个集群（RS通过将VIP绑定在loopback实现）。
请求由LVS接受，返回的时候由RS直接返回给Client。
当包到LVS的时候，LVS将网络帧的MAC地址修改为某台RS的MAC，此包会被转发到对应的RS上面进行处理。
此时S-IP和D-IP都没有发生改变。
RS收到LVS转发的包时，链路层发现MAC地址是自己的，网络层发现IP地址也是自己的，于是包被合法接受，RS不感知LVS。
当包返回时，RS直接返回给Client，不再经过LVS。
由于RS响应的数据包是直接返回给Client的，所以有效得避免了负载均衡服务器的带宽成为瓶颈。
*负载均衡模式-IP隧道模式
隧道模式有点类似与VPN，使用网络分层的原理，在从客户端发来的数据包的基础上，封装一个新的IP头标记（不完整，只有目的IP）发送给RS。
RS收到后，先把DR发过来的数据包的头解开，还原数据包。处理完成后，直接返回给Client。
*负载均衡模式-总结
综上所述，DR模式具有更好的性能，也是目前大型网站比较通用的一种模式。
*LVS调度算法
限于篇幅，只介绍部分算法。
1. 轮询调度
2. 加权轮询调度
3. 最小连接数调度
4. 加权最小连接数调度
5. 基于局部性的最少连接（LBLC）
该算法主要用于Cache集群系统。
该算法根据请求的D-IP找出该D-IP地址最近使用的服务器地址，如果此服务器可用，则发送给此服务器。如果不可用，则使用最小连接数算法选择一个服务器发送报文。
6. 带复制的基于局部性的最少连接（LCLBR）
它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射，而LBLC算法维护从一个目标IP地址到一台服务器的映射。
在LBLC算法里面，某些热门站点报文较多，可能服务器很快会达到饱和，然后切换到第二台又会很快达到饱和，然后后端服务器就一直在切换，造成资源不必要的浪费。
LCLBR里面，单个服务器变成了一组服务器，就会有效避免这种情况。
7. 目标地址散列
8. 源地址散列
*LVS的优点
1. 抗负载能力强，由于工作在传输层上，只做分发，无流量产生，所以它在所有的负载均衡里面性能是最强的，对内存和CPU的消耗也比较低。
2. 配置性较低，减少人为出错的概率，但是也相应减少了人为自主性。
3. 工作稳定，自身有完整的双机热备方案，如：LVS + Keepalived
4. 无流量，保证IO不会受到影响。
*LVS的缺点
1. 软件本身不支持正则表达式处理，不能做动静分离。
2. 网站应用比较庞大的时候，LVS/DR+Keepalive实施较为复杂。
【主流实现-Nginx】
Nginx是一个很强大的高性能Web和反向代理服务器。
最大的优势在于高负载情况下对内存和CPU的低消耗。
在高并发的情况下，Nginx是Apache服务器不错的替代品。
*传统基于进程或线程的模型
传统基于进程或线程的模型（如Apache）在处理并发时会为每一个连接建立一个单独的进程或线程。这种方法会在网络传输或者I/O操作上阻塞。
对于应用来讲，在内存和CPU的使用上效率都是非常低的。
而且，生成一个单独的进程/线程还需要为其准备新的运行环境（主要包括分配堆栈内存），以及上下文执行环境。
创建这些都消耗额外的CPU时间，这最终也会因为线程上下文来回切换导致性能非常差。
*Nginx架构设计
Nginx的架构设计是采用模块化的，基于事件驱动，异步，单线程且非阻塞。
Nginx大量使用多路复用和事件通知，nginx启动之后，会在系统中以 daemon（守护进程） 的方式在后台运行，包括一个master进程和多个worker进程。
所有的进程都是单线程的，进程间通信主要通过共享内存的方式。
多个连接，是通过worker进程中高效回环（run-loop）机制来处理的。对于每个worker进程来说，每秒钟可以处理上千个请求和连接。
*Nginx负载均衡
Nginx 负载均衡主要针对七层的http和https，当然，四层Nginx后来也支持了（1.9.0版本增加stream模块，用来实现四层协议）。
Nginx主要是通过反向代理的方式进行负载均衡的，所谓反向代理（Reverse Proxy），指的是以代理服务器来接收 Client 请求，然后将请求转发到内部服务器，并将内部服务器处理完成的结果返回给 Client ，对外，代理服务器就是真正的服务器，内部服务器外部不感知。
Nginx支持以下几种策略：
轮询·default
weight （权重）
ip_hash （可用于解决会话保持的问题）
fair·第三方 （按后端服务器的响应时间来分配请求，响应时间短的优先分配）
url_hash·第三方 （相同的url定位到相同的服务器）
*Nginx的优势
1. 跨平台，配置简单
2. 非阻塞，高并发（官方测试可以支撑5万并发数）
3. 事件驱动，通信机制采用 epoll 模型，支持更大的并发连接
4. 内存消耗小。（3万并发数下，10个Nginx进程只需要150M内存）
5. 内置的健康检查功能。 （一台后端服务器宕机了，不会影响前端访问）
6. 节省带宽。 （支持GZIP压缩，可以添加浏览器缓存的header）
7. 稳定性高。 （反向代理，宕机的概率很小）
*Nginx的缺点
1. 对后端服务器的健康检查，只支持通过端口检测，不支持url检测。
2. 不支持Session的直接保持。（通过ip_hash可解决）
【主流实现-Haproxy】
Haproxy提供高可用性，负载均衡以及基于TCP和HTTP的代理。
特别适用于那些负载特大的Web站点，这些站点通常需要会话保持或七层处理。
Haproxy支持四层和七层两种负载模式。
Haproxy有一些Nginx不具有的优点，比如支持Session的保持，Cookie的引导；同时支持通过获取指定的URL来检测后端服务器的状态。
Haproxy和LVS类似，本身就只是一款负载均衡软件；单纯从效率上来讲，比Nginx有更好的负载均衡速度，在并发处理上也优于Nginx。
Haproxy支持的负载均衡策略也比较多：Round-robin（轮循）、Weight-round-robin（带权轮循）、source（原地址保持）、RI（请求URL）、rdp-cookie（根据cookie）。
【三种负载均衡的比较】
|
比较 |
HAProxy |
Nginx |
LVS |
|
优点 |
支持session保持，Cookie引导。 可通过url检测后端服务器健康状态。 也可做MySQL、Email等负载均衡。 支持通过指定的URL对后端服务器健康检查。 |
http、https、Emai协议功能较好，处理相应请求快。 Web能力强，配置简单，支持缓存功能、适用动静分离，低内存消耗。 支持WebSocket协议。 支持强大的正则匹配规则 。 |
通过vrrp转发（仅分发）效率高，流量通过内核处理，没有流量产生。（理论） 相当稳定可靠。 |
|
缺点 |
一般不做Web服务器的Cache。 |
不支持session直接保持，但可通过ip_hash解决。 只能通过端口对后端服务器健康检查。 |
不支持正则，不能做动静分离，配置略复杂，需要IP略多。 没有后端主机健康状态检查。 |
|
支持算法 |
目标uri hash(uri) url参数 (url_params) 请求头信息调度(hdr(name)) cookie (rdp-cookie) |
最小响应时间 自定义hash内容(hash key [consistent]) url hash 最短时间和最少连接 |
最短期望延迟(Shortest Expected Delay) 不排队(Never Queue) 基于局部性的最少连接(LBLC) 带复制的基于局部性最少链接(LCLBR) |
|
官网 |
|||
|
虚拟主机 |
支持 |
支持 |
不支持 |
|
适用性 |
四层，七层（常用） |
四层，七层（常用） |
四层 |
|
量级 |
七层重量级，四层轻量级 |
七层重量级，四层轻量级 |
四层重量级 |
|
常用热备 |
Keepalived+其它 |
Keepalived+其它 |
Keepalived+其它 |
*补充区别
HAProxy对于后端服务器会一直做健康检测（就算请求没过来的时候也会做健康检查）
后端机器故障发生在请求还没到来的时候，haproxy会将这台故障机切掉，但如果后端机器故障发生在请求到达期间，那么前端访问会有异常。
也就是说HAProxy会把请求转到后端的这台故障机上，并经过多次探测后才会把这台机器切掉，并把请求发给其他正常的后端机，这势必会造成一小段时间内前端访问失败。
Nginx对于后端的服务器不会一直做健康检测
后端机器发生故障，在请求过来的时候，分发还是会正常进行分发，只是请求不到数据的时候，它会再转向好的后端机器进行请求，直到请求正常为止。
也就是说Nginx请求转到后端一台不成功的机器的话，还会再转向另外一台服务器，这对前端访问没有什么影响。
因此，如果有用HAProxy做为前端负载均衡的话 ，如果后端服务器要维护，在高并发的情况，肯定是会影响用户的。
但如果是Nginx做为前端负载均衡的话，只要并发撑得住，后端切掉几台不会影响到用户。
【Openstack LBaaS的现状】
Neutron中的loadbalance服务lbaas，可以将来自公网或内部网络的访问流量，分发到云资源中的云主机上，可以随时添加或者减少后端云主机的数量，而不影响业务。
lbaas在Grizzly版本集成到Neutron中。
现在社区最新的API版本为V2，在Kilo中发布，包含以下概念：
Lbaas V1与V2的区别如下：
|
功能 |
lbaas |
lbaasV2 |
|
最大连接数 |
Y |
Y |
|
TCP负载均衡 |
Y |
Y |
|
HTTP负载均衡 |
Y |
Y |
|
HTTPS负载均衡 |
Y |
Y |
|
TERMINATED_HTTPS负载均衡 |
X |
Y |
|
基于hostname的url转发 |
X |
Y |
|
基于path的url转发 |
X |
Y |
|
基于filename的url转发 |
X |
Y |
|
基于header的url转发 |
X |
Y |
|
基于cookie的url转发 |
X |
Y |
|
一个vip支持多种协议和端口 |
X |
Y |
【Octavia 介绍】
Octavia当前作为lbaasV2的一个driver存在，完全兼容lbaasV2的接口，最终的发展趋势会作为一个独立的项目代替lbaasV2。
架构图如下：
网络结构如下：
【参考】
octavia相关：https://docs.openstack.org/octavia/latest/
nginx相关：nginx.org