1. 问题的提出

负载平衡并不是一个很新的技术方向。硬件状态的负载均衡器至多曾经存在了二十年。在传统的硬件网络负载均衡器中，蕴含了比拟综合的性能。从协定的角度，蕴含了对 TCP、UDP 流量的反对，也蕴含了对 HTTP、HTTPS 等协定的解决。

而在大多数互联网公司中，广泛应用软件状态的负载均衡器，并且基于所解决的协定辨别为两种不同的零碎：
(1) 四层负载平衡，也被称为网络负载平衡，仅用于对 TCP、UDP 流量进行解决。四层负载平衡在转发中次要基于 IP 地址、端口等信息。四层负载平衡的开源软件包含 LVS、DPVS、Katran 等，代表了三种计划：Linux 内核，DPDK，eBPF（Extended Berkeley Packet Filter）。

(2) 七层负载平衡，也被称为利用负载平衡，反对 HTTP、HTTPS、SSL、TLS 等协定的解决。七层负载平衡在转发中能够利用应用层的信息，如 HTTP 的申请头部，而这些信息对四层负载平衡来说是不可见的。七层负载平衡的开源软件包含 Nginx、BFE、Traefik、Envoy、HAProxy 等。

随着对于流量治理需要的晋升，七层负载平衡的重要性越来越高。很多公司都在增强七层负载平衡接入层的建设。而目前这方面的软件计划比拟多，应该如何选型呢？

2. 七层负载平衡的生态

七层负载平衡的性能要比四层负载平衡简单的多，独立研发十分艰难，个别都要依靠于一个弱小的生态能力倒退起来。
目前，在七层负载平衡畛域，有 3 个比拟弱小的生态：

(1) Nginx / OpenResty 生态

Nginx 是一个应用十分宽泛的 Web Server 开源软件，起初也被用做反向代理。通过多年的倒退，在 Nginx 上积攒了大量的性能。为了解决 Nginx 性能开发成本高的问题，由章亦春在 Nginx 上减少了 Lua 执行模块，造成了 OpenResty 的生态。之后有一些软件基于 OpenResty 来开发，如 APISIX。

(2) Envoy 生态

Envoy 最早由 Lyft 公司研发，起初 Google 也加入进来。与 Nginx 相比，Envoy 做了一些调整和优化。Envoy 最早被设计用于 Service Mesh，作为 sidecar 网关。起初也逐渐用于其它七层负载平衡的应用场景。

(3) Go 语言生态

Go 语言具备开发成本低、安全性和稳定性高的特点，并且 Go 语言有大量的开源代码库，这使得一些公司选用 Go 语言来实现七层负载平衡，如：BFE，Traefik, MOSN 等。

3. Service Proxy 和 API Gateway

在 CNCF Landscape 中，将七层负载平衡做了两个分类：Service Proxy 和 API Gateway。

这两个分类的出发点不同。Service Proxy 偏重于流量的转发，API Gateway 偏重于 API 生命周期的治理。从性能的角度，两个分类下的零碎有很多重合的性能，一些软件也同时具备 Service Proxy 和 API Gateway 的性能，软件所属的分类变得含糊。

其实分类没有那么重要，满足本人场景的需要才是更重要的。

4. 七层负载平衡软件选型的因素

4.1 可能的比照维度

在七层负载平衡软件的抉择上，可能思考的因素包含：

(1) 零碎的性能
一个零碎所能出现进去的性能，受到很多因素的影响（版本、环境、配置参数等等）。本文并不打算给出一个性能方面的比拟，大家能够搜寻一下网上给出的一些测试报告。

(2) 零碎所提供的性能
一个七层负载平衡包含了很多的性能。有一些性能是基础性的，如协定反对、健康检查、转发规定形容；有一些性能可能不是必须的，如流量的镜像、执行脚本语言的反对等。具体抉择哪些性能来比拟，要看具体的应用场景。因为篇幅所限，本文只比照了基础性的性能。

(3) 零碎所提供的扩大开发能力
因为七层负载平衡和业务有更严密的分割，扩大开发的需要很大。是否不便和疾速的进行扩大性能的开发，是七层负载平衡选型的重要考察点。

(4) 零碎的安全性和稳定性
七层负载平衡作为网络流量转发的要害零碎，安全性和稳定性是十分重要的因素。对于面向外网接入的场景，七层负载平衡间接面对大量潜在的攻击行为，安全性方面的思考必不可少。

(5) 零碎的可运维性
作为一个继续运行的在线零碎，七层负载平衡应该具备很好的可运维性。这方面可能包含零碎的可观测性和可监控性，可能很好的把握零碎的运行状态，及时发现零碎的异样；也包含在不停机状况下配置的加载能力，冀望可能不影响零碎的失常转发。

4.2 对于几个比照维度的探讨

在以上这些因素中，“性能”是最常被大家拿进去比拟的，仿佛这是最重要的因素。

尽管没有十分主观精确的比照数据，然而大略说来，基于 C 语言开发的 Nginx 和 Envoy 的性能根本是相当的。而它们的性能要比基于 Go 语言开发的 BFE 和 Traefik 要好很多。即便做了一些优化，基于 Go 语言零碎的性能可能只有 C 语言零碎的 1 /2，在某些极其场景下甚至只有 1 /4（须要阐明，目前体现进去的性能差距可能并不是齐全因为编程语言的起因，而是因为程序编写的问题）。

这么看，仿佛基于 Go 语言研发的七层负载平衡齐全没有存在的理由呀？！

在小规模的应用场景下，流量较小，性能差别所引发的服务器老本差别并不大，性能并不是一个决策的关键因素。

