BFE是基于Go语言编写的七层负载均衡开源软件，诞生于2014年。2020年6月，BFE被CNCF（Cloud Native Computing Foundation，云原生计算基金会）接受为“沙盒项目”（Sandbox Project），成为中国第一个网络方向的CNCF开源项目。BFE已经在百度大规模使用多年，每天转发超过万亿的请求；BFE也被度小满、央视网、招商银行、360、用友网络等机构选用。

BFE开源项目的地址：GitHub - bfenetworks/bfe: A modern layer 7 load balancer from baidu

《深入理解BFE》免费版：GitHub - baidu/bfe-book: 《深入理解BFE》（Book for opensource project BFE, in Chinese）

    随着云计算和云原生的发展，七层负载均衡得到了越来越多的关注，这个领域出现了很多不同的解决方案。本文对七层负载均衡的多个主流生态进行了说明和对比。本文也将说明，BFE在安全性、稳定性、研发效率和综合成本等方面都明显优于Nginx，可以完美的取代Nginx。

1. 背景说明：七层负载均衡

    负载均衡技术已经存在超过20年的时间。在发展初期，主要使用网络负载均衡，俗称四层负载均衡。四层负载均衡使用网络层信息（如：服务侧IP地址，TCP或UDP协议，端口号）来区分服务。四层负载均衡的代表性开源项目是LVS。

    随着服务的数量越来越多，仅仅依靠网络层信息来区分服务已经不够用了。尤其对于对外服务来说，协议和端口都是固定的（如：Web服务一般为TCP协议的80和443端口），只能使用服务侧的IP地址来区分服务（如图1所示）。而IPv4地址的资源是非常紧张的。对于一个大型的企业，考虑到多地部署的场景，一个服务还要使用多个IP地址。七层负载均衡成为刚需。

图1 四层负载均衡：基于IP地址来区分服务

七层负载均衡使用应用层信息来区分目标服务。常用的信息是HTTP头部中所包含的Host（如：www.baidu.com）和Path（如：/abc），也可以使用HTTP头部中包含的其它信息（如：Cookie信息）。在使用七层负载均衡的情况下，多个服务可以复用相同的IP地址，七层负载均衡系统会根据不同的应用层信息将请求转发给不同的服务（如图2所示）。

图2 七层负载均衡：基于HTTP头部中的Host来区分服务

2. 七层负载均衡的4大生态

    目前在七层负载均衡领域，存在4大生态（如表1所示）：

(1)Nginx/OpenResty生态

(2)Envoy生态

(3)Go语言生态

(4)Rust语言生态

表1 七层负载均衡的4大生态及代表项目

    Nginx/OpenResty生态是目前势头最大的生态。Nginx本来是一个基于C语言开发的Web Server，后来也被用于作为七层负载均衡。OpenResty是对Nginx的一种扩展，可以利用Lua语言（一种脚本语言，由巴西人发明）对Nginx功能做扩展。Kong和APISIX都是属于这个生态的。

    Envoy是基于C++开发的七层开源软件。最早由美国Lyft公司技术团队开发并开源，后Google加入。目前Envoy已经成为服务网格(Service Mesh)中Sidecar网关的重要候选系统。

    Go语言于2009年由Google发布。由于其在内存管理和并发编程方面的优势，最近10年来获得迅猛的发展。Go语言的基础库中提供了非常好的网络协议栈支持。而业界常见的协议也往往能找到第三方提供的Go语言开源代码库。BFE、Traefik和Tyk都是基于Go语言研发的开源项目。

    Rust语言是一种可以提供更好内存安全性的系统编程语言。Rust语言已经被大量用于系统级的开发场景。Linkerd基于Rust语言开发了七层负载均衡软件。

3.  多生态间的对比

    下面对4个七层负载均衡的生态做一个简单的对比。在表2中列出了5个对比的指标，下面逐一进行说明。

表2 七层负载均衡4大生态的对比

(1) 性能

    在4大生态中，除了Go语言生态，其它3个生态系统的性能都非常高。BFE开源项目的性能问题，我们在下一章专门讨论。

