12. Interview-Nginx&Tomcat

1 四层负载均衡(转发)

四层&七层负载均衡

主要通过报文中的目标地址和端口，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

• F5
  • 硬件负载均衡器，功能很好，价格昂贵
• LVS
  • 重量级的四层负载均衡器
• Nginx
  • 轻量级的四层负载均衡器，带缓存功能，正则表达式较灵活
• haproxy
  • 模拟四层转发，较灵活

2 七层负载均衡(代理)

所谓七层负载均衡，也称为“内容交换”，也就是主要通过报文中的真正有意义的应用层内容，再加上负载均衡设备设置的服务器选择方式，决定最终选择的内部服务器。

• haproxy
  • 全面支持七层负载均衡器，功能全面
• nginx
  • 只在http协议和mail协议上功能比较好，性能与haproxy差不多
• apache
  • 功能较差
• mysql proxy
  • 功能尚可

3 负载均衡算法

• Round Robin轮询：服务器性能均衡
• Random随机
• 权重轮询：性能好的服务器获得较多请求
• 权重随机
• 最少连接数均衡：当前连接数最少的机器接收用户请求，适合长时间处理的请求服务，如FTP
• 一致性哈希：相同参数的请求总是发到同一服务器，当该节点挂掉时基于虚拟节点，平摊到其他提供者
• IP散列：相同client请求发到同一server处理
• URL散列：发送至相同URL的请求转发至同一服务器
• 响应速度均衡：负载均衡器发送探测请求，响应最快的服务器来接收用户请求，反映了服务器当前状态。
• 处理能力均衡(CPU、内存)：将请求发给处理负荷最轻的服务器，反映了服务器处理能力和当前网络现状。
• DNS响应均衡：最先收到域名解析IP地址来继续请求服务

4 LVS原理

• LVS NAT模式
• LVS DR模式
• LVS TUN模式
• LVS FULLNAT模式

LVS原理

LVS，Linux Virtual Server，Linux虚拟机服务器，现在是Linux标准内核的一部分，是一个虚拟的四层负载均衡器。

• ipvs ： 工作于内核空间，主要用于使用户定义的策略生效
• ipvsadm : 工作于用户空间，主要用于用户定义和管理集群服务的工具

4.1 LVS NAT模式

LVS NAT模式

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP(客户端IP),后面统称为CIP)，目
标地址为VIP(负载均衡器前端地址，后面统称为VIP)。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的目
标地址改为了后端服务器的RIP 地址并将报文根据算法发送出去。
③.报文送到Real Server 后，由于报文的目标地址是自己，所以会响应该请求，并将响应报文返还
给LVS。
④.然后lvs 将此报文的源地址修改为本机并发送给客户端。
注意：在NAT 模式中，Real Server 的网关必须指向LVS，否则报文无法送达客户端。

特点：

1、NAT 技术将请求的报文和响应的报文都需要通过 LB 进行地址改写，因此网站访问量比较大的
时候 LB 负载均衡调度器有比较大的瓶颈，一般要求最多之能 10-20 台节点
2、只需要在 LB 上配置一个公网 IP 地址就可以了。
3、每台内部的 realserver 服务器的网关地址必须是调度器 LB 的内网地址。
4、NAT 模式支持对 IP 地址和端口进行转换。即用户请求的端口和真实服务器的端口可以不一致。

优点：

集群中的物理服务器可以使用任何支持TCP/IP 操作系统，只有负载均衡器需要一个合法的IP 地
址。

缺点：

扩展性有限。当服务器节点（普通PC 服务器）增长过多时,负载均衡器将成为整个系统的瓶颈，因
为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时，大量的数据包都交汇
在负载均衡器那，速度就会变慢！

4.2 LVS DR模式(局域网改写MAC地址)

LVS DR模式

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将客户端请求报文的源
MAC 地址改为自己DIP 的MAC地址，目标MAC改为了RIP 的MAC 地址，并将此包发送给RS。
③.RS 发现请求报文中的目的MAC 是自己，就会将次报文接收下来，处理完请求报文后，将响应
报文通过lo 接口送给eth0 网卡直接发送给客户端。
注意：需要设置lo 接口的VIP 不能响应本地网络内的arp 请求。

