负载均衡原理

简单理解HTTP，TCP，网关，LVS 等一系列相关的概念及工作机制。
比方说张三想去创业，由于前期没有什么流量，就只需要一台服务器，让客户端将请求直接打到这台 server 上。

这样部署一开始也没啥问题，因为业务量不是很大，单机足以扛住，但后来张三的业务踩中了风口，业务迅猛发展，于是单机的性能逐渐遇到了瓶颈，而且由于只部署了一台机器，这台机器挂掉了业务也就跌零了，这可不行，所以为了避免单机性能瓶颈与解决单点故障的隐患，张三决定多部署几台机器（假设为三台），这样可以让 client 随机打向其中的一台机器，这样就算其中一台机器挂了，另外的机器还存活，让 client 打向其它没有宕机的机器即可

现在问题来了，client 到底该打向这三台机器的哪一台呢，如果让 client 来选择肯定不合适，因为如果让 client 来选择具体的 server，那么它必须知道有哪几台 server，然后再用轮询等方式随机连接其中一台机器，但如果其中某台 server 宕机了，client 是无法提前感知到的，那么很可能 client 会连接到这台挂掉的 server 上，所以选择哪台机器来连接的工作最好放在 server 中，具体怎么做呢，在架构设计中有个经典的共识：没有什么是加一层解决不了的，如果有那就再加一层，所以我们在 server 端再加一层，将其命名为 LB（Load Balance，负载均衡），由 LB 统一接收 client 的请求，然后再由它来决定具体与哪一个 server 通信，一般业界普遍使用 Nginx 作为 LB

采用这样的架构设计总算支撑了业务的快速增长，但随后不久张三发现这样的架构有点问题：所有的流量都能打到 server 上，这显然是有问题的，不太安全，那能不能在流量打到 server 前再做一层鉴权操作呢，鉴权通过了我们才让它打到 server 上，我们把这一层叫做网关（为了避免单点故障，网关也要以集群的形式存在）

这样的话所有的流量在打到 server 前都要经过网关这一层，鉴权通过后才把流量转发到 server 中，否则就向 client 返回报错信息，除了鉴权外，网关还起到风控，协议转换（比如将 HTTP 转换成 Dubbo），流量控制等功能，以最大程度地保证转发给 server 的流量是安全的，可控的。
但是后来发现不管是动态请求，还是静态资源（如 js，css文件）请求都打到 tomcat 了，这样在流量大时会造成 tomcat 承受极大的压力，其实对于静态资源的处理 tomcat 不如 Nginx，tomcat 每次都要从磁盘加载文件比较影响性能，而 Nginx 有 proxy cache 等功能可以极大提升对静态资源的处理能力。

这就是我们所说的动静分离，将静态请求与动态请求分开，这样 tomcat 就可以专注于处理其擅长的动态请求，而静态资源由于利用到了 Nginx 的 proxy cache 等功能，后端的处理能力又上了一个台阶。另外需要注意的是并不是所有的动态请求都需要经过网关，像我们的运营中心后台由于是内部员工使用的，所以它的鉴权与网关的 api 鉴权并不相同，所以我们直接部署了两台运营中心的 server ，直接让 Nginx 将运营中心的请求打到了这两台 server 上，绕过了网关。

当然为了避免单点故障 Nginx 也需要部署至少两台机器，于是我们的架构变成了下面这样，Nginx 部署两台，以主备的形式存在，备 Nginx 会通过 keepalived 机制（发送心跳包） 来及时感知到主 Nginx 的存活，发现宕机自己就顶上充当主 Nginx 的角色

看起来这样的架构确实不错，但要注意的是 Nginx 是七层（即应用 层）负载均衡器 ，这意味着如果它要转发流量首先得和 client 建立一个 TCP 连接，并且转发的时候也要与转发到的上游 server 建立一个 TCP 连接，而我们知道建立 TCP 连接其实是需要耗费内存（TCP Socket，接收/发送缓存区等需要占用内存）的，客户端和上游服务器要发送数据都需要先发送暂存到到 Nginx 再经由另一端的 TCP 连接传给对方。


通过比较可以发现 LVS 只是单纯地转发包，不需要和上下游建立连接即可转发包，相比于 Nginx 它的抗负载能力强、性能高，能达到 F5 硬件的 60%；对内存和cpu资源消耗比较低
负载均衡设备在接收到第一个来自客户端的SYN 请求时，即通过负载均衡算法选择一个最佳的服务器，并对报文中目标IP地址进行修改(改为后端服务器 IP ），直接转发给该服务器。TCP 的连接建立，即三次握手是客户端和服务器直接建立的，负载均衡设备只是起到一个类似路由器的转发动作。在某些部署情况下，为保证服务器回包可以正确返回给负载均衡设备，在转发报文的同时可能还会对报文原来的源地址进行修改。综上所述，我们在 Nginx 上再加了一层 LVS，以让它来承接我们的所有流量，当然为了保证 LVS 的可用性，我们也采用主备的方式部署 LVS，另外采用这种架构如果 Nginx 容量不够我们可以很方便地进行水平扩容，于是我们的架构改进如下：

当然只有一台 LVS 的话在流量很大的情况下也是找不住的，怎么办，多加几台啊，使用 DNS 负载均衡在解析域名的时候随机打到其中一台不就行了

通过这样的方式终于可以让流量稳定流转了
架构一定要结合业务的实际情况来设计，脱离业务谈架构其实是耍流氓，可以看到上文每一个架构的衍化都与我们的业务发展息息相关，对于中小型流量没有那么大的公司，其实用 Nginx 作为负载均衡足够，在流量迅猛增长后则考虑使用 lvs+nginx，当然像百度这样的巨量流量（数十 Gbps的流量、上千万的并发连接），lvs 也不管用了（实测虽然使用了 lvs 但依然出现了不少丢包的现象）所以它们开发出了自己的一套四层负载均衡器 BGW