负载均衡出现于上世纪90年代，一开始主要形态为硬件设备[1]。代表性的企业包括F5、A10、Radware等。随着时代的发展，基于硬件设备的解决方案体系结构已经落后，表现为以下方面：购置成本高

从设计的视角BFE的使用如何实现多数据中心流量调度BFE转发表的升级说明如何基于BFE做灰度发布使用BFE如何实现地址透传BFE的扩展开发如何为BFE开发扩展模块为BFE编写扩展插件(1)

编者说明：本文转载自CNCF官网（可通过最下方的“阅读原文”链接访问）和CNCF微信公众号。原文为英文，为了便于读者阅读，这里翻译为中文。英文原文，可以查看CNCF微信公众号。BFE

connection负载均衡策略的算法计算耗时若干Go语言依赖的更新若干Makefile和CI的优化问题修复修复了对内网IP网段判断错误的问题Golang

Nginx对于配置热加载的处理没有那么友好。任何配置内容的修改，都会引起所有配置内容的重新加载，配置热加载的开销较大。而对于Nginx开源版本来说，配置热加载还会导致正在处理中的长连接的中断。5.

对于每个BFE的模块，强烈推荐通过BFE规定的机制，向外暴露足够的内部状态信息。在模块对外暴露内部状态，需要做以下3步：定义状态变量注册显示内部状态的回调函数在代码中插入状态设置逻辑(1)

