热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

服务负载均衡系统设计与实践

认知才是最重

为什么要聊负载均衡系统,因为服务都做了无状态化目的不就是为了扩容缩容吗?没有负载均衡系统怎么做扩容缩容?


负载均衡系统分类

负载均衡系统可以分为两大类:

  1. 硬件负载

  2. 软件负载


硬件负载设备常见的有F5、Array,硬件负载设备的优点在于能够直接通过智能交换机实现,处理能力更强,而且与系统无关,负载性能强更适用于一大堆设备、大访问量、应用简单。但是硬件负载均衡设备成本都比较高,反正到目前为止我没有见过F5。

软件负载均衡常见的有LVS、Nginx、HAProxy,LVS是四层负载,Nginx是七层负载,而HAProxy则同时支持四层或者七层负载。四层负载和七层负载的概念大家可以自行去了解下网络的OSI7层模型,大致上就是四层负载是根据ip和端口号信息进行转发,七层负载就是在四层负载的基础上(一定要记住七层不可能脱离四层单独存在,这是TCP/IP报文处理的机制决定的)再根据url信息或者其它应用关键信息进行转发。

这里还有个概念要给大家解释清楚,我们都说Nginx是个反向代理软件,那什么是反向代理呢?有反向是不是还有正向呢?有的。那怎么去理解呢?先说正向代理,你就理解为当请求某个服务时,如果请求自己能决定请求到服务集群的某个节点,这就叫正向代理。反之,如果这一系列操作是在服务端或者在某个中间件完成的,对请求来说是透明的,这就叫反向代理。


负载均衡算法

负载均衡的算法有很多,我们拿SpringCloud核心组件Ribbon来说,其内置的算法有:

  1. RoundRobinRule:轮询

  2. RandomRule:随机

  3. AvailabilityFilteringRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,以及并发的连接数量超过阈值的服务,然后对剩余的服务列表按照轮询策略进行访问。

  4. WeightedResponseTimeRule: 根据平均响应时间计算所有服务的权重,响应时间越快,服务权重越大,被选中的机率越高。刚启动时,如果统计信息不足,则使用RoundRobinRule策略,等统计信息足够时,会切换到WeightedResponseTimeRule。

  5. RetryRule: 先按照RoundRobinRule的策略获取服务,如果获取服务失败,则在指定时间内会进行重试,获取可用的服务。

  6. BestAvailableRule: 会先过滤掉由于多次访问故障而处于断路器跳闸状态的服务,然后选择一个并发量最小的服务。

  7. ZoneAvoidanceRule: 默认规则,复合判断server所在区域的性能和server的可用性选择服务器。


其实Ribbon的AvailabilityFilteringRule负载均衡算法就支持简单的熔断策略在里面了,只不过熔断是在客户端做的。

那讲到这里咱们负载均衡是不是就讲完了,NO。我们从相对论的角度来分析,以上这些都是狭义上的负载均衡,都不需要我们动脑子,买个设备装个软件学个API就行了。有狭义是不是就有广义?广义上的负载均衡怎么说呢?那就是负载均衡系统嘛,就以上这些是不是顶到天就只算负载均衡设备、软件介绍。


负载均衡系统

什么是负载均衡系统?我们可以这么认为拥有一整套完整的故障处理恢复机制的软硬件结合体就叫负载均衡系统,负载均衡系统应该包括以下特性:

  • 故障自动发现

  • 故障服务自动剔除

  • 故障服务熔断

  • 请求自动重试

  • 服务恢复自动发现


我们还是拿水平分层的架构来分析:

首先我有以下假设:

  • 注册中心使用Zookeeper

  • 网关层有业务逻辑层的服务信息缓存

  • 网关层与业务逻辑层之间保持tcp长连接

  • 网关层有rsp队列


其实Zookeeper不适合做注册中心,因为其是CP模型,而对于服务注册中心来说夸机房出现网络分区的情况下CP模型会导致服务不可用,但是对于服务来说我们要保持高可用,即AP模型,也就是说我宁愿调用一个旧的服务缓存也比直接报错好。Eureka是目前比较合适做服务注册中心的,这个后续再聊,现在我们就假设我们拿Zookeeper做服务注册中心。


故障自动发现

故障自动发现我们要怎么做?即假如我的业务逻辑层1挂了后网关层怎么自动发现。其实很简单,因为我们的业务逻辑层服务起来后都会把name、ip、端口信息注册到Zookeeper,并且会不停的向Zookeeper发送心跳报文,所以我们可以利用Zookeeper的watch机制向网关层更新服务信息。


故障服务自动剔除

服务自动剔除与服务故障自动发现其实同步的,按照故障自动发现的思路来处理就行了。


请求自动重试

请求自动重试也很简单,现在开源的rpc框架(Dubbo、Dubbox、brpc、grpc、RPC Over HTTP)基本上都自带请求超时重试,跟着API来就完事。


服务故障熔断