(2) 安全性/稳定性

    众所周知，基于C/C++开发的程序在安全性和稳定性方面有严重的问题。C/C++程序超过50%的问题是由于内存管理造成的。即使对于一个已经超过20年经验的老程序员，也不敢说自己写的C/C++程序完全没有内存方面的问题。缓冲区溢出是C/C++程序在安全方面的重大隐患，著名的OpenSSL开源项目几乎每年都会发现缓冲区溢出导致的漏洞，而由于编程语言本质的问题，这方面的问题是不可能根治的。还有一个关键问题是，C/C++程序无法对于异常进行捕获，在出现异常的情况下，程序直接崩溃。

    Go语言和Rust语言的主要设计目的之一就是为了解决C/C++在内存管理方面存在的问题。Go语言中，内存的分配和释放都由系统来负责；Rust在内存管理方面引入了非常复杂的机制，以保证内存管理的安全性。而且Go语言和Rust语言都可以捕获异常。在内存管理安全性和异常捕获两方面，Go语言和Rust语言都远好于C/C++，它们的程序在安全性和稳定性方面强优于C/C++的程序。

(3) 开发效率

    现在软件的主要成本在于人的成本。硬件越来越便宜，人越来越贵。在七层负载均衡的生态选择方面，开发效率也是重要的考虑因素。

    Go的开发效率远高于C/C++。Go语言的开发效率和Python差不多，大约是C/C++的5倍。

    Rust的开发效率并不高。Rust的学习曲线很陡峭，在内存管理方面的设计成本也比较高。

(4) 开源生态

    Rust语言生态之外的3个生态，开源生态都非常强大。Rust目前使用的人群还比较少，能够使用的第三方开源库的数量也还不够多。尤其是在网络协议栈方面，可用的Rust语言开源库比较少。

(5) 转发延迟

    几个生态的系统，转发延迟都比较小。

    Go语言的系统，由于使用GC（内存垃圾回收）机制，在CPU使用率比较高的情况下，会存在一定比例（如：千分之几）的长尾延迟（可能达到几十毫秒）。对于一般的业务场景，这样的长尾延迟是可以接受的。但是对于少量对延迟敏感的场景（如：实时交易），这样的长尾延迟不可接受。在这种情况下，可以通过超量提供CPU资源的方式来缓解，在CPU使用率比较低的情况下，长尾延迟发生的概率会降低。

    对以上的比较，总结如下：

• 在安全性/稳定性、开发效率方面，Go生态的系统强优于C/C++的系统（Nginx/OpenResty, Envoy）

• 在开发效率和开源生态方面，Go生态优于Rust生态

• Go生态的系统的转发延迟在CPU使用率比较高的场景中会有较多长尾。这方面可以通过超量提供CPU资源的方式来缓解

• 性能方面，Go生态存在明显的劣势。这方面在下一章中将详细讨论。

注：OpenResty是结合了Nginx和Lua的混合方案。通过引入Lua，OpenResty提升了研发效率。但是如果想深入掌握OpenResty，仍然需要对Nginx的底层机制有所了解，部分功能也仍然需要使用C语言来开发。再考虑到C和Lua混合编程的调试难度，开发的难度和成本并没有降低。OpenResty底层所依赖的Nginx也仍然存在C语言程序所固有的安全性和稳定性隐患。

4.  关于BFE性能的说明

    下面，我们将重点说明BFE在性能方面存在的问题，及对这个问题的分析。

    为了简化问题的说明，这里仅将Nginx和BFE进行对比。Envoy和Nginx的性质是类似的。

4.1 BFE和Nginx的性能对比

    精确的性能比较受到很多因素的影响（请求和响应大小，连接复用率等），这里只展示比较粗略的性能对比数据。

(1) 在HTTPS转发场景下

    BFE配合使用RSA硬件加速卡和Nginx纯CPU条件下的性能基本相当，即

BFE(加速卡) ：Nginx(纯CPU) = 1 : 1

注：RSA硬件加速卡是一种比较廉价的硬件。通过引入RSA硬件加速卡，可以很好的解决RSA计算处理开销过大的问题。

(2) 在HTTP转发场景下

    BFE和Nginx的性能有较大的差距。在极端场景(长连接，小响应)下，BFE和Nginx的性能差距达到5倍，即：

BFE ：Nginx =1 : 5

    BFE和Nginx存在的巨大性能差距，主要原因在于：

• Go语言和C语言之间的性能差距

    Go语言相比C语言性能有一定的下降。如果BFE也能做极致优化，我估计性能应该能达到Nginx的70%-80%

• BFE和Nginx在内存拷贝优化方面的差距

    经过近20年的开发，Nginx在内存拷贝方面做了极致的优化。而从保证协议处理一致性的角度考虑，BFE使用了Go官方的标准协议栈，这导致在整个转发处理过程中，内存拷贝的次数较多。

• BFE无法使用CPU亲和性（CPU Affinity）来加速

    Nginx可以利用CPU亲和性，通过“绑核”的方法提升性能（提升空间在20%-30%）。对于BFE来说，只能看到Go的协程，而无法看到底层的线程，所以无法利用CPU亲和性来优化。

