https://github.com/baidu/bfe
BFE（Baidu Front End，百度统一前端）是百度的统一七层流量转发平台。BFE平台目前已覆盖百度大部分产品，每日转发请求接近 1 万亿，峰值 QPS 超过 1000万。在 2019 年百度春晚红包活动中，BFE 平台在超大用户压力、数次流量波峰下平稳运行，保证了春晚红包活动的顺利进行。

从曝光的资料来看，作为综合的流量转发平台，BFE 平台的主要服务包括四大块，分别是：
流量接入和转发：支持HTTP、HTTPS、HTTP/2、QUIC等多种协议，并支持强大的应用层路由能力
流量全局调度：支持由外网流量调度和内网流量调度共同构成的全局流量调度系统
安全和防攻击：支持黑名单封禁、精细限流和应用层防火墙（WAF）等多种防攻击能力
实时数据分析：支持分钟级的超高维度时序报表
作为 BFE 平台的核心组件，BFE 转发引擎从 2012 年开始研发，并于 2014 年使用 Go 语言完成重构。

BFE目前已开源并支持以下重要能力：
1、主流网络协议接入
支持HTTP/HTTPS/SPDY/HTTP2/WebSocket等
支持TLS/HTTP/ WebSocket反向代理模式
2、可扩展插件框架
通过可扩展插件框架，快速定制开发扩展模块，满足业务定制化需求
内置重写、重定向、流量修改、封禁等丰富插件
3、基于请求内容的分流
基于领域专有语言的分流规则，满足复杂业务场景定制化流量转发
支持完备的分流条件原语集，包括基于请求内容（URI/Header/Cookie等）以及请求上下文（IP、协议、标签、时间等）的条件原语。
4、灵活的负载均衡策略
支持集群级别负载均衡及实例级别负载均衡，实现多可用区容灾及过载保护
内置加权轮询、加权最小连接数策略，基于IP或请求内容识别用户实现会话保持

采用 Go 语言重构 BFE，是百度团队在经过与 C、Python 与 Go 的对比之后做出的选择。与前两者相比，Go 具有的特点如下：
性能和 C 接近
并发性
Go routine：屏蔽底层的机制，可以充分利用 CPU 资源
多线程模式：容易思考
开发效率
描述能力与 Python 接近
较丰富的库（系统库，第三方库）
大型程序的组织
package
数据访问的限制（首字母大小写的区别）
可测试能力
内置的单侧和覆盖检查工具，易于做 TDD
go test
错误检查能力
严格的编译阶段检查：强类型，文件包含，…
Panic，便于定位问题
上线和运维
可编译为独立可执行程序

由于基于Go语言，和业界普遍使用的Nginx开源软件相比，BFE具有学习成本、开发成本和性能上等各方面的优势，具体来说包括：
研发效率高：Go语言的开发效率远高于C语言（及Lua），在代码的可维护性方面也有巨大优势。
系统的安全和稳定性高：Go语言没有C语言固有的缓冲区溢出隐患，规避了大量的稳定性和安全风险；另外对于异常可以捕捉，保证程序在快速迭代上线的情况下也不崩溃。

从长期趋势看，基于更高级编程语言的软件系统会逐步取得竞争的优势。CPU等硬件资源的价格仍会快速下降，而开发人力成本、项目研发风险、系统稳定性/安全性方面会成为更重要的决策考虑。从这方面出发，主要基于C语言的Nginx会逐步衰落，而类似BFE这样的基于更高级编程语言的软件会逐步成为主流。

另外，BFE在设计中，还特别增加了企业级应用场景的考虑：
转发场景的直接支持：和Nginx这样从Web Server转型为Proxy的进化路径不同，BFE直接为转发场景设计，从转发模型和转发配置方面更满足转发场景的需求
多租户的支持：在云计算的场景下，多租户复用是普遍的需求。在BFE的设计中，内置提供了多租户的支持
结构化的配置：BFE的配置设计，大量使用JSON这样的结构化方式，便于和相关配置管理系统对接
丰富的监控探针：作为一个工业级软件，在BFE的设计中充分考虑了线上监控的需求，BFE程序通过HTTP方式向外暴露数千个内部状态变量

前提
golang 1.12+
golang yacc
git

下载源代码
BFE代码可以在以下 repo 中找到：
https://github.com/baidu/bfe
克隆主要的BFE repo：
$ mkdir -p gocode/src/github.com/baidu
$ cd gocode/src/github.com/baidu
$ git clone https://github.com/baidu/bfe
$ cd bfe

