一、前言
在互联网厂商业务不断扩展之后，多种服务的入口会导致接入流量的剧增，所以多数基于IPVS或者Nginx等初级负载均衡技术的早期方案都会面临故障或者失效，所以就像google开发meglev一样，许多互联网服务提供商也都纷纷开发自己的分布式软件负载均衡系统作为对外服务的接入口。
美团点评在它的技术博客上表明它也面临这样的接入流量爆炸问题，并且基于继续对IPVS的性能瓶颈的分析，开发了它们自己的四层分布式软件负载均衡系统，参见美团点评的技术博客《MGW——美团点评高性能四层负载均衡》。
转载自https://blog.csdn.net/cloudvtech
二、美团点评传统四层负载均衡技术面临的问题和解决方案
根据美团点评的运维经验总结，传统IPVS面临如下一些性能瓶颈：
- 中断爆炸
- 内核协议栈冗余处理
- 内核锁
- 上下文切换
- 连接一致性
2.1 中断爆炸
在大并发高速接入系统中，每个网卡可能都要以接近于线速的处理能力工作，这时候，每秒产生的中断响应次数是百万级别的,每一个中断都会抢占正在进行负载均衡后续处理的逻辑，造成大量的切换和cache miss，影响性能。所以在大并发的系统中，需要使用基于轮询模式的硬件请求处理模式。
2.2 内核协议栈的冗余处理
IPVS借助于netfilter进行数据包的处理，所以在到达IPVS的处理逻辑之前，需要经过很长的一条内核处理链，造成了IPVS整体处理能力的下降。需要使用内核bypass的技术缩小IPVS应用逻辑和网卡驱动的距离。
而DPDK提供的用户态PMD驱动可以解决2.1和2.2这两个问题。借助于Linux UIO技术，在用户态通过poll的形式直接处理网卡驱动的事件，批量的处理数据包，有很好的性能提升。同时由于DPDK针对Intel处理器架构下面的内存、NUMA等基础计算资源所做的优化，以及丰富的开发库的支持，所以使用DPDK作为基础开发框架。
2.3 内核锁
由于MGW使用FULLNAT作为转发方案，所以需要维护一个session表来追踪数据包源IP和NAT之后IP的对应关系；而在启动RSS的网卡中，同一个源IP的数据包可能会被分发到不同的CPU处理，所以可能存在请求和响应同时在系统中不同的CPU上处理，从而会对同一个session表同时进行读写，所以需要对session表的访问加锁，造成性能下降。
MGW使用CPU与local IP绑定的方式，保证同一个FULLNAT流程中的数据包能串行的在用一个CPU上处理，去掉了锁结构。
2.4 上下文切换
在传统Linux系统中，控制面和数据面是共享CPU的，在大量数据包需要处理的时候，会不断在控制面和数据面的处理逻辑间进行上下文切换，巨大的切换开销和cache miss会降低系统处理能力。
借助DPDK和UIO技术，在用户态绑定CPU到不同的线程进行转发逻辑处理，将合适数据的CPU留给控制面以及内核使用，这样数据面处理过程不再有切换开销，可以显著提升性能。
2.5 连接一致性
在分布式负载均衡系统中，需要保证同一个TCP连接上的数据包能够为同一个后端服务器所处理，所以分布式负载均衡系统需要一个状态同步方案能够保证不同负载均衡节点状态的一致性。
在Meglev中使用google开发的Meglev consistent hashing算法，来保证一定程度的一致性和出错状态较低的连接失败率；而在MGW中，使用了跨节点状态同步的方法来保证负载均衡集群中各个节点FULLNAT session状态的强一致性，保证路由器ECMP转发数据包到任何一个负载均衡节点都能被快速处理，这种强一致性可能会导致一定的控制面性能损失和更长的节点上线时间进行一个session同步的预热过程。同时在后端服务器选择中，使用了Meglev consistent hashing算法来保证出错时候的最小影响范围。
2.6 故障切换
MGW前端的交换机使用物理接口连接MGW的负载均衡服务器的NIC，负载均衡服务器上健康监测程序以500ms间隔监测本服务器的状态，发现异常，快速关闭网卡；在这种情况下，交换机会马上感知端口断电状态并且瞬间关闭到该端口的转发，几乎无延时的且走流量。
MGW宣称可以做到升级操作0丢包，主程序故障0丢包，其他异常（网线等）会有一个最长500ms的丢包(对应于状态监测程序500ms的监测间隔)：
转载自https://blog.csdn.net/cloudvtech
三、总结
美团点评的基于DPDK开发的FULLNAT模式MGW在实践中在传统网络环境和overlay大二层环境下都有很好的性能和稳定性，使用在网站数据库、千万级长连接、以及web服务等业务中。
转载自https://blog.csdn.net/cloudvtech