总结：

1、通过在调度器 LB 上修改数据包的目的 MAC 地址实现转发。注意源地址仍然是 CIP，目的地址
仍然是 VIP 地址。
2、请求的报文经过调度器，而 RS 响应处理后的报文无需经过调度器 LB，因此并发访问量大时使
用效率很高（和 NAT 模式比）
3、因为 DR 模式是通过 MAC 地址改写机制实现转发，因此所有 RS 节点和调度器 LB 只能在一个
局域网里面
4、RS 主机需要绑定 VIP 地址在 LO 接口（掩码32 位）上，并且需要配置 ARP 抑制。
5、RS 节点的默认网关不需要配置成 LB，而是直接配置为上级路由的网关，能让 RS 直接出网就
可以。
6、由于 DR 模式的调度器仅做 MAC 地址的改写，所以调度器 LB 就不能改写目标端口，那么 RS
服务器就得使用和 VIP 相同的端口提供服务。
7、直接对外的业务比如WEB 等，RS 的IP 最好是使用公网IP。对外的服务，比如数据库等最好
使用内网IP。

优点：

• 和TUN（隧道模式）一样，负载均衡器也只是分发请求，应答包通过单独的路由方法返回给客户
  端。与VS-TUN 相比，VS-DR 这种实现方式不需要隧道结构，因此可以使用大多数操作系统做为
  物理服务器。
• DR 模式的效率很高，但是配置稍微复杂一点，因此对于访问量不是特别大的公司可以用
  haproxy/nginx 取代。日1000-2000W PV或者并发请求1 万一下都可以考虑用haproxy/nginx。

缺点：

所有 RS 节点和调度器 LB 只能在一个局域网里面

4.3 LVS TUN模式(IP封装、跨网段)

LVS TUN模式

①.客户端将请求发往前端的负载均衡器，请求报文源地址是CIP，目标地址为VIP。
②.负载均衡器收到报文后，发现请求的是在规则里面存在的地址，那么它将在客户端请求报文的
首部再封装一层IP 报文,将源地址改为DIP，目标地址改为RIP,并将此包发送给RS。
③.RS 收到请求报文后，会首先拆开第一层封装,然后发现里面还有一层IP 首部的目标地址是自己
lo 接口上的VIP，所以会处理次请求报文，并将响应报文通过lo 接口送给eth0 网卡直接发送给客
户端。
注意：需要设置lo 接口的VIP 不能在共网上出现。

总结：

1.TUNNEL 模式必须在所有的 realserver 机器上面绑定 VIP 的 IP 地址
2.TUNNEL 模式的 vip ------>realserver 的包通信通过 TUNNEL 模式，不管是内网和外网都能通
信，所以不需要 lvs vip 跟 realserver 在同一个网段内。
3.TUNNEL 模式 realserver 会把 packet 直接发给 client 不会给 lvs 了
4.TUNNEL 模式走的隧道模式，所以运维起来比较难，所以一般不用。

优点：

负载均衡器只负责将请求包分发给后端节点服务器，而RS 将应答包直接发给用户。所以，减少了负载均衡器的大量数据流动，负载均衡器不再是系统的瓶颈，就能处理很巨大的请求量，这种方式，一台负载均衡器能够为很多RS 进行分发。而且跑在公网上就能进行不同地域的分发。

缺点：

隧道模式的RS 节点需要合法IP，这种方式需要所有的服务器支持”IP Tunneling”(IP
Encapsulation)协议，服务器可能只局限在部分Linux 系统上。

4.4 LVS FULLNAT模式

无论是 DR 还是 NAT 模式，不可避免的都有一个问题：LVS 和 RS 必须在同一个 VLAN 下，否则
LVS 无法作为 RS 的网关。这引发的两个问题是：
1、同一个 VLAN 的限制导致运维不方便，跨 VLAN 的 RS 无法接入。
2、LVS 的水平扩展受到制约。当 RS 水平扩容时，总有一天其上的单点 LVS 会成为瓶颈。
Full-NAT 由此而生，解决的是 LVS 和 RS 跨 VLAN 的问题，而跨 VLAN 问题解决后，LVS 和 RS
不再存在 VLAN 上的从属关系，可以做到多个 LVS 对应多个 RS，解决水平扩容的问题。
Full-NAT 相比 NAT 的主要改进是，在 SNAT/DNAT 的基础上，加上另一种转换，转换过程如下：

