在基础设施领域，从谈云计算到聊云原生，无论技术怎么革新，作为业务流量入口四层负载均衡都在默默的支撑着业务的运行，随着业务规模扩大，其中稳定、高性能是业务对四层负载均衡的核心诉求，买硬件四层负载均衡太贵，纯软件实现规模又上不去成本还高，唯有基于开源方案自研才能破局。高性能负载均衡不好做，本文分享一些实践经验，主要讨论“网易数帆的高性能负载均衡如何基于开源负载均衡软件DPVS打造的”。

为什么选择DPVS

目前高性能负载均衡研发的一个流行方案是使用DPDK（Data Plane Development Kit），这是一个用于包数据处理加速的软件库，使用了网卡用户态驱动、零拷贝、内存Hugepage和Polling模式等技术。业界基于DPDK开发负载均衡主要有两种模式，一是直接在DPDK库上自研或者移植负载均衡业务逻辑代码，二是使用DPDK作为加速通道加速已有的负载均衡的开源软件。DPVS就是一个使用DPDK软件库加速LVS（DPDK+LVS）的高性能负载均衡开源软件，详见https://github.com/iqiyi/dpvs。

网易数帆选择基于DPVS开发新一代四层负载均衡，是因为DPVS既解决了LVS的性能瓶颈问题，又具备LVS的丰富的负载均衡业务逻辑，这使得团队可以把主要精力放在四层负载均衡和云内网络框架适配、运维监控、稳定性和软硬结合提升性能的优化上，而非重复开发负载均衡业务逻辑。

本文从DPVS云化场景改造、资源隔离保障系统稳定性、软硬件结合提高系统性能和监控运维功能增强四个方面分享网易数帆高性能四层负载均衡实践之路。

云化场景的改造

云化场景的核心改造涉及到如下三个方面内容：

云化网络架构适配
用户源地址透传设计
健康检查框架设计

这三个方面的改造目标是让网易数帆四层负载均衡具备“连通虚拟网络且隔离租户”、“透传真实的源IP地址给业务“、“集中管理健康检查流量”的能力。这些能力是网易数帆四层负载均衡产品化开发的基础功能要求，满足这些要求的四层负载均衡才可以支撑起云场景（容器云/虚拟机云/裸金属云等）的业务，下文逐一介绍实现要点。

云化网络架构适配

图 1.

图 2.

如图2所示，网易数帆四层负载均衡外网配置使用KNI（Kernel NIC Interface）口bond2.kni和DPDK Bond口bond2；发布路由的程序Quagga，Quagga通信网络依赖于Linux内核协议栈，而外网的网卡被DPVS用户态程序接管，因此Quagga需要将借助bond2.kni（DPDK创建的虚拟内核口）口将BGP通信流量发给外网路由设备,而bond2口则负责业务流量的收发。

网易数帆四层负载均衡内网配置使用bond1口，并根据组网需求建立对应的VLAN子接口负责和云网络宿主机网络连通，和VPC通信数据需要使用开发的VXLAN模块进行VXLAN封装和解封装。

增加VxLAN处理模块

VxLAN模块主要是用来连接云网络和隔离租户的，其属于云化网络连通性中非常关键的部分，所有发给云网络的数据包需要先进行VxLAN封装， VxLAN模块就必须足够的简单和高性能，还要方便控制面程序进行管理配置。

VxLAN模块在开发之初参考了下面两种方案：

选择1:参照Kernel VxLAN机制
选择2:参照Openv Switch VxLAN

但是网易数帆最后选择了第3种，去除VxLAN口的逻辑概念，将VxLAN封装和解封装直接使用数据面实现，选择该方法的考虑是以下三点：

性能更优，直接进行VxLAN数据包的封装和解封装，在选择后端时候，VxLAN封装信息就已经具备，这个时候少了一个选择VxLAN口的过程；
实现简单，直接流程中实现VxLAN封装和解封装就不需要进行VxLAN口管理；
逻辑清晰，控制面就不需要关注VxLAN口建立和删除。

实现方法命令举例，使用如下方法建立云化场景的后端：

    ipvsadm -A -t 60.191.87.35:2022 -s wrr
  ipvsadm -a -t 60.191.87.35:2022 -r 192.168.1.178:8700 -T 10.182.6.87-10.182.4.59-5015 -m -w 100