注：CPU 亲和性（affinity）是进程要在某个给定的 CPU 上尽量长时间地运行而不被迁移到其他处理器的倾向性（来自 知乎）。

4.2 BFE和Nginx的综合成本对比分析

    上文展示了，在不加密的HTTP转发场景下，BFE和Nginx之间存在着5倍的性能差距。读者一定会问：这么大的性能差距，BFE有什么理由存在呀？！

    下面会对BFE和Nginx的综合成本做一个对比。通过从硬件成本、人力成本、机会成本等3个方面的综合对比，我们会发现：BFE在综合成本上是优于Nginx的。

(1) 场景假设：

    HTTP转发，100万QPS容量

    这个容量已经是中国大型互联网企业的容量规模，中国只有少数企业能够达到这样的规模。当然，这个数值距离百度BFE平台的容量还有很大的差距，百度BFE平台的峰值请求超过千万级QPS。

(2) 硬件成本的对比

    BFE需要50台服务器（注：这是2019年的硬件水平）。Nginx需要10台服务器。BFE方案多用40台服务器。

    使用BFE，硬件成本每年增加92万元（单台服务器购置成本约4万元，按照3年折旧，每台年度折旧为1.3万元；每台服务器在数据中心的上架成本为1万元。增加成本 = 2.3 * 40）

注：七层负载均衡所使用的服务器，需要较好的CPU，而对于内存和硬盘的需求都比较低，所以购置成本较低。

(3) 人力成本的对比

    对于一家具有100万QPS容量的公司，使用Nginx至少需要5名年度综合成本60万元以上的工程师，而使用BFE只需要2名。BFE方案每年节省人力成本180万元以上。

综合以上两方面的对比，BFE方案不仅不多花钱，每年还节省了90万元。下面还有第三个对比：机会成本。

注：以上人力成本的对比还比较保守。首先，60万的年度综合成本很难招聘到合格的工程师；其次，从薪酬水平角度，BFE所需要的Go语言工程师比Nginx所需要的C语言工程师更低。

(4) 机会成本的对比

    和Nginx相比， BFE出现稳定性和安全性问题的概率更低。从百度内部的使用情况来看，线上数千个实例，稳定运行超过7年，线上生产环境从来没有出现过程序崩溃的情况。

    另外，BFE可实现新功能快速交付，和Nginx相比交付周期缩短至¼。在2019年百度春晚红包活动的支持中，在短短的一个月内，在BFE上增加了8000行业务代码，很多刷红包的请求在BFE就直接返回了，大大降低了对于下游服务的压力。

注：机会成本(opportunity cost) 是指企业为从事某项经营活动而放弃另一项经营活动的机会，或利用一定资源获得某种收入时所放弃的另一种收入。另一项经营活动应取得的收益或另一种收入即为正在从事的经营活动的机会成本。通过对机会成本的分析，要求企业在经营中正确选择经营项目，其依据是实际收益必须大于机会成本，从而使有限的资源得到最佳配置。（来自百度百科）

(5) 结论

    BFE的综合成本要优于Nginx

    在以上的对比中，我们选择的是一个流量规模很大的场景。对于流量更小的场景，BFE在硬件成本方面的劣势会变小，BFE的综合优势会更加突出。而且，即使BFE和Nginx的性能差距达到10倍，仍然不会改变以上分析的结论。

    以上的对比结果可能出乎大家的预料。其实这个对比只是在重述一个基本的规律：硬件越来越便宜，人越来越贵，软件交付速度越来越重要。

    以上的对比也能够印证，为什么最近10年来Go语言能够得到如此快速的发展。人和交付速度方面的重要性远远超过了硬件成本。

5.  总结

    本文对七层负载均衡的4大生态进行了说明和对比。

    在安全性、稳定性、研发效率等方面，基于Go语言的BFE都明显优于业界知名的Nginx（基于C语言）和Envoy（基于C++）。

    可能出乎很多人的预料，在综合成本方面，BFE和Nginx（及Envoy）相比也有明显的优势。

    由于篇幅所限，本文并没有展开说明BFE在设计理念方面相对于Nginx的先进之处。Nginx原本是一个Web Server，后来半路出家成为七层负载均衡；而BFE在设计之初，就是作为企业级的七层负载均衡软件来设计的。这方面的内容可以参考以下文章：

• 【视频分享】BFE：企业级七层负载均衡开源软件

• BFE和Nginx有什么差异？- 转发模型的对比