从源代码创建
在bfe（src / github.com / baidu / bfe）的源目录中运行构建脚本：
$ make
运行测试：

$ make test
BFE二进制文件生成如下：

$ file output/bin/bfe
output/bin/bfe: ELF 64-bit LSB executable …

运行
使用示例配置运行bfe：conf
$ cd output/bin/
$ ./bfe -c ../conf -l ../log

功能性
集群之间的请求路由

在BFE配置中，“产品”可以由多个群集组成。用户可以定义如何在集群之间路由请求。请求路由基于HTTP请求的内容。

规则配置
HTTP标头中的字段用于定义路由规则，以在群集级别分配流量，例如：
主机，路径，查询，cookie，方法等
BFE提供了一个“条件”表达式来定义如何使用特殊标头路由消息。这是群集级别负载平衡中的路由规则。
如果配置了多个规则，则BFE将按顺序匹配这些规则。如果一条规则匹配，则匹配过程停止。

例子
一个产品“demo”需要处理三种流量：静态内容流量，“后”流量，其他流量，据此我们可以定义三个集群：
静态演示：提供静态内容
demo-post：发表留言
demo-main：服务其他流量
在BFE配置中，可以添加以下路由规则：
规则1：req_path_prefix_in（“ / static”，false）-> demo-static，这意味着路径前缀为“ / static”的消息将被路由到集群demo-static。
规则2：req_method_in（“ POST”）&& req_path_prefix_in（“ / setting”，false）-> demo-post，这意味着使用方法“ POST”并以“ / setting”为前缀的消息将被路由到集群“ demo-发布”。
规则3：默认-> demo-main，这意味着所有与上述规则不匹配的消息都将发送到集群“ demo-main”。

子集群级别的负载平衡
在子集群级别，也可以配置负载平衡规则。规则定义了分配给每个子群集的流量权重。
可以使用特殊的虚拟子群集“ BLACKHOLE”来丢弃流量。

例子
考虑以下配置：
两个IDC：IDC1，IDC2
两个BFE集群：BFE1，BFE2
两个后端子集群：sub-cluster-1，sub-cluster-2
在BFE群集（BFE1和BFE2）中：
BFE1：{sub-cluster-1：w11，sub-cluster-2：w12，Blackhole：w1B}
BFE2：{sub-cluster-1：w21，sub-cluster-2：w22，Blackhole：w2B}
根据配置的权重，BFE将流量分配到后端子群集。
例如，如果权重配置{w11，w12，w1B} = {45，45，10}，则到子集群的流量百分比是sub-cluster-1，sub-cluster-2和Blackhole分别是45％，45％和10 ％。
实例级别的负载平衡
通常，子群集由多个实例组成。在子群集中，WRR（加权轮询）用于在实例之间分发消息。
实例可以根据其容量分配不同的权重。
实例的状况检查
BFE对每个后端实例进行运行状况检查。实例具有以下两种状态：
正常状态：实例正常处理消息。
正在检查状态：实例异常，无法处理消息。BFE在这种状态下会定期进行健康检查。
状态转换：
在以下情况下正常进行检查：
在连接或向实例发送消息时连续失败超过阈值。
在以下情况下检查为正常：
BFE从后端实例收到正确的健康检查请求响应。

消息重试失败

如果消息路由失败，则BFE支持分两个级别重试消息：
在同一子群集内重新路由消息。
将消息重新路由到其他子群集。

连接池

BFE与后端实例之间的TCP连接支持：
短期连接：BFE使用新建立的TCP连接将每个请求消息路由到后端服务器。
连接池：
BFE维护到实例的连接池。
对传入的请求：
如果有可用的连接，请重新使用它。
否则建立一个新的TCP连接。
通过连接完成请求处理后：
如果连接池的当前大小小于配置的数目，则将连接添加到该池中。
否则，直接关闭连接。
会话粘性

BFE支持会话粘性基于请求消息的以下标识：
源IP
请求标头，Cookie等中的字段
将会话保持在不同的路由级别：
子群集级别：会话的消息发送到相同的子群集（此子群集中的实例可能不同）。
实例级别：会话消息发送到同一实例。

监测

指标
BFE支持大量的内置指标，可以通过BFE实例的访问监视器端口获取这些指标。
配置
在BFE的配置文件中，设置监视端口：
[服务器]
monitorPort = <端口>

地址
访问以下URL，从运行的BFE实例中获取指标的完整列表：
http://:/monitor

插件
插件模块