LVS FULLNAT模式

1. 在包从 LVS 转到 RS 的过程中，源地址从客户端 IP 被替换成了 LVS 的内网 IP。内网 IP 之间
   可以通过多个交换机跨 VLAN 通信。目标地址从VIP 修改为RS IP.
2. 当 RS 处理完接受到的包，处理完成后返回时，将目标地址修改为LVS ip，原地址修改为RS
   IP，最终将这个包返回给 LVS 的内网 IP，这一步也不受限于 VLAN。
3. LVS 收到包后，在 NAT 模式修改源地址的基础上，再把 RS 发来的包中的目标地址从 LVS 内
   网 IP 改为客户端的 IP,并将原地址修改为VIP。
   Full-NAT 主要的思想是把网关和其下机器的通信，改为了普通的网络通信，从而解决了跨 VLAN
   的问题。采用这种方式，LVS 和 RS 的部署在 VLAN 上将不再有任何限制，大大提高了运维部署的
   便利性。

总结

1. FULL NAT 模式不需要 LBIP 和 realserver ip 在同一个网段；
2. full nat 因为要更新 sorce ip 所以性能正常比 nat 模式下降 10%

5 Keepalive原理

• Keepalived是Linux下一个轻量级别的高可用解决方案。虽然它没有HeartBeat功能强大，但是Keepalived部署和使用非常的简单，所有配置只需要一个配置文件即可以完成。
• keepalive 起初是为LVS 设计的，专门用来监控lvs 各个服务节点的状态，后来加入了vrrp 的功能，因此除了lvs，也可以作为其他服务（nginx，haproxy）的高可用软件。
• VRRP 是virtual router redundancy protocal（虚拟路由器冗余协议）的缩写。VRRP 的出现就是为了解决静态路由出现的单点故障，它能够保证网络可以不间断的稳定的运行。所以keepalive 一方面具有LVS cluster node healthcheck 功能，另一方面也具有LVS director failover。

5.1 keepalived体系结构

keepalived运行时，会启动3个进程，分别为：core(核心进程)，check和vrrp.

• core：负责主进程的启动，维护和全局配置文件的加载；
• check：负责健康检查
• vrrp：用来实现vrrp协议

keepalived体系结构

5.2 Keepalvied的工作原理

• 网络层：Keepalived通过ICMP协议向服务器集群中的每一个节点发送一个ICMP数据包(有点类似与Ping的功能)，如果某个节点没有返回响应数据包，那么认为该节点发生了故障，Keepalived将报告这个节点失效，并从服务器集群中剔除故障节点。

• 传输层：Keepalived在传输层里利用了TCP协议的端口连接和扫描技术来判断集群节点的端口是否正常，比如对于常见的WEB服务器80端口。或者SSH服务22端口，Keepalived一旦在传输层探测到这些端口号没有数据响应和数据返回，就认为这些端口发生异常，然后强制将这些端口所对应的节点从服务器集群中剔除掉。

• 应用层：Keepalived的运行方式也更加全面化和复杂化，用户可以通过自定义Keepalived工作方式，例如：可以通过编写程序或者脚本来运行Keepalived，而Keepalived将根据用户的设定参数检测各种程序或者服务是否允许正常，如果Keepalived的检测结果和用户设定的不一致时，Keepalived将把对应的服务器从服务器集群中剔除。

5.3 VRRP选举机制

VRRP路由器在运行过程中有三种状态：

1. Initialize状态： 系统启动后就进入Initialize，此状态下路由器不对VRRP报文做任何处理；
2. Master状态；
3. Backup状态；
   一般主路由器处于Master状态，备份路由器处于Backup状态。

VRRP使用选举机制来确定路由器的状态，优先级选举：

