提起负载均衡设备，程序员基本都打过交道。硬件的比如 F5、netscaler, 以前在赶集网就用 netscaler, 后来过保也没续... 软件的有 lvs、haproxy，当然了七层的 nginx 也算。关于转发模式也知道一些 dr、nat、tunnel 等等，轮循的算法有 rr、wrr、wlc 等等。但是内部原理除了网络同学，大部分同学只是简单的使用，借着这次调研 dpdk 机会，读读源码，一勺烩了。
背景
现代互联网流量越来越大，网卡吞吐能力也越来越强，从最早的 1gb, 到现在 10gb 是标配，以后可能 100gb, 所以负载均衡设备的线性扩展也遇到了瓶劲。谷歌前几年发布了关于 LB 的论文 Maglev, 估计是受启发，各大公司相继造 LB 轮子，爱奇异和小米同时用 dpdk + lvs 技术开发了自己的负载均衡软件，要是小米先开源，这名和利早就是小米同学的了... 虽然这些技术都是开源并且己知，很成熟的，能站在了巨人的肩膀上，将技术组合起来并开源也很历害，感谢爱奇异的大牛们。
lvs 的问题
IT 行业技术变化真快，刚毕业时 lvs 还是负载均衡界的小甜甜，才过了几年就成了牛夫人。中小公司 lvs 足够好用，但是内核比较低，尤其 fullnat 模式应用非常广泛。那 lvs 问题是什么呢？
主要是内核太慢，网络栈代码写的也不好，各种历史问题，很多 if 语句，这个很影响分支预测的。而lvs 的数据需要经过内核网络栈，再拷贝到用户空间，性能自然上不去。谷歌的 Maglev 完全是绕过了内核，从网卡收数据直接送到 LB. 这就是所谓的内核旁路 kernel bypass 技术，这个技术现在比较成熟，dpdk, open onload, netmap 等等。当年谷歌可是硬撸的，理念和技术水平领先一个时代。
什么是 dpvs
那再回头说什么是 dpvs 呢？dpdk + lvs，可以理解为经过内核旁路的 lvs ++. 对于原来熟悉 lvs 的人不会陌生。看官网得知，转发模式完全来自 lvs，就连代码部份函数名都是一样的。
上图是官网的一张图，右侧都是
dpvs 列出的优化点。那这些优化点难不难呢？难，但是，dpdk 都做好了。dpdk 程序最大的特点就是每个逻辑核都有自己的数据，有一个封装好的宏 RTE_PER_LCORE，即然都本地化了，那自然也没有锁开销。看源码得知，mbuf 分配，定时器这些都是本地化的。
dpvs 优点
lvs 相关的模式，转发算法目前没看到区别。性能优化都是 dpdk 层面的，减少 cpu cache miss, 减少 false sharing，NUMA 友好，绑定 cpu，其实想想这些不都是软件优化共性嘛。
- 用户态内核旁路，少去内核到用户空间的拷贝
- 网卡队列与 cpu 的绑定
-
flow director增加返程数据亲和性，往返都由同一个 cpu 处理 - cpu 数据本地化，无锁
- 实现轻量级 tcp stack，专用的性能自然好
dpvs 缺点
- 缺点还是有的，由于他是
lvs衍生出来的，所以lvs各个模式的缺点他都有。 - 相比
Maglev, 目前dpvs更适配intel网卡，看官网也支持其它厂商网卡。这其实算是dpdk的限制，毕竟intel的框架。 - 由于网卡被
dpvs专用，可能还需要专配一个网卡用于运维，或是开kni也行。 - 不支持
ipv6, 现在有强推的趋势，想对标Maglev, 还是越早支持越好。
小结
先写这些，之后再从源码角度分析 dpvs 业务处理流程，和各种优化的细节。