目录：前言配置灵活是陷阱配置测试是关键配置体验是灵魂最后前言什么是“配置”？百度百科上是这样描述的：“配”——把缺少的补足；“置”——设立。“配置”就是把缺少的补足并且设置好，这是一种从广义角度上的解释，而在不同的专业领域中，“配置”还有着其独特含义。在系统研发领域中，“配置”通常会被理解为那些不需要经过程序编写、系统部署、甚至功能测试，就能快速调整程序处理方式的一种操作。它不但能够简化冗长的系统变更流程，还能让暂时无法确定的事项稍后再做决定。由此可见，“配置”已经在系统研发领域中起着举足轻重的作用，甚至有些组织都已将系统配置的灵活性，作为评判系统先进性的标准之一。听上去似乎没有问题，但凡事得把握一个度，否则可能会引发一场灾难。你是否经常听到过这种声音——“这些功能通过配置就可以实现”。嗯，非常之先进，但我想这恐怕只是用来欺骗外行的把戏而已，这些配置工作不但极其复杂，而且还难以理解。依我来看，那可能并不是配置，而是货真价实的高级编程！配置灵活是陷阱对于优秀的设计人员来说，当拿到一份业务需求时，他们不仅要有拆解功能点的能力，更要有洞察扩展点的能力，这些能力能够增加系统的前瞻性，为系统迭代预留扩展空间，还可间接提高研发交付效率，从而让技术有机会领先业务“半个身位”。不过，掌握这些能力并不是件容易的事，稍不留神就会走火入魔。我见过某些经验老道的设计人员，他们为了追求极致的扩展性，会在业务需求的基础上添砖加瓦，对其进行多重抽象+封装，并将它们提炼为配置，还时不时会对别人宣称其功能配置的灵活性。原本简洁单一的功能，经过他们妙手一挥，转眼间升级为一个功能复杂度和配置困难度也上升了N个台阶的“强大”功能。虽说，在功能上仍然可以满足业务期望，但换来的却是高昂的理解成本及高危的配置风险，其隐蔽性足以让它们成为名副其实的陷阱。更可悲的是，这些陷阱并没有被开发人员所遏制，所谓“既设计，则实现”，有些开发人员只会将自己扮演为一名搬砖工人，并完全按照图纸的设计内容进行盖楼，导致那些享受着配置灵活性的使用者们，在完全不知情的情况下，已埋下了引发生产故障的种子。配置测试是关键想必大家都知道，任何功能在开发完成后，都需要经过测试才可以发布到产线。那么使用已发布的功能进行配置，是否还需要进行测试，估计绝大多数的同学都会认为配置也属于功能的一部分，已经在测试环境验证过了，没有必要再次验证，不会存在问题。但真的如此吗，你可以尝试统计下近年来，因配置问题所引发的产线故障有多少，你会惊奇的发现，它绝对不占少数，而为什么会造成这种现象，主要有两个原因，一是认为配置不是编程，不需要进行测试，二是认为任何功能的测试，都可以在测试环境验证。假如你也这样认为，那估计你也经历过因配置问题所引发的产线故障，如果你还未经历过，那产线故障可能离你已经不远了。造成这样认为的原因，还是由于对配置和编程的定义存在理解混淆，那它们是否有区分标准呢，至今为止我都还没有找到。有人认为修改商品库存是配置，而有人认为创建营销活动才是配置，答案五花八门，但你会发现它们都有共性——不用编写代码的都是配置。你无法否定也无法肯定，但没关系，你并不用纠结是配置还是编程，而更应该关注的是，它们是否都应该被测试。在我的认知世界里，不管是通过配置还是编程，只要是被创造出来的全新事物，就应该被测试，如果因客观因素无法在测试环境进行测试，那就必须在生产环境进行测试。因为创造都存在着不确定性，而测试就是为了发现不确定性，所以说配置测试是关键。配置体验是灵魂配置本身也是一种功能，它同样讲究客户体验。不佳的配置体验，不但会影响使用者的配置效率，错失业务运营的最佳时机，还会导致使用者配置错误，引发产线故障，造成经济损失。所以说优质的配置体验，是检验配置型功能好坏的核心标准。前文有提到过，配置和编程同样都具备创造性，但它们所处的操作环境并不相同。当你在编程时，你完全可以借助优秀的IDE集成开发工具，搭配上强大的开发插件，辅助你及时发现代码语法错误，甚至还能为你完成代码自动补全。但请你回想一下，你所开发过的配置型功能中，是否也拥有类似的辅助能力？恐怕是输入配置信息超长后没有任何提示，但提交后返回一堆无法让人理解的错误信息，或是对输入配置信息没有格式校验，导致功能运行时因获取错误配置信息而出现系统异常。这还不算什么，我还见过更反人类的配置操作。例如：当需要在输入框中输入多个词语时，需要使用者在中间手动补充“逗号”，或是无法在已配置过排序的记录中插入新记录，必须先将尾部记录删除，然后添加新记录，最后再将刚才删除的记录恢复回来。是不是觉得很夸张，其实这都只是凤毛麟角，只有想不到的，没有做不到的。当你身处在这样恶劣的操作环境下，配置不出错可能都有点对不起那位开发人员。因此，缺乏体验的配置就好比失去了灵魂，它将无法提供安全的创造环境及激发使用者的创造灵感。最后作为一名从事技术工作的你，每天的工作必然离不开“配置”和“编程”，它们有相似点也有不同点，你不必非得对它们进行区分，而是可以将它们视为是一种组合，所谓“配置化编程”可能就是这种组合最好的呈现，我相信它可能会成为一种更高级的编程语言。期待同样追求技术的你，可以一起探讨与交流作者简介：信用卡业务领域摸爬滚打10余年，做过运维、干过开发、带过团队，现主要活跃在系统架构演进、通用组件研发、AI产品孵化等领域。BFE开源项目相关文章：稳定才是负载均衡的第一需求【视频分享】BFE：企业级七层负载均衡开源软件欢迎关注“BFE开源项目”微信公众号，获得本项目的更多信息。谢谢！

Nginx就是负载均衡的标准和最佳实践。由于Nginx在安全性、稳定性、研发效率等方面存在的问题，百度于2014年基于Go语言研发了新一代的企业级七层负载均衡开源软件BFE【4】【5】。

“在特定的场景，使用专用系统来替代通用系统”，这是互联网企业不断技术升级的一个基本方法论。通用系统什么都能做，但反过来什么都做不好。通过功能的细分和系统的专业化，专用系统会取得比通用系统更好的效果。

欢迎关注“BFE开源项目”微信公众号，获得本项目的更多信息。谢谢！附1：《万亿级流量转发：BFE核心技术与实现》视频简介附2：KubeCon2021演讲《BFE：企业级七层负载均衡开源软件》

