查看原文
其他

七层负载均衡应如何选型?

BFE开源项目 BFE开源项目 2024-04-15


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(https://landscape.cncf.io/)中,将七层负载均衡做了两个分类:ServiceProxyAPI 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)健康检查

  1. BFE和Nginx只支持“被动”模式的健康检查

  2. Envoy支持主动、被动和混合模式的健康检查。

  3. Traefik只支持“主动”模式的健康检查。

(3)实例级别负载均衡。这四个系统都支持实例级别负载均衡。

(4)集群级别负载均衡

  1. BFE、Envoy、Traefik都支持集群级别负载均衡。

  2. Nginx不支持集群级别负载均衡(指Nginx的开源版本。OpenResty提供了支持。)

注意:Envoy基于全局及分布式负载均衡策略。

(5)对于转发规则的描述方式

  1. BFE基于条件表达式。(详见《BFE转发表的升级说明》)

  2. Nginx支持域名、Path的前缀匹配、精确匹配和正则表达式匹配(详见《BFE和Nginx有什么差异?- 转发模型的对比》)

  3. Envoy支持基于域名、Path及Header的转发规则

  4. Traefik支持基于请求内容的分流。


5.3 扩展开发能力


    七层负载均衡有较多的定制扩展开发需求。下面从系统扩展开发能力的角度对几个开源项目进行对比。

(1)使用的编程语言

  1. BFE和Traefik都基于Go语言开发。

  2. Nginx使用C语言和Lua语言开发。

  3. 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)内部状态展示

  1. BFE对程序内部状态提供了丰富的展示。

  2. Nginx和Traefik提供的内部状态信息较少。

  3. Envoy也提供了丰富的内部状态展示。

(2)配置热加载

  1. 四个系统都提供配置热加载功能。

  2. Nginx配置生效需重启进程,并中断活跃长连接。

需注意:Nginx商业版支持动态配置,在不重启进程的情况下热加载配置生效;一些基于OpenResty的软件也支持配置热加载。


6. 总结


七层负载均衡是非常重要的基础设施,如何选择,关系重大。


性能并不是唯一的考虑因素,也不存在在任何场景都适用的方案。需要结合使用场景的具体情况,从成本、功能、效率、安全和稳定性等多方面综合考虑。



欢迎关注“BFE开源项目”公众号,获得本项目的更多更新。谢谢!


    点击下方的“阅读原文”,可以提交留言或发表评论。


继续滑动看下一个
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存