1. VRRP组中IP拥有者。如果虚拟IP地址与VRRP组中的某台VRRP路由器IP地址相同，则此路由器为IP地址拥有者，这台路由器将被定位主路由器。
2. 比较优先级。如果没有IP地址拥有者，则比较路由器的优先级，优先级的范围是0~255，优先级大的作为主路由器
3. 比较IP地址。在没有Ip地址拥有者和优先级相同的情况下，IP地址大的作为主路由器。

5.4 keepalived & heartbeat

• Heartbeat、Corosync是属于同一类型，Keepalived与Heartbeat、Corosync，根本不是同一类型的。Keepalived使用的vrrp虚拟路由冗余协议方式；Heartbeat或Corosync是基于主机或网络服务的高可用方式；简单的说就是，Keepalived的目的是模拟路由器的高可用，Heartbeat或Corosync的目的是实现Service的高可用。

• 一般Keepalived是实现前端高可用，常用的前端高可用的组合有，就是我们常见的LVS+Keepalived、Nginx+Keepalived、HAproxy+Keepalived。而Heartbeat或Corosync是实现服务的高可用，常见的组合有Heartbeat v3(Corosync)+Pacemaker+NFS+Httpd 实现Web服务器的高可用、Heartbeat v3(Corosync)+Pacemaker+NFS+MySQL 实现MySQL服务器的高可用。

• 总结一下，Keepalived中实现轻量级的高可用，一般用于前端高可用，且不需要共享存储，一般常用于两个节点的高可用。而Heartbeat(或Corosync)一般用于服务的高可用，且需要共享存储，一般用于多节点的高可用。

6 HeartBeat原理

HeartBeat集群组件

• 心跳检测
• 资源管理

7 HAProxy原理

• HAProxy 的优点能够补充 Nginx 的一些缺点，比如支持 Session 的保持，Cookie 的引导;同时支持通过获取指定的 URL 来检测后端服务器的状态。

• HAProxy 跟 LVS 类似，本身就只是一款负载均衡软件;单纯从效率上来讲 HAProxy 会比 Nginx 有更出色的负载均衡速度，在并发处理上也是优于 Nginx 的。

• HAProxy 支持 TCP 协议的负载均衡转发，可以对 MySQL 读进行负载均衡，对后端的 MySQL 节点进行检测和负载均衡，可以用 LVS+Keepalived 对 MySQL 主从做负载均衡。

7.1 会话保持方案

同一客户端访问服务器，Haproxy保持回话的三种方案：

1. Haproxy将客户端ip进行Hash计算并保存，由此确保相同IP访问时被转发到同一真实服务器上。
2. Haproxy依靠真实服务器发送给客户端的cookie信息进行回话保持。
3. Haproxy保存真实服务器的session及服务器标识，实现会话保持功能。

7.2 Haproxy代理模式

• 四层tcp代理：Haproxy仅在客户端和服务器之间双向转发流量，可用于邮件服务内部协议通信服务器、Mysql服务等；
• 七层应用代理：Haproxy会分析应用层协议，并且能通过运行、拒绝、交换、增加、修改或者删除请求（request）或者回应（reponse）里指定内容来控制协议。可用于HTTP代理或https代理。

7.3 haproxy、Nginx、LVS比较

Nginx&LVS*HAProxy

• 大型网站架构：对性能有严格要求的时候可以使用lvs或者硬件F5，单从负载均衡的角度来说，lvs也许会成为主流，更适合现在大型的互联网公司；
• 中型网站架构：对于页面分离请求由明确规定，并且性能有严格要求时，可以使用haproxy
• 中小型网站架构：比如日访问量小于1000万，需要进行高并发的网站或者对网络不太严格的时候，可以使用nginx

8 Nginx原理

• 反向代理
• 负载均衡

9 nginx反向代理怎么配置

• upstream_module：负载均衡
• proxy_pass：请求转发

10 nginx反向代理怎么知道其中一台tomcat挂掉了？

Nginx配置这两个参数，可以查看到请求落在了后端的具体哪个server上。

• upstream_addr
• upstream_status