6月份我发表了《为什么BFE可以取代Nginx》，收到大量反馈。为此，我发表了《为什么BFE可以取代Nginx：十问十答》。在这些过程中，我发现关于“什么是负载均衡的核心需求”，大家的认识并不统一。如果说到“什么是负载均衡的第一需求”，大家的意见分歧更大。

条件表达式的机制，在多租户大流量场景下经过了多年的验证，取得了非常好的效果。在上千个租户的情况下，各租户的管理员都可以很好的维护自己的配置，并且对公用转发平台的稳定性没有影响。

这里对于团队的规模，是有前提和假设的，也就是容量达到100万QPS。如果按照百度BFE平台万亿级请求规模（对应千万级QPS）来推断，100万QPS对应的每日请求应该是几百亿到1000亿。

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

环境下在BFE-Ingress处理请求的过程中，根据用户的配置将满足特定条件的请求做重定向处理，即不将请求转发给后端服务，而直接以指定状态码加重定向URL的形式对请求进行响应。BFE-Ingress

AnnotationAwareOrderComparator.sort(this.handlerMappings);

转眼已经到了农历牛年的年尾。过去的一年，在BFE开源项目成员和社区的共同努力下，BFE开源项目获得进一步发展，取得了多个具有里程碑意义的成果。今天，我们就来对BFE开源项目走过的2021年进行一下回顾。

Nginx已经有20年的历史了。对于计算机这样变化如此迅速的领域，一款开源软件能够流行20年，真的已经可以说是奇迹了。Nginx这样的辉煌，和背后的创始人及团队一定有着莫大的关系

扩展插件机制是所有现代化的七层负载均衡开源软件都具有的能力。通过扩展插件机制，可以很方便的为BFE增加新的功能，同时又能保持BFE代码组织的清晰逻辑。

使用场景丰富：支持在如下场景使用对四层负载均衡等四层网关进行性能测试、长稳测试对云上虚拟机的网络性能进行测试对网卡性能、CPU的网络报文处理能力进行测试压测场景下，可作为高性能的HTTP

v1.5.0。该版本包括安全更新，建议您进行升级。功能新增提供了

转发模型的对比》，《BFE转发表的升级说明》。关于多数据中心的流量调度，可查看历史文章《如何实现多数据中心流量调度》。关于BFE

