七层负载均衡应如何选型（）负载均衡开源软件云原生

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）内部状态展示。