重庆小潘seo博客

当前位置:首页 > 重庆网络营销 > 小潘杂谈 >

小潘杂谈

使用负载均衡的常见误区及建议

时间:2020-08-14 14:45:13 作者:重庆seo小潘 来源:
1、优先使用无状态服务 有状态服务和无状态服务,原本是各有优势,并没有明显的优劣之分,但是在大集群、服务化的场景下,无状态服务则更有优势。 因为有状态服务在服务架构较为简单时虽然有易开发,高并发等优势,但随着业务规模的扩大,也会造成异常恢复困

1、优先使用无状态服务

有状态服务和无状态服务,原本是各有优势,并没有明显的优劣之分,但是在大集群、服务化的场景下,无状态服务则更有优势。

因为有状态服务在服务架构较为简单时虽然有易开发,高并发等优势,但随着业务规模的扩大,也会造成异常恢复困难、难以并行扩展等问题。而在这种场景下,无状态服务在服务管理、并行扩展方面有着先天的优势。

一般来讲,使用负载均衡,大多是服务规模较大,业务负载的场景,因此更推荐使用无状态化的服务。

2、忽视健康检查配置!

健康检查是负载均衡服务的重要功能之一,也是服务判断后端节点是否存活的重要标准(很多场景下甚至是唯一标准)。不仅仅会影响到显示的状态,还会影响到用户的服务质量,甚至造成整个服务异常。下面举两个例子:

误区1:健康检查判断异常参数过于敏感,在系统压力较大时错误判断而移除正常的节点,导致剩下节点压力增大,从而继续发出移除操作,直到全部节点移除,系统雪崩。

应对之策:在线上压力较大,偶现超时的场景下,建议采用快速拉起,缓慢宕机的策略。通过适当拉长节点异常宕机时周期,减少错误判断的概率,而在服务正常时快速接入服务,缓解负载。

误区2:健康检查宕机参数设置时间过长,结果在节点宕机时无法快速拉起,在异常时影响到了用户访问。

应对之策:在线上压力较小、健康检查接口响应正常的情况下,可以考虑缩短宕机时间,这样在异常时可以快速移除异常节点,减少对用户的影响。

因此,健康检查参数并没有一个固定的原则,关键还是要看业务本身的特点,以及对业务来说,最重要的是什么:是业务稳定,还是用户体验?

3、接入负载均衡无法保障高可用

有一个常见误区就是认为服务接入负载均衡就算高可用了。而事实上实际服务的高可用性是需要通盘考虑的事情,比如全链路移除单点,服务本身对于异常的处理等。

因此说,接入负载均衡仅仅是保证了接入点的高可用(如果挂单点那接入都不是高可用的),真正要实现高可用还需要全局保证,负载均衡只是构筑服务高可用的一个工具,而不是全部。

4、接入负载均衡后并不会实现业务加速

负载均衡是一个高性能的转发服务,但是对于单次请求来说,无法做到性能加速。

如果你本来的请求要 100ms返回,使用负载均衡之后也不会把你的请求缩短到 10ms。

而且从理论上说,无论任何形式的负载均衡,都只会增长调用链而不是缩短(一些软负载均衡,如 DNS,Service的 Iptables不会增加调用链本身,但是也会加入额外操作)。因此,对于单个请求,结果往往是变慢而不是加速(一般负载均衡服务增加的成本是微乎其微的 ms以内,应用完全感知不到)。

负载均衡对性能的提升,是通过分担负载带来的并行扩展能力从而提升服务的稳定性。而由于业务并行扩展,造成单台压力变小,从而提升服务的整体性能。

另外,由于负载均衡服务往往有更可靠的接入端(BGP网络),更高效的转发设施(专用转发设备和链路),更好的优化,一般性能还是远远优于自己搭建的转发服务。因此很多场景是会有更好的性能表现。