本文根据阿里云飞天八部金帅在大流量高并发互联网应用实践在线峰会上的题为《双十一技术揭秘——负载均衡性能优化演进之路》的演讲整理而成。

直播视频：点此进入

PDF下载：点此进入

在云计算时代，我们输出计算能力会像水和电一样方便。提到云计算时，大家可能更多会想到计算相关的云产品，比如云主机ECS、关系型数据库RDS、大数据处理平台ODPS，但其实负载均衡在云计算里面的地位是至关重要的，因为它是网络流量的入口。互联网时代，计算资源、服务器、手机、电脑、物联网设备需要网络去连在一起。云计算时代，分布式计算往往意味着一个集群里面有很多计算节点，怎么保证服务的请求会均匀分布在计算节点上面同时对外提供服务呢？这是负载均衡需要解决的一个课题。

云上的“双十一”

2015年的“双十一”第一次有阿里云参与进来，是云上的“双十一”。“双十一”的阿里云主要有以下几个部分：阿里云三大件，即云服务器、负载均衡、RDS云数据库，这三大件是云计算的基础组件。

SLB负载均衡的“双十一”提出了很多问题：如何实现快速部署？如何提供足够的性能？如何提供高可用的服务？如何提供足够的容量？

负载均衡简介

负载均衡是指通过某种负载分担技术，将外部发送来的请求均匀分配到对称结构中的某一台服务器上，而接收到请求的服务器独立地回应客户的请求。通俗的讲，就是当访问请求变多时，需要更多的服务器来响应请求、对外提供服务，这时候需要有一个负载均衡器通过一定规则把请求分发在多台服务器上，横向拓展了服务的性能。负载均衡可以通过硬件或者软件来实现，传统的负载均衡还可以通过DNS实现，但是DNS的时效性不好。

硬件负载均衡器是一个重要的角色。十年以前，负载均衡大部分是由负载均衡器来实现的，最出名的厂商是F5。负载均衡器的优点是：有专门的团队来提供开发和维护，性能比较好，相对软件负载均衡稳定可靠些。缺点是：费用昂贵，难以拓展功能和容量，灵活性差。

软件负载均衡

LVS（Linux Virtual Server）跑在网络层的第四层，TCP或者UDP这一层，它是开源的，已集成在Linux内核中，其可伸缩，可以弹性部署，非常可靠。

Nginx跑在7层网络上面，它是轻量级的Web服务器，优势在于它有很好的网络适应性，只要后端的路由器可以连通就可以通过Nginx做HTTP的负载均衡，它支持URL、正则表达式等高级逻辑，同样是开源的。

SLB其实就是基于前面介绍的LVS和Nginx来实现的，分为四层负载均衡和七层负载均衡。如图所示，访问流量会经过公网的入口，进入某个可用区，每个可用区又会有多个机房，每个机房又会有一个LVS的集群和一个Tengine的集群来实现四层负载均衡和七层负载均衡。

负载均衡技术已经作为了全集团的流量入口。第一，它是弹性计算的流量入口，服务阿里云的公有云用户，涵盖了大中小型网站、游戏客户、APP服务端，还有专有云，包括金融和政府部门。第二个服务的对象是云产品，比如RDS、OSS、高防等都用到了SLB的负载均衡技术，提供云计算服务的流量入口。第三，为集团VIP统一接入平台提供负载均衡服务作为电商平台的流量入口。第四，蚂蚁金服使用负载均衡服务作为支付宝、网上银行交易平台的流量入口。

高性能的负载均衡

如何对负载均衡进行高性能的优化？首先是FULLNAT技术，它是LVS的一个转发模式，此优化的目的是为了摆脱开源LVS对网络部署的限制；另外的一个优化点是二层转发，LVS是Linux内核里面的一个模块，需要经过Linux传统的协议栈，性能非常低，二层转发可以通过记录MAC地址绕过Linux路由表，提升性能；第三个比较大的优化是CPU的并行化，可以让每个 CPU 并行的处理报文的转发；第四个优化是FASTPATH，完全旁路了Linux协议栈，直接将报文送到网卡，性能达到硬件线速；第五个优化是CPU指令的优化，由于FULLNAT需要对报文做一些修改，我们使用CPU专门对Crc32定制的计算指令会大大优化计算校验的性能；最后一个优化点充分利用了现在服务器NUMA的特性，NUMA是计算机的一种架构，在不同的CPU上面访问特定内存或者系统资源会比较快，通过NUMA的特性来分配本地内存可以达到很大的性能提升。