建立监听60.191.87.35:2022，后端地址是192.168.1.178:8700，vxlan封装信息是源IP地址是10.182.6.87，目的IP是10.182.4.59和租户VNI 5015。

用户源地址透传设计

用户地址透传是指负载均衡后端程序能够获取到客户端的公网地址，该功能是云上用户的强需求，用户获取到源地址后可以进行地域用户画像、黑白名单和地域用户行为分析等。设计支持云化网络场景时候就必须解决用户地址透传问题。

网易数帆的分析是：流量在经过中间层的四层负载均衡，如果四层负载均衡采用FNAT模式，会导致地址源地址丢失（因为FNAT会更换源地址为LOCAL地址），无法满足用户地址透传的需求，因此我们决定使用DNAT模式，这里重点描述下遇到的问题以及解决方法。

遇到的问题是：

社区DPVS DNAT模式只支持单CPU Core。
社区主推使用FNAT，DNAT单CPU Core模式使用的人比较少，存在不稳定因素。

社区无法实现DNAT模式多CPU Core，这是社区的一大缺点，其无法使用多Core和硬件网卡类型以及架构关联很大。社区实现精妙点是会话（类似于conntrack）无锁，每CPU会话独立管理，为了达到此要求，需要正反向流量使用一个CPU处理，因为社区支持的是经典网络的场景，在多业务CPU CORE DNAT模式下，从后端回来数据包（反向流量）无法找到固定的特征使用硬件分流一定回到正向流量所在的CPU。

图 3.

因此云化场景需要解决VPC云主机后端回包的问题，网易数帆采用了新型网卡支持的rte_flow支持的使用VxLAN inner dst mac进行反向流量的硬件分流解决了此问题，具体解决过程描述如图4所示：

图 4.

四层负载均衡采用双臂部署，通过双网卡实现，每个CPU固定绑定一个队列，外网网卡的rss硬件功能根据数据包的五元组把数据包Hash到外网网卡硬件队列里，绑定该队列CPU会使用该CPU预先关联的MAC地址作为Vxlan inner src MAC将流量发给云网络；后端记录该mac并作为发包Vxlan inner dst MAC发出；内网网卡根据VxLAN数据包内层的目的MAC地址进行精确匹配把从后端来的数据包放到与内层MAC绑定的rx队列中，因为rx队列和CPU一一绑定，所以从后端回来的数据包能回到正向流量处理的CPU。详细过程举例如下：

数据流量发给四层负载均衡外网口时候rss到了外网口q3队列，在CPU3上建立正向会话；
CPU3进行VxLAN封装将VxLAN内层头的src MAC更换成02:02:00:00:00:03发给云化网络，这个src MAC地址03代表CPU Core ID。
宿主机所在的SDN程序会记录该发包五元组对应的源MAC，后端发给负载均衡流量时候会查询该记录，将VxLAN inner dst MAC换成02:02:00:00:00:03；
四层负载均衡的内网网卡根据VxLAN inner dst MAC进行数据分流，根据网卡硬件rte_flow配置的策略，将反向流量发给内网口的q3，从而CPU3继续处理。

设计新的健康检查框架

健康检查是四层负载均衡重要的组成部分，其帮助负载均衡判断业务后端服务是否处于正常工作状态，并且及时剔除不可工作的后端服务，始终让负载均衡的后端服务处于健康状态，确保过负载均衡的业务稳定运行。

云化场景下的后端处于云化网络中，传统的健康检查程序是socket程序实现的，socket不支持VxLAN封装，无法连通云网络的后端，因此传统的健康检查程序在云化场景中无法正常工作。为了解决传统健康检查面临的问题，网易数帆提供了健康检查通道技术，帮助健康检查程序连通云网络，传统的健康检查程序零改动的即可检查云化网络的业务后端服务。

图 5.

那么使用Kernel协议栈的健康检查程序和位于用户态协议栈的健康检查通道是如何协同工作的呢？如图5所示：

健康检查程序不需要改动，直接将想要检测的后端云主机地址和端口改成健康检查通道的预先分配的地址和端口；
建立程序和通道接口地址端口的的绑定关系，建立通道和后端地址端口的绑定关系（间接建立可健康检查程序和后端地址待和端口的绑定关系）；
健康检查流量被预先配置的路由和预先配置的静态ARP信息牵引到bond2.kni口，然后这个流量进入到健康检查通道；
检查通道将流量进行FNAT转换和进行VxLAN封装后发给对应的后端；
从VPC后端返回的流量反向运行上述逻辑，控制流量通过bond2.kni口发给传统健康检查程序。

