随着云计算和云原生的发展，七层负载均衡得到了越来越多的关注，同时也出现了很多不同的解决方案。BFE是基于Go语言编写的七层负载均衡开源软件，在2020年6月被CNCF接受为“沙盒项目”，成为中国第一个网络方向的CNCF开源项目。
2022年7月27日，在由开放原子开源基金会主办的“2022开放原子全球开源峰会”上，百度智能云资深研发工程师、BFE开源项目发起人章淼带来了《BFE：企业级七层负载均衡开源软件》的主题演讲。
对于企业来说，流量转发服务实际就是把服务高效地交付给终端用户。
上图展现了百度是如何将BFE用于整个流量转发的，有四道主要的系统。
全局流量调度系统GTC：在网络入口对外网流量进行调度，基于DNS生效；
HTTPDNS：支持移动域名解析；
BGW：四层负载均衡；
BFE：七层负载均衡，支持多机房集群粒度的流量调度。
用软件替代硬件
使用软件替代硬件这件事情在互联网公司已经发生了超过十年的时间，但很多传统的行业还在大量使用硬件设备。当前，硬件所提供的负载均衡功能，可以用软件全部实现，相比之下硬件并不占优势。那软件有什么好处呢？
降低成本；
可快速升级功能；
云原生化，可快速扩缩容。
从系统到服务
现在的企业都在使用开源软件，但并没有形成统一的云化服务。很多企业对于每个独立的业务都搭建了独立的开源软件集群，有的甚至达到上百套，对于这样的庞大数量，该如何有效地做运维成为难题。
为此，我们做了多次实验，最终在内部实现了基于BFE搭建的平台型的服务，实现了从负载均衡系统升级到流量转发服务，同时支持多用户模型，实现资源共享，降低维护成本。
加强七层处理能力
百度非常重视七层处理，很多企业没有统一的七层转发，只有四层，这对流量的控制能力是非常弱的。当前很多流量是加密的，而四层处理无法看到这些流量特征。
通过建立统一的七层负载均衡，能够在企业层面增强流量控制能力、增强数据分析和洞察能力，进而提升整体服务质量。
加强流量调度能力
当前云原生的发展如火如荼，微服务化后，服务的数量会呈爆炸性增长，这就对应用路由的能力提出了更高的要求。此外，当前企业的场景变得越来越复杂，具有多个数据中心、多个容器云集群，那么容器云之间如何进行流量调度是一个非常关键的问题。
BFE是针对与百度类似的复杂企业级场景而设计的，它具有以下四个特点。
稳定是负载均衡的第一需求，但当前很多工程师认为性能是最关键的，我想说这个观点是错误的。与K8s相比，Go语言在安全性、稳定性及研发效率方面具有极大的优势，可以大大降低内存管理的风险、捕捉异常。
BFE具有良好的插件设计，同时Go语言代码具有易于编写和维护的特点，这都利于功能在后期进行快速开发。
BFE内置多租户设计，具有强大的路由转发模型，支持多数据中心调度支持。
写出负载均衡的软件并不难，如何保证7x24小时的高效运维才是难点所在。对此，BFE提供一些系统支持，如内置大量状态探针、支持配置无损动态加载等。
高安全性和稳定性
功能快速开发
复杂场景支持
运维友好支持
BFE的路由转发模型
如上图所示，该场景有三个数据中心，每个数据中心内都有BFE服务（S1）存在，请求的转发共有以下四个步骤。
demo.baidu.com => demo
/static => S1
=> S1-3
=> S1-3_1
Step 1：确定租户（tenant）
Step 2：确定集群（cluster）
Step 3：选择子集群
Step 4：选择实例（instance）
在确定服务或者集群时，BFE也提供了转发机制。
基础转发表针对请求中的Host和Path字段进行匹配，这是一种高效的树型查找；
高级转发表使用BFE独特的条件表达式，相比传统的正则表达式，它的可读性得到了极大的提升。
近年来，七层负载均衡的生态非常繁荣，有四大主流生态。
Nginx /OpenResty生态
OpenResty是对Nginx的一种扩展，可以利用Lua语言对Nginx功能做扩展；
代表项目：
Nginx、OpenResty、Kong、APISIX；
特点：性能高、开源生态强，但稳定性、开发效率、转发延迟较低。
Envoy生态
Envoy是基于C++开发的七层开源软件，已经成为Service Mesh中Sidecar网关的重要候选系统；
代表项目：Envoy；
特点：性能高、开源生态强，但稳定性、开发效率、转发延迟较低。
Go语言生态
代表项目：FFE、Traefik、Tyk；
特点：稳定性、开发效率、开源生态强，但性能、转发延迟低。
Rust语言生态
专注于Service Mesh方向，包含使用Rust语言开发的七层负载均衡软件；
代表项目：Linkerd；
特点：性能、稳定性高，但开发效率、开源生态弱，转发效率低。
Go生态
优势：
相比于Nginx和Envoy，Go生态在安全性、稳定性、研发效率方面都有碾压性优势；
相比于Rust生态，Go生态在开发效率和开源生态方面有明显优势。
劣势：
Go生态在性能和长尾延迟方面有弱点。（注：长尾延迟对于用于一般场景无影响，但阻碍部分场景如实时交易，可以通过增加CPU资源来缓解。）
BFE和Nginx的性能对比
HTTP转发场景 : 极端场景下
BFE : Nginx = 1 : 5
HTTPS转发场景 : BFE配合RSA硬件加速卡
BFE（加速卡）: Nginx（纯CPU）= 1 : 1
综合成本对比分析
场景假设：HTTP转发，100w QPS容量（已是很大规模的企业）
硬件成本对比：
BFE需要50台服务器，Nginx需要10台服务器；
BFE硬件成本每年增加92万元（单台服务器年度折旧为1.3万元，上架成本为1万元，BFE方案多用40台服务器）
人力成本对比：
对于一家具有100w QPS容量的公司，使用Nginx至少需要5名综合成本60万元以上的工程师，而是用BFE只需要2名。这意味着，BFE方案每年节省人力成本180万元以上。
机会成本对比：
和Nginx相比，BFE出现稳定性和安全性问题的概率更低；
BFE可实现功能快速交付，和Nginx相比，交付周期缩短至4%。
结论：BFE的综合成本优于Nginx。
在K8s集群之内，BFE可以作为Ingress，且BFE Ingress已于2021年10月开源发布。
在K8s集群之外，BFE可以作为全局负载均衡器。
BFE控制面已经于2021年10月开源，为用户提供更完整可用的BFE开源产品，具有以下三个组件。
API Server：提供API接口，负责BFE配置的变更、存储和下发；
Dashboard：管理控制台，用于BFE集群的可视化管理；
Conf Agent：配置加载组件，从API Server获取最新配置，触发 BFE 进行配置热加载。
Q：BFE在将来会不会考虑提供WebAssembly插件？
章淼：这是一个很好的问题，明确地说BFE不会支持。Nginx之所以要增加这种支持，原因在于它的底层开发成本太高了。但BFE使用Go语言，开发成本已经足够低，我们并不需要去引入Wasm来降低成本。同时，引入Wasm会带来稳定性降低的风险，这和我们要将稳定性、安全性放在第一位的原则是相悖的。
