引入
Nginx
Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件（IMAP/POP3）代理服务器。 Nginx 主要提供反向代理、负载均衡、动静分离(静态资源服务，即静态web server)等服务。
反向代理部分，以以前的例子来说，比如国内访问香港快，香港访问github快，但国内访问github慢，那我用一个香港服务器做nginx反代github，就能加速国内访问github了
反向代理需要设置在配置文件的HTTP模块中
Nginx作为负载均衡使用的话就是一种常用的SLB软件。具体见后面“SLB：Nginx”一节
参考阅读：Nginx
正向代理和反向代理
正向代理：Proxy代理客户端去访问服务器
反向代理：客户端访问Proxy，该Proxy代理了服务端
反代是负载均衡的一种实现手段（的一个步骤）
使用负载均衡的网络架构举例
- 反向代理层的负载均衡，是通过“DNS轮询”实现的
- 站点层的负载均衡，是通过“nginx”实现的
- 服务层的负载均衡，是通过“服务连接池”实现的
- 数据层的负载均衡，要考虑“数据的均衡”与“请求的均衡”两个点，常见的方式有“按照范围水平切分”与“hash水平切分”
四层和七层负载均衡
由前面的例子可以看到，负载均衡实际上是可以实现在网络结构的每一个层次的，其核心目的就是平衡负载，前面所说的层次是指在网络请求架构上的层次，而这里的“四层”，“七层”SLB指的是SLB实现在在OSI七层模型的第几个层次。这两者是不冲突的，勿混淆。
那么根据OSI七层网络模型，1物理层、2数据链路层、3网络层、4传输层、5会话层、6表示层、7应用层。
四层SLB工作在OSI第四层，也就是传输层；七层SLB工作在最高层，也就是应用层。
区别如图：
四层负载均衡：使用IP加端口的方式进行路由转发，也就是说客户端并没有和proxy建立TCP连接，而是客户端直接和后端服务器建立TCP连接（客户端先向负载均衡发送SYN请求建立第一次连接，然后再通过SLB算法，让客户端去与目标后端服务器进行三次握手连接）；
七层负载均衡：一般是基于请求URL地址的方式进行代理转发，七层服务均衡在应用层选择服务器，只能先与负载均衡设备进行TCP连接，然后负载均衡设备再与后端服务器建立另外一条TCP连接通道。
四层和七层负载均衡实现方式整体原理（重要）：四层负载均衡和七层负载均衡区别在哪里？
常用负载均衡软件：四层和七层负载均衡的特点及常用负载均衡Nginx、Haproxy、LVS对比
（四层: F5、LVS等，七层: nginx、apache等）
显然七层SLB更损失性能；四层SLB可能会遭受SYN Flood攻击（一种DDoS攻击），可能将垃圾流量转发给后台服务器，而七层显然可以在SLB服务器上设置过滤
（SYN Flood：利用TCP协议缺陷，发送大量伪造的TCP连接请求，从而使得被攻击方资源耗尽，更细节原理参考：详解SYN Flood攻击原理与防范 待阅读）
负载均衡
四层负载均衡可通过LVS（Linux Virtual Server）+ keepalived的方式实现，七层负载均衡通过Tengine（淘宝网发起的Web服务器项目，在Nginx的基础上，针对有大访问量的网站需求进行了优化）实现。
来自公网的请求通过等价多路径路由（ECMP）到达LVS集群，LVS集群内的每台LVS通过组播报文将会话同步到该集群内的其它LVS机器上，从而实现LVS集群内各台机器间的会话同步。同时，LVS集群会对Tengine集群进行健康检查，将异常机器从Tengine集群移除，保证七层负载均衡的可用性。
产品架构：阿里云负载均衡产品架构
集群综述
集群根据功能分为两大类：高可用集群（HA）和负载均衡集群（SLB）
高可用集群主要是防止服务器宕机导致服务不可用，主要功能是服务器状态检测和故障隔离（热备）
负载均衡集群则是平衡负载功能，请求分发给后端服务器处理
HA：VIP、VRRP
虚拟IP，方便切换实际主机而保持IP不变，目的是高可用性HA，虚拟IP(VIP)
持有VIP的是集群中的一台主机，只是对于外界来说，整个集群好像一台IP为VIP的主机
其需要使用VRRP协议
VRRP (Virtual Router Redundancy Protocol-虚拟路由冗余协议)：双机热备份-VRRP
VRRP可以通过把多台设备虚拟化成一台设备，然后通过配置虚拟IP地址(VIP)作为网关就能实现对网关的备份（这虚拟IP地址是代表整个VRRP组内的所有设备），当其中一台设备出现故障之后，VRRP组内其他设备会通过某些机制来接替故障设备的工作。
VIP地址与VRRP组中的某台VRRP设备实际IP地址相同，则此设备为IP地址拥有者（如在keepalived中我们最开始会手动设置一个master，后面再通过各种检查和选举机制决定新master）只有IP地址拥有者（master）才真正拥有这个VIP，显示在网卡信息中，其它backup是没有的
master会通过组播的形式向各个backup发送VRRP协议的数据包，当backup收不到master发来的VRRP数据包时，就会认为master宕机了。此时就需要根据各个backup的优先级来决定谁成为新的mater。
HA：keepalived
keepalived是一个实现服务器HA的软件
keepalived通过VRRP实现HA：基于VIP的keepalived高可用集群架构
Keepalived主要有三个模块，分别是core、check和vrrp。
①core模块：为keepalived的核心，负责主进程的启动、维护以及全局配置文件的加载和解析
②check模块：负责健康检查
③vrrp模块：是来实现VRRP协议的。
keepalived可以集成LVS配置，这样就不必单独配置LVS（见后面“keepalived+LVS集群”部分）
SLB：LVS
LVS：Linux Virtual Server
LVS 是一个实现负载均衡集群的开源软件
LVS工作模式分为NAT模式、TUN模式、以及DR模式（见下面链接）
NAT模式就是运用NAT的原理，直接改IP头，这样的话数据往返都要经过ds。
DR模式：为了实现每台rs在向外发送响应报文的时候，可以把VIP作为源地址，因此我们设置ds和rs集群的所有主机都是同样的VIP，这样数据返回的时候就可以直接返回给请求端了。但需要在rs上禁用ARP解析，让所有的rs上的VIP地址不响应VIP的arp广播请求（否则vip一样，所有rs同时响应，谁响应快调度谁，不符合slb目的，这样一来只有ds会响应MAC地址请求，那么请求报文就一定发给ds了，再由ds根据调度算法指定目的rs的MAC地址，传给它，rs拿到清请求包后，将请求数据结果返回SIP（sourceIP）即可。
DR模式是最常用的，因为一般返回的数据比较庞大，返回流量不经过SLB可以大大减小负荷
LVS的十大调度算法：LVS十种调度算法介绍
使用LVS架设的服务器集群有三个部分组成：
负载均衡层(Load Balancer)：包含负载调度器（Director），简写“ds”
服务器集群层(Server Array)：包含后端的服务器，真实服务器（Real Server）集群，是客户端真实访问的服务器，简写“rs”
数据共享存储层(Shared Storage)：提供给后端服务器进行数据访问
LVS已经是Linux标准内核的一部分，只需要再安装一个lvs的管理工具：ipvsadm即可（ IPVS为LVS的核心模块）
Lvs之NAT、DR、TUN三种模式的应用配置案例以及底层原理（整理版本：LVS安装使用详解）
SLB：Nginx
Nginx功能有反向代理、七层负载均衡，也可以作为静态web服务器，邮件服务器。默认使用端口80。其它功能见“引入”一节。
Nginx的这些功能都是工作在第七层的，都是通过HTTP/HTTPS实现的，所以我们在写反代、负载均衡等的配置的时候自然要写在HTTP模块里。在HTTP子模块中主要有server和upstream子模块，server中需要配置location路由信息模块。
反向代理：在配置反向代理的时候，我们在http模块中定义server子模块，这个子模块配置虚拟主机，该服务器接受到端口80的所有流量（所有到达本Nginx服务器的HTTP请求）都发往该虚拟主机，也就完成了反代。
负载均衡：如果有定义upstream子模块，server虚拟主机子模块将所有流量转发上游upstream子模块中的服务器，在upstream中可以设置多台rs后端服务器，可以选用负载均衡策略，也就实现了负载均衡功能。默认轮询调度upstream中的backend rs。（注意，upstream名称和server配置中的proxy_pass需要匹配才能转发到upstream。）
Nginx的负载均衡功能支持3种负载均衡策略，2种常用的第三方策略
以下为Nginx通用配置结构
main # 全局配置
events {
# nginx工作模式配置
}
http { # http设置
....
server { # 服务器主机配置（虚拟主机）
....
location { # 路由配置
....
}
location path {
....
}
location otherpath {
....
}
}
server {
....
location {
....
}
}
upstream name { # 负载均衡配置
....
}
}注意：所有rs都要禁用arp解析（写个jio本），原因和lvs集群须禁用rs的arp解析一样
SLB：Tengine
淘宝网发起的Nginx的升级版，就是针对淘宝网的需求优化了一下
keepalived+LVS集群：实现高可用负载均衡
【整体网络架构：keepalived管理LVS集群，LVS管理后端服务器集群】
（LVS集群中由keepalived指定的就是本次工作的ds）
为什么要两者结合？因为LVS做负载均衡，来达到分发请求的目的，但是不能很好的避免单点故障，假如LVS服务器挂点了，那么所有的服务也会跟着瘫痪 。keepalived+LVS，就能很好的解决这一问题
keepAlived用于保证SLB集群（LVS）的高可用性，是指的SLB本身的高可用。对于在keepalived中配置lvs模块，起目的是补充lvs的配置，keepalived属于lvs的扩展项目
实践例子：
②keepAlived+lvs→效率最高的负载均衡【重要：KeepAlived集成LVS】
③keepalived + nginx 实现高可用集群方案（这里Nginx只是安装好后直接启动，没有任何配置，其实和①差不多）
keepalived可以集成LVS配置，在①的配置文件中，若多写个virtual_server项，即可在keepalived中配置本机的VIP等信息的时候同时将本机配置为LVS服务器，virtual_server中的real_server项配置即为本机LVS负责调度的真实的后端服务器集群，keepalived的负载均衡框架实际上就是使用的LVS，keepalived直接使用了IPVS，即LVS的核心组件，实现了负载均衡功能。
这样一来，keepalived就接管了虚拟ip完成了虚拟ip的高可用（主从热备功能），同时keepalived也监测了两台Real Server（负载均衡功能）
也可以不在KeepAlived中配置LVS，单独手动配置LVS，见前面“LVS-Lvs之NAT、DR、TUN三种模式的应用配置案例以及底层原理”一部分，但这样显然更麻烦；对于集群不是LVS集群，如是普通主机集群or Nginx集群，就只能各个服务自己配置自己的了，keepalived只负责主从热备。
[KeepAlived+LVS大概步骤总结]：
先给每台LVS配置同一个VIP（增加一个本地路由lo0，设置其IP为想要的VIP，注意VIP必须和实际IP在同一个网段）linux配置虚拟IP—VIP
安装ipvsadm
集群中每台主机都安装keepalived，写keepalived配置：配置VIP和真实服务IP，配置LVS（配置virtual_server和对应的real_server）
如果是LVS工作在DR模式，需要在每台rs上抑制arp响应
那么网络结构就是：请求端——keepalived+lvs集群（ds）+后端服务器集群（rs）
keepalived+LVS集群+Nginx集群：实现四层、七层高可用负载均衡
LVS+KeepAlived+Nginx高可用实现方案【这篇写得很详细，推荐】
网络结构：请求端——keepalived+lvs集群（ds）——Nginx集群（ds/rs）——后端服务器集群（rs）
Ningx集群对于lvs集群来说是rs，对于后端服务器集群来说是ds（配置也就按这样ds-rs关系配置）
LVS作为四层和七层SLB的入口。对于四层，由LVS集群转发给rs；对于七层，LVS集群将请求转发给Tengine集群，再由Tengine集群转发给rs；由于lvs的消耗很低，所以这种结构是合理的，即能满足四层SLB的速度，又能满足七层SLB的多功能。
在使用VIP下，如果lvs集群、nginx集群、rs集群对外的vip都是一样的，所以为了让请求到达云的时候，只让lvs的ds响应，我们要抑制nginx集群和rs集群的arp响应：LVS负载均衡中arp_ignore和arp_annonuce参数配置的含义（对于keepalived+lvs集群本身，keepalived会根据VRRP协议，只让master（也就是VIP目前指向的真实MAC地址机器）作出响应，所以无需再手动抑制lvs集群的arp响应）
高性能负载均衡设计与实现 - 阿里云云栖号的文章 - 知乎 https://zhuanlan.zhihu.com/p/29949340
高可用架构可能出现的问题
脑裂：主备集群中两个节点互相认为对方已挂掉，都成为了master，然后开始争抢共享资源，结果会导致系统混乱，数据损坏。
在keepalived+LVS集群+Nginx集群网络结构中，只有keepalived+LVS集群这一层可能出现脑裂（keepalived导致），即keepalived的master主机使用vrrp对keepalived+lvs集群进行心跳检查（vrrp报文）的时候出现故障，以为对方挂了，在vrrp协议中，backup如果收不到来自master的心跳包，就认为master down了，自动转为master，那集群就出现两个master了，它们都持有VIP，那么他俩都能接收到SIP（source IP）发出的请求，开始争抢资源，系统混乱，也就是脑裂。
可能原因：VRRP中的心跳检查出故障了
待更新更多可能问题…
Key Server
如果相应的负载均衡实例服务端口使用的是七层HTTPS协议，与上述HTTP处理过程类似（keepalived+LVS集群+Tengine集群），差别是在按策略将服务请求最终分发到后端ECS服务器（rs）前，先调用Key Server进行证书验证及数据包加解密等前置操作。
这一步是由Tengine集群向Key Server发送请求进行验证，而不是后端服务器rs