在下面这个配置的例子中，对于属于“example_product”的请求，如果请求的Path前缀为“/header”，则设置名为X-Bfe-Vip的Header，用于向下游服务传递服务端IP地址。{

API完成灰度发布的相关配置。注：本文章中包含多个指向github的链接。可以通过点击左下方的“阅读原文”来访问这些链接。欢迎关注“BFE开源项目”微信公众号，获得本项目的更多更新。谢谢！

应用发布，简单来说就是将已开发完成的系统功能部署到生产环境，并可正常对用户提供服务。传统的应用发布步骤一般采用“三步曲”：第一步：停止应用第二步：更新应用第三步：启动应用那你肯定会问，从停止应用一直到启动应用期间，系统功能是不是无法正常使用？没错。在应用发布过程中，可能会出现页面白屏、访问超时等各种异常，而且一般会持续很久，所以发布时间基本上都集中在凌晨，讲究点的可能就配上一句友好提示“系统正在维护，请稍后访问！”。这种情况大部分都出现在传统行业，原因可能是觉得没有必要，因为：1.传统行业的业务一般都集中的日间，也就是说凌晨基本没有业务，或者非重要业务2.就算凌晨无法使用这些功能，觉得也没关系，第二天再来就是了，客户又不会跑了但真的是这样吗？如今越来越多的传统行业，都在向互联网服务模式转型，其服务主要特点：“全天”不间断为客户提供“优质”的“线上”服务，拆分一下关键词1.“全天”代表着任何时间2.“优质”代表着客户体验3.“线上”代表着线上自助所以说，一个优质的客户服务势必会对服务可用性提出更高的要求，而传统的停机发布不但会对客户造成使用影响，还会变向对企业造成非直接经济损失。例如：客户体验下降导致的客户流失仅此而已？非也！作为曾经也同样是一名运维工程师的我来说，凌晨发布家常便饭，还时不时来一次长达8小时的“长途之旅”，身体就直接被掏空，加上第二天还在“补血”中，还会被各种骚扰电话轰炸，这简直就是一场噩梦。由此可见，应用不停机发布的重要性，通过它可以帮助我们：一是在应用发布过程中线上服务持续可用，提升服务可用性，二是可在白天或是任何时间发布，提升运维人员的机动性。那么我们需要怎么做，才能实现应用不停机发布呢，那接下来就让我们进入正题。01应用不停机发布，从字面上很好理解，就是应用发布过程中服务不中断。但仔细回想一下，原先应用发布过程中，反正服务会中断，那就在应用发布完成后，通过网络屏蔽外部流量的方式，先进行核心或常用功能的内部验证，在确保没有问题后，再解除网络屏蔽，并对外提供服务。那现在呢？应用发布后直接对外？不需要进行内部或小流量验证？想必每个人的答案都有所不同。对此，可以对应用不停机发布能力，简单定义三个成熟度。成熟度成熟度能力成熟度一级应用发布过程服务不中断成熟度二级应用发布过程服务不中断，单应用功能可先进行内部/小流量验证成熟度三级应用发布过程服务不中断，多应用（联动）功能可先进行内部/小流量验证注：不同的成熟度对技术能力的要求会有所不同，建议通过逐步演进的方式来提升成熟度，并在演进过程中对不同的技术能力进行验证，从而不断完善。有人会说蓝绿发布，或有人会说滚动发布，灰度发布就可以实现以上能力。但其实，这些答案并不准确，或者说并不全面，它们虽有交集，但无法涵盖。既然提到发布模式，那我们先来简单比较一下几种发布模式的优缺点。蓝绿发布滚动发布灰度发布资源成本生产等比例资源投入，成本较高基本无需额外资源投入，成本较低基本无需额外资源投入，成本较低回滚时长两套环境直接切换，时长较短根据滚动速率决定，时长较长灰度部分实例回滚，时长适中技术难点资源完全隔离，技术难点较低需制定滚动策略，技术难点适中引入流量路由能力，技术难点较高影响范围影响所有用户，影响面较大影响所有用户，影响面较大影响少量用户，影响面较小注：大部分的技术文章里都会提到，可通过以上任何一种发布模式，做到用户无感知的应用发布，但在实际情况下，并不完全足够，还需要通过一些辅助手段组合在一起才能实现。结合以上发布模式的优缺点，如果你的组织在基础架构技术能力上已经非常成熟，那么灰度发布一定是最佳之选，但如果还处于初级阶段，那可能并不是，而蓝绿发布的资源投入较高，也不是一种非常好的选择。剩下的只有滚动发布，但滚动发布的发布策略会比较复杂，特别在容器环境下，同一应用多个服务实例的滚动策略还需要单独来实现。所以，前期可以选择一种折中的方式，即：单独搭建一套预发验证环境，应用架构需对齐生产环境，但容量方面可以最小化，一般一个应用至少2个服务实例。这样，我们就可以在对生产环境做应用发布前，事先对生产预验证环境进行应用发布，发布后仅对内部用户可见，验证通过后，再对生产环境采用全量应用发布。02应用不停机发布是一项综合性能力，当明确好一种发布模式后，就需要逐步识别会涉及到哪些技术组件，以及明确技术组件在整个解决方案中所担任的职责边界，从而使它们能够相互协同工作。如下列举了一些主要的技术组件：技术组件职责边界应用管理平台主要负责控制整个应用发布流程，以及集成并调度不同的技术组件，协同完成应用不停机发布负载均衡（4层）主要负责服务请求的流量接入，可根据所识别的流量特征，负载分发到不同的负载均衡（7层）负载均衡（7层）主要负责服务请求的流量路由，可根据所识别的流量特征，路由分发到同一应用的不同实例容器/虚拟机平台主要负责容器/虚拟机资源管理，包括容器/虚拟机的创建、更新、销毁等域名解析系统主要负责域名地址管理，包括域名的注册、更新、解析等，以及提供用户访问应用或应用间访问等寻址能力注册中心主要负责服务资源管理，包括服务的注册、更新、注销等，以及提供服务请求方发现服务提供方的能力在明确技术组件后，还需要对技术组件进行合理的架构规划，以适配不同的网络架构要求。本次主要将对负载均衡进行特别说明，一方面它是负责处理流量的核心技术组件，另一方面网络架构的不同，对它的部署架构影响可能也是最大的。在传统的网络架构环境中，出于对网络安全或其他考虑因素，通常会划分出多个不同的网络区域，网络区域间的访问需要通过开设防火墙访问策略才可以进行互通。但这种方式必然会对应用服务间直接进行点对点访问的方式造成影响，主要原因是虚拟机或容器环境中，应用的IP地址可能会发生变化，导致无法提前明确防火墙访问策略。所以，一般都会考虑使用负载均衡（代理模式）来解决这个问题。建议前期优先选择方案三，虽然链路较长会小幅影响性能，但此部署方案相对较为成熟，一方面可以避免流量负载不均的问题，另一方面对于应用的改造成本也会相对较低。注：除网络区域隔离会遇到这种情况外，在某些网络架构中，不同的容器集群间也同样无法访问，所以也同样适用。另外，除必要情况下，也应尽量减少跨网络区域或跨容器集群间的访问，例如：优先容器集群内路由访问，跨网络区域频繁交互的应用服务建议迁移至同一网络区域等。负载均衡通常可以分为4层模式和7层模式，其中4层更关注流量负载，而7层更关注流量路由。一般建议将负载均衡（4层）和负载均衡（7层）进行分层部署，以充分发挥它们的强项。建议前期优先选择方案二，虽然无法实现多容器集群间的全局流量调度，但对于当前可观测性和排障能力还不够健全的组织，通过物理隔离降低运维难度也是一种不错的选择。综上架构决策，最终的全局流量链路大致如下，默认情况下，数据中心间流量隔离，即：单数据中心流量收敛，但可根据实际情况进行选择性放行。03应用不停机发布的基础是服务路由，在这里，我们可以把应用服务分为两种角色，服务请求方或服务提供方，而服务请求方通过不同的寻址方式，最终访问到服务提供方的形式，可以称之为服务路由。服务路由可以分为南北向和东西向。南北向：服务请求方—>负载均衡（4层）—>负载均衡（7层）—>服务提供方东西向：服务请求方—>服务提供方不难发现，其主要区别就是，南北向服务请求方需借助负载均衡（代理模式）访问服务提供方，而东西向服务请求方直接访问服务提供方。注：域名解析结果会缓存在本地，可缓解域名解析服务压力，但缓存时间应根据不同的服务水平进行评估，否则将会延长解析地址切换及故障转移时长。有条件的话建议采用httpdns来解决本地缓存问题。但不管是南北向还是东西向，服务提供方在被访问前，得让服务请求方感知或可见，常见的方式主要有两种，一种是不依赖注册中心的，而另一种则是依赖注册中心的。如果当前应用架构上暂未使用微服务框架，即：不依赖注册中心，服务提供方可以手动或自动将服务在负载均衡上进行服务注册，服务请求方直接调用负载均衡。如果当前应用架构上已经使用微服务框架，即：依赖注册中心，服务提供方可以在注册中心上进行服务注册，服务请求方在注册中心进行服务发现，或者由负载均衡在注册中心进行服务发现，服务请求方直接调用负载均衡。注：在多注册中心的场景下，可通过统一注册中心完成异构注册中心的服务发现另外，我们还会对同一应用的不同服务实例进行分组，分组策略可根据不同的条件来决定，例如：不同环境、不同版本等。假设根据不同环境（预生产环境和生产环境）这个条件，可以把部署在预发验证环境的应用服务分为预发组，把部署在生产环境的应用服务分为线上组。然后通过配置路由策略，下发到负载均衡或应用服务，就可以实现简单的服务路由了。例如：不同分组间默认情况下不允许服务路由，但特殊场景下允许预发组服务路由至线上组。注：若服务请求方是前端页面或客户端，也可以对前端流量也进行分组，例如：根据网络环境，将接入公司WI-FI网络环境的流量识别成预发组04应用不停机发布的核心是应用如何优雅停止，光有服务路由可能还不够，它虽然已经解决了大部分问题，但离成功还差最后一步。前面我们提到过应用发布要做到用户无感知，那如果应用发布过程中出现瞬断或短时间中断，而用户又正好在使用，那算不算用户就感知到了呢？不过，如果你觉得线上服务中断5分钟也可以忍受，那我只能呵呵了。但我相信大部分具备互联网服务模式的头部公司，别说发布一次服务停止5分钟，可能就连5秒钟也无法忍受。那我们先来分析一下为什么会出现瞬断或短时间中断：1.服务请求处理还没完成，应用就被强行停止（例如：运维必备大招之kill

解决方案可以分为数据平面和控制平面。2019年发布的核心转发引擎属于数据平面，本次我们发布了控制平面的核心组件后，用户已经可以使用

Controller支持Kubernetes原生定义的Host规则、Path规则，并利用注解(Annotation)支持了Header规则、Cookie规则，以及多服务之间的负载均衡。

如果数据中心发生了故障（如：接入点1发生了故障，或服务1发生了故障），可以通过改变智能DNS的策略，将2.2.2.2返回给客户端，从而将用户流量从数据中心1中的服务1调度到数据中心2中的服务2。图3

月，是一个中立的云原生终端用户社区，致力于为开发者提供云原生领域的专业资讯，推动中国云原生产业发展，目标成为中国云原生领域最具影响力的开源社区。云原生社区基于成员兴趣创建了多个

基于C语言开发的系统在性能方面有绝对的优势，而基于Go语言开发的系统在二次开发成本、研发速度和系统的安全性、稳定性方面有更大的优势。而系统的功能和可运维性需要针对具体的系统来详细对比。4.3

在云计算时代浪潮下，大规模、高并发的技术架构已成为主流。云计算的高速发展，离不开底层基础设施的创新与改进，传统七层负载均衡架构已无法满足复杂的网络集群。在云时代巨量请求背景下，在网民数量和互联网流量井喷的时点，2012年，百度技术团队推出BFE平台。网上有一个著名的段子：百度一下，测试网络通不通。BFE

在高级规则表中，多条规则之间是有序的。需要将转发给Demo-D1的规则放在前面。在高级规则表中包含默认规则，对于没有命中其它规则的请求将被转发到Demo-E。

Nginx在匹配优先级上做了一定的限制，必须首先匹配Host以确定server，然后在server内匹配location。这个限制在简单的场景下没有问题，但是在比较复杂的场景下可能会制约规则的编写。

BFE核心技术与实现》的海报，也吸引了不少观众扫码预购（关于本书的详细介绍和预购优惠参见下面的文章）。往期文章BFE开源项目，公众号：BFE开源项目《万亿级流量转发

提示：已经在使用BFE的小伙伴，在BFE开源项目的Issue（https://github.com/bfenetworks/bfe/issues/748）中提交使用案例，即可获赠一本。【内容简介】

China大会上分享的内容，欢迎大家批评指正。谢谢。最后，感谢Asta

BFE是百度统一的七层负载均衡接入转发平台。BFE平台从2012年开始建设，截至2020年底，BFE平台每日转发的请求超过万亿，日峰值请求超过1000万QPS，在业界有巨大影响力。2019年7月，BFE的转发引擎对外开源，并于2020年6月被CNCF（云原生计算基金会）接受为“沙盒项目”（Sandbox

End（百度统一前端）的缩写。BFE平台是百度统一的七层负载均衡接入转发平台，该平台从2012年开始建设，截至2020年年底，平台每日转发的请求超过1万亿次，日峰值请求超过1000万QPS。

BFE正式宣布开源了！BFE是什么？想用几句话解释清楚不容易。BFE是百度的统一七层流量转发平台，每天转发流量请求接近1万亿。当你访问百度的时候，很大可能已经在使用BFE的服务了。关于BFE的详细介绍，可以查看