这样设计的健康检查机制有如下优点：

健康检查程序透明，健康检查通道是工作在数据面的逻辑层概念，可以理解其为中间代理层，健康检查通道全权代理健康检查程序的检查行为，对健康检查程序透明，传统网络的健康检查程序可直接被使用对云化网络后端进行检查行为；
运维方便，健康检查通道统一管理了所有租户的健康检查行为；
简单，这样的架构，使健康检查通道解耦了健康检查和云化网络连通的逻辑，并且提供接口供控制面使用配置上也非常简单；
通用，这样的结构也适用于经典网络场景。

资源隔离保障系统稳定性

DPVS原生框架已经将负载均衡数据处理会话做到CPU级别隔离，该机制很大的提升了会话的并发和新建能力，此外原生框架采用了DPDK作为底层加速通道，已经提供了基础的高性能框架，但是从实际运行业务的稳定性角度去考虑，其框架上仍有很大的改进点，下面先分析原生框架存在的问题，再给出网易数帆的解决方案。

图 6.

如图6所示，将DPVS框架按照流量源的差异性分为六个部分；图中使用6个序号表示：

健康检查前半部分流量
健康检查后半部分流量
BGP心跳和配置同步前半部分流量
BGP心跳和配置同步后半部分流量
控制面配置流量
负载均衡转发业务流量

问题1: 控制面对接模块和KNI模块会相互影响

1和3需要master cpu0运行KNI模块处理逻辑，将流量从和内核的共享队列中取出；5也需要master cpu0处理用户业务配置，而用户业务配置量级存在突发和不确定性，会独占master cpu0，导致序号1和3流量处理不及时而被丢弃。简要描述该问题是，控制面对接模块和KNI模块因争抢master cpu0计算资源而互相影响。

问题2：BGP 通信流量和业务流量相互影响

4属于BGP 通信流量的后半部分，该流量社区原生处理是轮询使用各个slave CPU将数据包放到绑定的队列中发到外网，BGP通信流量依赖外网网卡收发队列资源和所有slave CPU计算资源；6属于负载均衡业务流量，业务流量具备非常明显的突发性，当发生流量突发时候，会导致外网网卡的队列资源和CPU资源被长时间占用，BGP 通信流量因获取不到队列和CPU资源，数据包被丢弃，BGP产生断连。

问题3：健康检查通道的流量和业务流量相互影响

2会用slave CPU1和下联口队列1将数据包收发给VPC后端；6的业务流量具备明显的突发性，正像在问题2中解释的那样，也会使健康检查通道被影响，可能导致健康检查工作异常，进而引发业务无法提供服务。

经过分析，上述三个问题描述了各个流量之间的相互影响和资源依赖，社区原生框架工作在业务流量相对稳定、配置流变动小、普通规模的后端和稳定的组网环境还可以，但是为达到我们产品化级别的稳定性要求，我们还需要做大量工作，所以我们需要使用资源隔离机制保障系统稳定性，网易数帆的解决方法如图7：

图 7.

控制面对接模块独占CPU n+1，KNI模块使用master cpu0处理，两个模块CPU级别物理独立，解决问题1；
BGP 通信的流量使用CPU n和qn，业务流量使用CPU1… CPU n-1和q1…qn-1,两个模块CPU和外网队列物理级别独立，解决问题2；
健康检查通道使用CPU n、下联口的qn队列，业务使用上下联口的CPU1…CPUn-1、q1…qn-1 ，健康检查通道的流量和业务流量物理资源隔离而不相互影响，解决问题3；

我们采用的这样的解决方法，解决了提出的原生框架的三个缺陷，但是也引入了新的问题，由图7可知，BGP 通信的流量和健康检查通道的流量会共用CPU n, 共用就会产生影响，但是经过实际极限性能测试，BGP 通信的流量和健康检查通道的流量都不大，一个物理CPU n处理完全足够，所以在实际业务中不用担心这个问题。

软硬件结合提高系统性能