很多朋友会好奇,为什么我们有了服务自动剔除还需要服务故障熔断。我这里说的服务故障熔断是客户端的服务故障熔断,因为我们业务逻辑层向Zookeeper发送心跳报文肯定不是业务服务线程去做的,对吧?肯定会另外起一个单独的线程去做这个事,那如果服务出现假死,即我们的业务服务线程死循环了或者其他的乱八七糟的故障,但是我们的心跳报文线程是好的,这个时候其实Zookeeper是不会主动向网关层推送故障服务信息的,所以网关层还是会继续请求出现故障的服务,那这个时候怎么办呢?其实很简单,我们可以在网关层维护一个rsp队列,记录1分钟或者5分钟之内(这个时间根据业务实际PV去调整)的请求相应状态,我们可以拿count(失败) + count(超时)/count(失败) + count(超时) + count(正常)算出一个比例,如果超过10%或者20%(这个比例可以根据业务实际PV去调整)那我就在网关层主动剔除服务缓存中对应的服务节点。


服务恢复自动发现

服务怎么自动恢复呢?很简单,重启服务就行了,重启服务后Zookeeper就会重新向网关层推送最新的服务信息。当然如果是物理机直接kill进程再重启,如果是容器我们除了要kill进程还要kill docker和pod。



推荐阅读
  • 本文总结了近年来在实际项目中使用消息中间件的经验和常见问题,旨在为Java初学者和中级开发者提供实用的参考。文章详细介绍了消息中间件在分布式系统中的作用,以及如何通过消息中间件实现高可用性和可扩展性。 ... [详细]
  • 从理想主义者的内心深处萌发的技术信仰,推动了云原生技术在全球范围内的快速发展。本文将带你深入了解阿里巴巴在开源领域的贡献与成就。 ... [详细]
  • RocketMQ在秒杀时的应用
    目录一、RocketMQ是什么二、broker和nameserver2.1Broker2.2NameServer三、MQ在秒杀场景下的应用3.1利用MQ进行异步操作3. ... [详细]
  • 为什么多数程序员难以成为架构师?
    探讨80%的程序员为何难以晋升为架构师,涉及技术深度、经验积累和综合能力等方面。本文将详细解析Tomcat的配置和服务组件,帮助读者理解其内部机制。 ... [详细]
  • Docker安全策略与管理
    本文探讨了Docker的安全挑战、核心安全特性及其管理策略,旨在帮助读者深入理解Docker安全机制,并提供实用的安全管理建议。 ... [详细]
  • 本文介绍了SIP(Session Initiation Protocol,会话发起协议)的基本概念、功能、消息格式及其实现机制。SIP是一种在IP网络上用于建立、管理和终止多媒体通信会话的应用层协议。 ... [详细]
  • 本文总结了一次针对大厂Java研发岗位的面试经历,探讨了面试中常见的问题及其背后的原因,并分享了一些实用的面试准备资料。 ... [详细]
  • 探讨低代码行业发展现状,分析其未能催生大型企业的原因,包括市场需求、技术局限及商业模型等方面。 ... [详细]
  • 华为云HECS:高效能云服务器助力中小企业智能化转型
    华为云凭借其强大的技术创新能力和广泛的服务网络,持续为用户提供高效、稳定、安全的云计算解决方案。本文将深入探讨华为云HECS云服务器如何通过集成智能技术,帮助中小企业实现业务的快速部署与优化。 ... [详细]
  • 电商高并发解决方案详解
    本文以京东为例,详细探讨了电商中常见的高并发解决方案,包括多级缓存和Nginx限流技术,旨在帮助读者更好地理解和应用这些技术。 ... [详细]
  • 本文详细记录了 MIT 6.824 课程中 MapReduce 实验的开发过程,包括环境搭建、实验步骤和具体实现方法。 ... [详细]
  • 在运行于MS SQL Server 2005的.NET 2.0 Web应用中,我偶尔会遇到令人头疼的SQL死锁问题。过去,我们主要通过调整查询来解决这些问题,但这既耗时又不可靠。我希望能找到一种确定性的查询模式,确保从设计上彻底避免SQL死锁。 ... [详细]
  • 阿里面试题解析:分库分表后的无限扩容瓶颈与解决方案
    本文探讨了在分布式系统中,分库分表后的无限扩容问题及其解决方案。通过分析不同阶段的服务架构演变,提出了单元化作为解决数据库连接数过多的有效方法。 ... [详细]
  • Nacos 0.3 数据持久化详解与实践
    本文详细介绍了如何将 Nacos 0.3 的数据持久化到 MySQL 数据库,并提供了具体的步骤和注意事项。 ... [详细]
  • 检查 Kubernetes 系统命名空间中的 Pod 状态时,发现 Metric Server Pod 虽然处于运行状态,但存在异常:日志显示 'it doesn’t contain any IP SANs'。 ... [详细]
author-avatar
许更剑_725
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有