前言
话说之前大学放暑假的时候，我到一个餐厅打工两个月，Title 是初级传菜员。正是这次打工经验，为我带来了一波潜藏已久的素材，请听听我的故事吧~
本文主要内容如下：
一、餐厅角色
在餐厅主要有这几种角色：
- 服务员：负责记录客户已点哪些菜、上菜时间、上菜、划掉菜。可以将多个服务员都当做客户端，相对于传菜员来说。
- 传菜员：负责通知厨房走菜、划菜、传菜。可以将传菜员当作 Keepalived 组件。
- 厨师：烹饪、装盘。可以将厨师当作后台真实服务器。
为什么需要传菜员这个角色？有了传菜员这个角色后，发生了什么呢？
- 服务员需要服务顾客，不需要离开包间去厨房拿菜。（单一职责）
- 服务员不需要定期到厨房询问菜是否好了。（解耦）
流程图如下：
① 客户点菜下单。
② 服务员记录菜名、上菜时间。这里的上菜时间是指客户要求的上菜时间，因为有些客户可能想等朋友一起来了再吃。
③ 服务员将一份订单交给传菜员，另外一份订单留在包间。
④ 传菜员大声通知多位厨师有哪些菜要做，什么时候开始上菜。
⑤ 厨师准备食材和烹饪。如果缺少食材，厨师还会告诉传菜员，由传菜员转告服务员说这道菜不能做。
⑥ 厨师做好后将菜装在盘子里，然后递给传菜员。
⑦ 传菜员将订单上对应的菜划掉，表示已经做了。
⑧ 传菜员将菜端给服务员。
⑨ 服务员将菜从订单上划掉。
⑩ 服务员将菜端上餐桌。
这个流程简单来说就是客户下单->服务员传单->传菜员通知->厨师烹饪->传菜员传菜->服务员上菜。
上面的流程不正是服务员请求数据，将请求都发给了传菜员，传菜员将请求转发给了厨师，厨师处理完后返回结果。妙啊！！
二、初探 Keepalived 的路由方案
2.1 为什么需要路由方案
上篇我们讲到 Keepalived 的负载均衡调度算法，通过这个算法选出某台真实服务来处理本次客户端请求。
就好比传菜员要将要做的菜，告诉其中一个厨师（一般是告诉大厨）。
而如何告诉厨师呢？是用
喇叭喊，还是传呼机，还是走到他旁边告诉他？
服务员与厨师对话的方式
对于 Keepalived 来说，选择了一个真实服务器后，后续还有两个流程需要梳理下：
- Keepalived 如何将请求转发给这个服务呢？
- 服务处理完这个请求后，如何将处理结果返回给客户端？
上面两个流程就是 Keepalived 的路由方案要做的事。
Keepalived 有三种路由方案：NAT、TUN、DR。
2.2 配置在哪
具体的配置哪种路由方案在 keepalived.conf 配置文件中，其中有一个 lb_kind 配置，可以配置成 NAT、DR、TUN 三种。目前配置的是 DR 模式。
还有一个配置 lb_algo，这个是配置调度算法的，比如这里配置的 wrr 加权轮询调度算法。
2.3 LVS 的结构
上篇我们说到 Keepalived 是利用了 LVS 模块的功能来实现负载均衡的。那么 LVS 的结构是怎么样的呢？
分为两个模块：前端的负载均衡器（Load Balance，简称 LB），后端的多台真实服务器（Real Server, 简称 RS）组成。LB 负责流量转发，RS 负责处理请求，然后将请求返回。
三、深入理解 Keepalived 的路由方案
3.1 NAT 路由方案
NAT 的全称是 Network Address Translation，网络地址转换。它有两个功能：
- 使企业内部的私有 IP 可以访问外网，
- 使外部用户可以访问位于公司内部的私有 IP 主机。
对于 Keepalived 来说，这种模式就好比餐厅的标准下单上菜模式：多个服务员将订单数据转给传菜员，传菜员通知厨师进行烹饪，厨师把菜做好后转给传菜员，传菜员负责把菜传递给服务员。
如下图所示，LVS 负载调度器有两块网卡，配置了不同的 IP 地址，网卡 eth0 设置为公网 VIP 与外部网络连通，网卡 eth1 设置为私有 VIP 与内部网络通过交换设备相互连接，
示例如下：
eth0 网卡 -> 公网 VIP -> 外部网络
eth1 网卡 -> 私有 VIP -> 交换设备 > 内网网络
原理图如下所示：
① 比如现在 eth0 网卡配置了一个公有 VIP 如 10.1.2.88，客户端发送的请求都是到这个 Public VIP（目标地址）。
② 主 LVS Router 负责接收请求，将请求的目的地址（Public VIP）替换成 NAT VIP（192.168.56.88）。
③ 这个 NAT VIP 和后端服务器同属一个局域网，可以相互访问，请求经过负载均衡调度选择一个真实服务器。
④ LVS 修改数据包中的目标地址和目标端口为真实服务器的。
⑤ 真实服务器处理完请求后，将应答数据返回给 LVS Router。
⑥ LVS Router 将应答数据的源 IP 地址 NAT VIP 和端口转换成 Public VIP 和 LVS 的端口，然后转发给外部网络的客户端。
对于客户端而言，它只和 Public VIP 打交道，并不知道 NAT VIP，更不知道真实服务器的 IP 地址，这个过程也称为 IP 伪装。
对于服务员💁🏻来说，她只和传菜员打交道，并不知道厨师👩🏻🍳 。
1.2 LVS-TUN 路由方案
1.2.1 NAT 方案的瓶颈
如果餐厅的生意非常火爆，一个传菜员会非常忙，有可能厨师已经把菜做好了，但是传菜员没有时间传给服务员，那么餐厅的瓶颈就是传菜员了。
如下所示，一个传菜员对应三个厨师，而且做的菜很多，都需要传菜员将菜端给包间外的服务员。
NAT 的路由方案存在瓶颈，由于所有的数据请求及响应的数据包都需要经过 LVS 调度器转发，如果后端服务数量很多，客户端访问流量也很大的话，那么调度器会忙于调度转发和地址替换等操作。
为了解决 NAT 的性能问题，TUN 路由方案是个比较好的选择。TUN 方案中，真实服务器处理完结果后，直接返回给客户端。但是这就要求真实服务器能够与外部网络连接。
也就是说厨师做好菜后，厨师直接把菜递给服务员，不需要经过传菜员。厨师是对外可见的。
1.2.2 TUN 详解
TUN 其实是 tunneling（隧道）的缩写，而 TUN 路由方案就是基于 IP 隧道的一种技术。
我们熟知的 VPN 技术就是 IP 隧道技术。
IP 隧道其实是一种封装技术，将一个 IP 报文封装在另一个 IP 报文中。分为如下两步：
- ① 先将原始数据包进行封装。
- ② 然后添加新的源地址+端口、新的目标地址+端口。
它可以将原始数据包封装并添加新的包头（内容包括新的源地址及端口、目标地址及端口），从而实现将一个目标为调度器VIP地址的数据包封装，通过隧道转发给后端的真实服务器（Real Server），通过将客户端发往调度器的原始数据包封装，并在其基础上添加新的数据包头（修改目标地址为调度器选择出来的真实服务器的IP地址及对应端口），LVS（TUN）模式要求真实服务器可以直接与外部网络连接，真实服务器在收到请求数据包后直接给客户端主机响应数据。
原理图如下所示：
TUN 模式的缺点：
隧道模式的RS节点需要合法 IP，这种方式需要所有的服务器支持 IP Tunneling 协议。
1.3 LVS-DR 模式
那么 LVS 的 TUN 路由模式有没有什么问题呢？
因为 TUN 的方式必须在 LVS 调度器和真实的服务器之间有一个隧道连接，这个创建隧道的过程会对服务器增加负担。
在餐厅这种场景中，TUN 模式中，厨师是对外可见的，菜好了后直接和服务员对接；而 DR 模式中，厨师不可见，统一被看成是传菜员。
DR 模式和 TUN 模式的相同之处：
- 模式中，用户的请求被调度器负载均衡到真实服务器上，然后真实服务器把响应结果返回给客户端。
- 客户端的请求数据包中目标 IP 为 LVS 的 VIP，源 IP 为客户端 IP。
DR 模式和 TUN 模式不同之处：
- DR 模式要求调度器与后端服务器必须在一个局域网内。
- DR 模式不需要创建 IP 隧道。
- DR 模式中，VIP 需要在 LVS 调度器与后端所有的服务器间共享。
- DR 模式中，真实服务器处理完结果后，返回数据包时，设置源 IP 为 VIP 地址，目标 IP 为客户端 IP。
- DR 模式中，LVS 调度器和真实服务器在同一物理网段上。同一网段机器数量有限，限制了其应用范围。
更细节的内容
负载均衡器和RS都使用同一个IP对外服务但只有 DR（Director Server，可以理解为 LVS 的核心） 对 ARP 请求进行响应，所以 RS （Real Server，真实服务器）对本身这个 IP 的 ARP 请求保持静默。
也就是说，网关会把对这个服务IP的请求全部定向给 DR。而 DR 收到数据包后根据调度算法,找出对应的 RS，把目的 MAC 地址改为 RS 的 MAC（因为 IP 一致）并将请求分发给这台 RS 这时 RS 收到这个数据包，处理后直接返回给客户端。由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域，也可以简单的理解为在同一台交换机上。
四、三种模式对比
推荐 DR 模式。
