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

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。

七层负载均衡应如何选型?_第1张图片

这两个分类的出发点不同。Service Proxy偏重于流量的转发,API Gateway偏重于API生命周期的管理。从功能的角度,两个分类下的系统有很多重合的功能,一些软件也同时具有Service Proxy和API Gateway的功能,软件所属的分类变得模糊。

其实分类没有那么重要,满足自己场景的需求才是更重要的。

七层负载均衡应如何选型?_第2张图片

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)对于转发规则的描述方式。

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. 总结

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

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

你可能感兴趣的:(负载均衡开源软件云原生)