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

1、优先使用无状态服务

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

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

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

2、忽视健康检查配置！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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