2020年6月24日，BFE开源项目被CNCF （Cloud Native Computing Foundation，云原生计算基金会）正式接纳为Sandbox Project。这是百度第一个被CNCF接纳的开源项目，也是在网络方向上中国第一个被CNCF接纳的开源项目。
BFE原名为Baidu Front End（百度统一前端），是百度的统一七层流量转发平台。BFE平台目前已接入百度大部分流量，每日转发请求接近1万亿，峰值QPS超过1000万。在2019年百度春晚红包活动中，BFE平台在超大用户压力、数次流量波峰下平稳运行，保证了春晚红包活动的顺利进行。
作为综合的流量转发平台，BFE平台集成了以下4大功能：
- 流量接入和转发：支持HTTP、HTTPS、HTTP/2、QUIC等多种协议，并支持强大的应用层路由能力
- 流量全局调度：支持由外网流量调度和内网流量调度共同构成的全局流量调度系统
- 安全和防攻击：支持黑名单封禁、精细限流和应用层防火墙（WAF）等多种防攻击能力
- 实时数据分析：支持分钟级的超高维度时序报表
作为BFE平台的核心组件，BFE转发引擎从2012年开始研发，并于2014年使用Go语言完成重构。由于基于Go语言，和业界普遍使用的Nginx开源软件相比，BFE具有以下优势：
- 研发效率高：Go语言的开发效率远高于C语言（及Lua），在代码的可维护性方面也有巨大优势。
- 系统的安全和稳定性高：Go语言没有C语言固有的缓冲区溢出隐患，规避了大量的稳定性和安全风险；另外对于异常可以捕捉，保证程序在快速迭代上线的情况下也不崩溃。
有理由相信，从长期趋势看，基于更高级编程语言的软件系统会逐步取得竞争的优势。
CPU等硬件资源的价格仍会快速下降，而开发人力成本、项目研发风险、系统稳定性/安全性方面会成为更重要的决策考虑。从这方面出发，主要基于C语言的Nginx会逐步衰落，而类似BFE这样的基于更高级编程语言的软件会逐步成为主流。
另外，BFE在设计中，还特别增加了企业级应用场景的考虑：
- 转发场景的直接支持：和Nginx这样从Web Server转型为Proxy的进化路径不同，BFE直接为转发场景设计，从转发模型和转发配置方面更满足转发场景的需求
- 多租户的支持：在云计算的场景下，多租户复用是普遍的需求。在BFE的设计中，内置提供了多租户的支持。
- 结构化的配置：BFE的配置设计，大量使用JSON这样的结构化方式，便于和相关配置管理系统对接
- 丰富的监控探针：作为一个工业级软件，在BFE的设计中充分考虑了线上监控的需求，BFE程序通过HTTP方式向外暴露数千个内部状态变量
为了促进负载均衡技术的交流和发展，BFE的转发引擎于2019年7月正式开源，并获得了广泛的关注。2019年11月19日，BFE开源项目登上GitHub Trending Top 3。2019年12月，BFE开源项目的Github stars超过3000。
BFE开源支持以下重要能力：
1、主流网络协议接入
- 支持HTTP/HTTPS/SPDY/HTTP2/WebSocket等
- 支持TLS/HTTP/ WebSocket反向代理模式
2、可扩展插件框架
- 通过可扩展插件框架，快速定制开发扩展模块，满足业务定制化需求
- 内置重写、重定向、流量修改、封禁等丰富插件
3、基于请求内容的分流
- 基于领域专有语言的分流规则，满足复杂业务场景定制化流量转发
- 支持完备的分流条件原语集，包括基于请求内容（URI/Header/Cookie等）以及请求上下文（IP、协议、标签、时间等）的条件原语。
4、灵活的负载均衡策略
- 支持集群级别负载均衡及实例级别负载均衡，实现多可用区容灾及过载保护
- 内置加权轮询、加权最小连接数策略，基于IP或请求内容识别用户实现会话保持
CNCF是云计算领域全球顶级的开源社区。BFE开源项目在2020年启动了加入CNCF的申请工作。经过一系列的准备工作，于2020年6月18日通过CNCF SIG-NETWORK的答辩，并在不到一周内收到了被CNCF TOC接受的通知。在加入CNCF后，BFE将改名为Beyond Front End。
BFE开源技术已在百度内被HTTPDNS、云加速、BML等产品使用，并将和百度的云原生产品进一步深入结合。BFE商用产品已经被度小满、央视网等客户选用，并已经在多个客户进行了测试验证。BFE将进一步扩大开源范围，加强开源生态的建设，并基于开源建立百度负载均衡的商业生态。
相关材料：
- BFE开源项目：
- CNCF Sandbox Project：
1. 我不太清楚你提keyless的目的是？
2. 对于一个软件的total cost，不能只考虑硬件成本，还需要考虑：
- 研发成本
- 维护成本
综合考虑以上成本，才能得出更加客观的结论。
3. 希望能够就事论事、实事求是的讨论，而不是转移话题。
我们一直在专注的做好BFE技术和产品，也希望大家能够在平等和互相尊重的基础上进行有建设性的交流和讨论。
谢谢！
明白了。非常感谢你的关注和讨论。
1. golang在转发性能上很难与nginx之类的相比
我之前在公开演讲中也多次承认，BFE在性能上和nginx存在差距。
但是nginx的学习成本、维护成本确实要高很多。综合考虑人力成本、机器成本、稳定性和安全风险，nginx不一定是最优的选择。
尤其是在部署规模不大的时候（比如就20个实例，其实对很多公司已经足够了），在人力成本上的投入远超过机器成本的差异。（现在想找一个能精通nginx的开发人员都不是很容易）
2. dpdk目前只适用于4层负载均衡，而不是7层负载均衡。由于协议栈和功能的原因，7层负载均衡的复杂度要高很多。dpdk仅仅降低了收发包的成本，但是无法降低协议处理和业务处理的成本。
3. 关于keyless。bfe早就实现了这方面的能力，而且改造成本比nginx低很多。未来会开源这方面的能力。
7层负载均衡的功能需求仍然在快速增加，在这种情况下，能够快速、稳定、安全的交付功能就成为一个必须要考虑的目标。世界上没有十全十美的方案，应该说在2014年我们就已经做出选择：牺牲部分的性能，以换取更好的研发效率、稳定和安全。从目前的情况看，6年前我们做出的选择是正确的。
我从官网上看的