FULLNAT优化

CPU并行化

控制管理的并行化，修改了LVS的源码，原生的LVS本地只有一份配置是全局的，每个CPU访问它都要去加锁，我们的优化是在每个CPU上都有全量的转发配置的部署，这样，每个CPU查询自己的资源的时候是不需要上锁的，大大提高了处理的效率。

每个 CPU 在查询连接（session） 时，也是并行处理，大大提高了转发性能。

当CPU分开工作时，怎么保证同一条流的入方向和出方向都落在同一个CPU上呢？之前提到的FULLNAT有两条流，一条是client访问vip，另一条是从RS访问local地址，这两条流采用了硬件的两个特性来保证他们落在同一个CPU上，client -> vip这条流采用了硬件的RSS技术，通过哈希自动选择CPU，通过网卡队列CPU中断的绑定使得关系固定下来，当它处理完发送到后端后，RS ->
localaddr回来的入包的源地址是后端的服务器，目的地址是本地地址，此时通过 flow-director 特性对本地地址设置规则来保证分流的效果，即入包和出包的规则一致，
命中同一个 CPU 进行处理。

FASTPATH优化

只经过网卡层和驱动层，大大提升报文的转发性能。

高可用的负载均衡

连接级的高可用通过Session同步来实现，LVS上面每一条转发的连接都会用Session来记录原地址、目的地址等相关信息，每台LVS上面都可以获得其他LVS上面的Session，这样当一台LVS宕机之后，其流量就会分配到其他LVS上面；第二个优化是单机高可用，每台LVS有两个物理网口，双上联了一台交换机，从网络路径上提供了一个冗余，每台交换机上面的路由器也有vip优先级，当一台路由器故障时它会根据优先级切换到另外一台路由器上，实现单机高可用；第三个优化是集群高可用，即热升级无感知、单机故障无感知、交换机故障无感知；第四个优化是通过主备双SITE、秒级切换实现AZ高可用；第五个优化是安全防护，使用SynProxy防御快速校验TCP的三次握手抵御攻击，减少CPU和内存的损耗；最后一个实现高可用的途径是健康检查，及时剔除异常RS，保证服务高可用。

负载均衡集群的高可用

每个集群可能有4台或者8台LVS作为转发服务器，每台服务器上面会有双网口，分别上联两台交换机，两台交换机又分别上联两台路由器，这样网络路径上的冗余就变得非常大，任意一条路径断掉不影响其性能。

负载均衡AZ的高可用

以杭州集群为例，分为可用区A和可用区B，其上面都有全量的转发规则，我们可以设置某个vip，它的流量只通过路由器1来访问其中的某个集群。当整个的可用区发生故障时，它会秒级的切换到另一个路由器上，它的请求就会落在备用的可用区上面，这样当集群发生大规模故障的时候，vip的可用性不会受到影响。

SLB可用性全景图

首先可以通过DNS这种传统的模式在一个域名下面挂两条以上的vip，其中一条vip放到杭州集群，一条vip放到青岛集群，进到杭州集群的流量也有两个可用区，正常情况下会落到某个可用区上面，而另外的可用区是一个备份，当某个可用区变得不可用时，会在杭州集群内进行切换，实现了AZ的高可用。某一个可用区里面，某一台LVS宕机时，那么其他三台LVS就会提供服务。整体上实现异地多活，同城多活的架构。

展望未来

软件架构：从内核态切换到DPDK架构，转移到用户态做网卡的轮询，报文的转发。

硬件升级：从10G网卡升级到40G网卡，集中硬件资源、缩小集群的数量，配备更快的CPU、更大的内存。

高可用：计划做跨AZ的Session同步，即使AZ之间的切换也让用户无感知，保证原有连接的持续；网络的全链路监控包括区域链路上报文转发的时延、丢包率、重传率等给客户提供更全面的网络质量评估；vip的主动探测帮助客户监控vip是否可用，并且把数据展示给用户；SLA，关于用户使用资源上的限制和保证，做好公有云用户的资源隔离。