高性能低成本，一直是数据面开发者追求的目标，我们在启动新负载均衡项目时候，定下的目标是千万级别的并发、千万级别的PPS、百万级别的新建能力。因为这个级别的性能指标可以帮助公司满足业务需求；DPVS是DPDK和LVS的结合体，具备DPDK的性能优势（Kernel by-pass 、RX Steering and CPU affinity、Zero Copy、Polling instead of interruptd等）,继承这些优势，可以帮助实现千万级别的过包率。我们从使用软硬结合机制提高业务最关注的并发能力和业务秒杀场景所需要的新建能力。

会话无锁的实现

会话无锁是并发和新建能力所需要的核心技术。这块我们创新的新开发了DNAT模式，使用网卡硬件分流（例如：rss和rte_flow）和后端SDN软件的设计可以把一个会话的正反向流量都在一个CPU core处理，这样分在不同CPU core上的会话互不影响，会话之间也就不需要加锁了。上文中Dnat模式实现已经讲述了这一点。

使用网卡硬件卸载特性

除了使用上面介绍的网卡的硬件分流rss和rte_flow外，还使用网卡卸载了VxLAN数据包的内层L4的Checksum计算，我们下一步计划使用Mellanox 25G CX5网卡的VxLAN和Qos硬件卸载功能进一步提升新建能力和PPS能力。

监控运维功能增强

监控运维能力是负载均衡组件的硬实力的代表，我们基于网易内部业务实践运维需求，这块做了大量的工作，下面简要描述下，后续会出文专门对监控运维进行讨论。

多维度的监控能力

业务维度：新增VIP级别统计，精确到负载均衡的后端级别，额外开发VIP维度的各个连接数统计、VIP Qos丢包统计、后端级别的连接数统计等;

CPU维度：精确到CPU级别，CPU维度的业务计数（并发连接数、丢包、等）;

系统维度：查看CPU使用率，丢包率统计，定位丢包发生位置点确认是否是DVPS导致业务问题等手段;

有了上述多维度的监控，通过业务资源维度的参考，当业务产生异常时候，能够清楚反映到监控的指标中，且经过业务和资源维度的对比，可以确定问题发生的模块，以及该问题发生在哪个数据面CPU是否和网卡有关系等。

日志分级管理

日志手段是组件的基础能力，在日志能力上，我们进行了分模块和日志分级别方式来提升日志记录的灵活性；不同的场景和模块可进行日志开启动作，并且指定特定模块的日志级别。

问题排查手段

关于运维手段，我们开发了条件计数功能。条件计数是一种出现连通性问题时候的一种辅助定位手段。为了更精准的定位和跟踪流量的功能，为了简化条件的复杂性和性能做平衡，目前仅仅提供源地址维度的条件；我们想通过该手段做如下跟踪：

跟踪是否收到其配置的源地址的发出的ARP request 和 ARP reply；
跟踪是否收到其配置的源地址发出的ICMP 数据包；
跟踪是否收到其配置的源地址发出的数据包；
跟踪某一个配置的源地址触发的流量是否到负载均衡流程，从负载均衡流程是否发出，该地址触发流量从后端回来时候是否进入负载均衡流程，是否从负载均衡流程发出。

总结

目前，网易数帆以DPVS为框架完成的新一代高性能的负载均衡已经稳定运行一年多，支撑网易内部网易传媒、网易云音乐、网易严选等各大业务方，各项性能指标都符合预期，其中新建连接能力达到百万级别，并发连接能力千万级别满足了业务需求，这是网易数帆拥抱开源，结合现有云计算架构和业务落地的一次有意义的实践，此外我们在功能和监控运维痛点解决上也做了大量设计工作，这个后续再讨论。

作者简介

刘勤龙，网易杭州研究院资深云计算开发工程师，7年服务端开发和优化经验，负责网易数帆四层负载均衡数据面设计，参与网易轻舟服务网格性能优化，目前专注于轻舟云原生Serverless平台底层的开发和优化工作。主要关注Kubernetes、Istio、Knative、Cilium等技术领域。

张晓龙，网易技术委员会委员，网易数帆轻舟业务部技术总监，2012年浙江大学博士毕业后加入网易杭州研究院，负责基础设施研发/运维至今。在虚拟化、网络、容器、大规模基础设施管理以及分布式系统等技术架构有多年经验，当前主要兴趣点在云原生技术方向。

创作场景

网易数帆基于 DPDK 的高性能四层负载均衡实践