在大规模的应用场景下，流量较大，性能差别的确会导致服务器老本上较大的差别。但也须要留神到，在大规模场景下，也会有较多的二次开发需要。在这种状况下，不同编程语言所导致的研发效率和研发老本的差别会凸现进去（Go 语言的研发效率是 C 语言的数倍）。在选型时，须要兼顾“硬件老本”、“人力老本”、研发速度等几方面的因素。

零碎的安全性和稳定性也是须要思考的。对于重要的业务，一次因稳定性问题导致的业务中断可能就会导致重大的经济损失（及商誉损失）。平安方面可能导致的问题同样十分重大，平安问题可能导致系统的解体，也可能导致敏感信息的泄露。这两方面的机会成本可能远大于负载平衡自身的硬件老本。

基于 C 语言开发的零碎在性能方面有相对的劣势，而基于 Go 语言开发的零碎在二次开发老本、研发速度和零碎的安全性、稳定性方面有更大的劣势。而零碎的性能和可运维性须要针对具体的零碎来具体比照。

4.3 小结

在七层负载平衡的 3 大生态间做抉择是十分艰巨的。从老本、效率、平安和稳定性这几个根底指标来看，目前没有任何计划是完满的。鱼和熊掌，不可兼得。到底抉择走哪条路，须要大家依据本人的场景，联合以上多个维度进行综合的思考。

5. 几种开源七层负载平衡软件的比照

上面对一些七层负载开源我的项目进行比照，包含：BFE/Nginx/Envoy/Traefik。

须要阐明的是，因为这些我的项目都在沉闷开发中，信息可能过期或有误，读者可通过这些开源我的项目的官方网站查看最新信息。

5.1 开源我的项目定位

在各开源我的项目的官网上对其定位形容如下。
(1) BFE: BFE 是一个开源的七层负载平衡零碎。
(2) Nginx: Nginx 是 HTTP 服务、反向代理服务、邮件代理服务和通用 TCP/UDP 代理服务。
(3) Envoy: Envoy 是开源的边缘和服务代理，为云原生利用而设计。
(4) Traefik: Traefik 是先进的 HTTP 反向代理和负载平衡。

5.2 性能比照

上面从零碎性能的角度对几个开源我的项目进行比照。
（1）协定反对。这四个零碎都反对 HTTPS 和 HTTP/2, 并打算或正在开发反对 HTTP/3。

（2）健康检查。

• BFE 和 Nginx 只反对“被动”模式的健康检查
• Envoy 反对被动、被动和混合模式的健康检查。
• Traefik 只反对“被动”模式的健康检查。

（3）实例级别负载平衡。这四个零碎都反对实例级别负载平衡。

（4）集群级别负载平衡。

• BFE、Envoy、Traefik 都反对集群级别负载平衡。
• Nginx 不反对集群级别负载平衡（指 Nginx 的开源版本。OpenResty 提供了反对。）
  留神：Envoy 基于全局及分布式负载平衡策略。

（5）对于转发规定的形容形式。

• BFE 基于条件表达式。（详见《BFE 转发表的降级阐明》）
• Nginx 反对域名、Path 的前缀匹配、准确匹配和正则表达式匹配（详见《BFE 和 Nginx 有什么差别？- 转发模型的比照》）
• Envoy 反对基于域名、Path 及 Header 的转发规定
• Traefik 反对基于申请内容的分流。

5.3 扩大开发能力

七层负载平衡有较多的定制扩大开发需要。上面从零碎扩大开发能力的角度对几个开源我的项目进行比照。
（1）应用的编程语言。

• BFE 和 Traefik 都基于 Go 语言开发。
• Nginx 应用 C 语言和 Lua 语言开发。
• Envoy 应用 C ++ 语言开发。

（2）可插拔架构。这四个零碎都应用了可插拔架构。

（3）新性能开发成本。因为编程语言的差异性，BFE 和 Traefik 的开发成本较低，Nginx 和 Envoy 的开发成本较高。

5.4 安全性和稳定性

（1）稳定性。
因为编程语言的差异性，BFE 和 Traefik 能够对异样（在 Go 语言中称为 Panic）进行捕捉解决，从而防止程序的异样完结; 而 Nginx 和 Envoy 无奈对内存等方面的谬误进行捕捉，这些谬误很容易导致程序解体。

（2）安全性
“缓冲区溢出”的威逼是 C 语言程序固有的问题，根本无法彻底解决。Go 语言不存在这方面的问题（注：如果应用 cgo 调用，可能会引入这方面的问题）。Nginx 中所应用的 OpenSSL 是一个经常出现安全性问题的模块，有趣味的敌人能够在百度中搜寻“HeartBleed 破绽”；Envoy 通过应用 BoringSSL 来缓解这方面的问题。

5.5 可运维性

可运维性对于零碎在正式生产环境的应用十分重要。上面从零碎可运维性的角度对几个开源我的项目进行比照。

（1）外部状态展现。

• BFE 对程序外部状态提供了丰盛的展现。
• Nginx 和 Traefik 提供的外部状态信息较少。
• Envoy 也提供了丰盛的外部状态展现。

（2）配置热加载。

• 四个零碎都提供配置热加载性能。
• Nginx 配置失效需重启过程，并中断沉闷长连贯。
  需注意：Nginx 商业版反对动静配置，在不重启过程的状况下热加载配置失效；一些基于 OpenResty 的软件也反对配置热加载。

6. 总结

七层负载平衡是十分重要的基础设施，如何抉择，关系重大。

性能并不是惟一的思考因素，也不存在在任何场景都实用的计划。须要联合应用场景的具体情况，从老本、性能、效率、平安和稳定性等多方面综合思考。