企业级负载均衡解决方案之七：京东四层负载均衡解决方案ContainerLB

一、前言

根据文章《京东商城ContainerLB实践》里面的描述，京东在2016年的时候几乎已经把他的所有业务系统转成容器模式，“线上20万+容器实例承载着数千个业务应用”，这里无法知道京东容器云的管理平台是Kubernets还是自研平台，但是这样的平台面临的接入需求无疑巨量的。所以，京东也基于DPDK开发了自己的FULLNAT模式四层负载均衡系统ContainerLB，不同于其它负载均衡解决方案的是京东的负载均衡系统的后端服务器是一系列的容器而不是物理服务器或者虚拟机：

转载自https://blog.****.net/cloudvtech

二、ContainerLB的技术要点

2.1 ContainerLB集群

根据文章中描述的技术要点，ContainerLB使用了和Meglev类似的负载均衡节点接入技术，使用BGP或者OSPF作为ContainerLB服务器集群的接入算法。每个ContainerLB服务器运行quagga与开启OSPF/BGP的路由器做路由交互，通过这种策略来实现VIP的发布和横向容量负载能力扩展。ContainerLB使用RR、consistent hashing、最小连接数等算法进行负载均衡，但是文章并未提到连接的一致性问题如何处理。

2.2 FULLNAT负载均衡模式

由于京东本身VLAN隔离等需求，所以FULLNAT这种对网络需求极地的负载均衡模式就成为京东ContainerLB最佳的选择。基本思想和IPVS FULLNAT模式类似。

2.3 基于DPDK的高速转发

• 基于线程和RSS队列的CPU affinity
• 使用大页，减少TLB Miss，据称有10％～15％的提升
• 整个转发流程数据零拷贝
• 使用无锁队列提处理性能
• DPDK PMD模式进行轮询收包，减少中断开销

2.4 包处理的优化

• ContainerLB实现控制面和数据面CPU隔离，数据面线程pin到CPU core
• RSS实现数据包分流，RSS的队列和CPU core绑定
• 维护core local的数据结构，没有跨core的数据交互
• FULLNAT的LIP和CPU core绑定，加速后端选择过程
• Quagga通过DPDK KNI接口向外发布VIP信息

• 使用rte_prefetch0()进行数据预取，减少cache-miss次数
• 使用likely()和unlikely()进行分支预测
• 减少锁的使用，进行批量数据处理，分摊无法避免的读写锁的开销

转载自https://blog.****.net/cloudvtech

三、性能测试

据文章描述，ContainerLB单机的TPS在100M以上：

转载自https://blog.****.net/cloudvtech