流量高峰,突现线上服务可用率降低,排查发现,因其中有几台机器较旧。当时最早申请的一批容器配置较低,缩容时留下几台,当流量达到高峰,这几台容器因负载太高,扛不住压力。
业务部门问题:
当时方案:在治理平台调低这几台机器权重,访问流量就减少了。
但业务说:当他们发现服务可用率降低时,业务请求已受影响,再如此解决,需要时间,这段时间里业务可能已有损失。紧接提出需求:RPC框架有智能负载机制?能及时自动控制服务节点接收到的访问量?
需求合理,也是普遍问题。虽服务治理平台能动态控制线上服务节点接收的访问量,但当业务方发现部分机器负载过高或响应变慢时再调整节点权重,可能已影响线上服务可用率。
当一个服务节点无法支撑现有访问量,会部署多节点组成集群。通过LB将请求分发给该集群下的节点,共同分担请求压力。
负载均衡主要分为:
在一或多台服务器安装LB软件,如LVS、Nginx。
通过硬件设备实现的LB,如F5服务器。
LB算法主要有随机法、轮询法、最小连接法等。刚才介绍的LB主要应用在Web服务,Web服务的域名绑定LB的地址,通过LB将用户请求分发到一个个后端服务。
为啥不通过DNS实现“服务发现”?为啥不采用添加LB设备或TCP/IP四层代理,域名绑定LB设备的IP或四层代理IP的方式?
因为面临问题:
全由RPC框架自身实现,RPC的服务调用者(后文简称为caller)会与“注册中心”下发的所有服务节点建立长连接,在每次发起RPC调用时,caller都会通过配置的负载均衡插件,自主选择一个服务节点,发起RPC调用请求。
LB机制完全由RPC框架自身实现,不依赖任何LB设备,自然不会发生LB设备的单点问题,服务调用方的LB策略也可配,可通过控制权重,对LB进行治理。
咋动态、智能控制线上服务节点所接收到的请求流量?关键就在RPC框架的LB。设计一种自适应LB策略。
caller发起请求时,会通过配置的LB插件,自主选择服务节点。是不是只要调用者知道每个服务节点处理请求的能力,再依次判断要打给它多少流量就行了?
采用打分策略,caller收集与之建立长连接的每个服务节点的指标数据,如:
通过这些指标,计算出一个分数,如总分10分,若CPU负载达70%,就减它 3 分,当然了,具体减几分需要一个结合业务特点的计算策略。
年终考核专业能力、沟通能力和工作态度分别占比30%、30%、40%,我给一个员工评分10、8、8,那他综合分数计算:1030%+830%+8*40%=8.6分。
给服务节点打分一样,为每个指标都设置一个指标权重占比,然后再根据这些指标数据,计算分数。
Q:caller给每个服务节点都打分后,会发送请求,这时我们咋根据分数去控制给每个服务节点发送多少流量呢?
A:配合随机权重的LB策略去控制,通过最终指标分数修改服务节点最终权重。如给一个服务节点8分(满分10分),服务节点权重100,最终权重80(100*80%)。caller发请求时,通过随机权重策略选择服务节点,该节点接收到的流量就是其他正常节点的80%(这里假设其他节点默认权重都100,且指标正常,10分)。
RPC自适应负载均衡示意图:
RPC框架不是依赖一个LB设备或LB服务器来实现LB,而是由RPC框架本身实现,caller可自主选择服务节点,发起服务调用:
自适应LB,通过它,就能根据caller依赖的服务集群中每个节点的自身状态,智能控制发送给每个服务节点的请求流量,防止因某个服务节点负载过高、请求处理过慢而影响到整个服务集群的可用率。
自适应LB关键,就是调用端收集服务端每个节点的指标数据,再根据各方面指标数据计算打分,最后根据每个节点的分数,将更多流量打到分数较高的节点。
Q:常用的LB算法?
A:以Dubbo为例说明
轮询算法、随机算法,编码简单,适用于集群中各节点提供服务能力等同且无状态的场景。两个方法将服务节点性能当成一样,但实际复杂环境,服务节点处能力不一。需要我们有比重地分发请求,于是加入权重属性,即有权重的随机算法、加权轮询算法。
若某服务节点异常,服务处理缓慢。轮询算法、随机算法还会持续将请求发分到服务节点,进一步加重服务节点情况。这是个较大缺点。
最少活跃调用数算法,记录服务节点的活跃数,活跃数越少,表明该provider效率越高,单位时间内可处理更多的请求,可有效改善上面的case。
哈希(又分一般哈希,一致性哈希、加虚拟节点的一致性哈希)。hash一致性算法,适用于服务有状态的的场景,但是实很少需要有状态的场景,该算法比较少使用。
Q:grpc官方并未提供服务发现注册的功能实现,但为不同语言的gRPC代码实现提供可扩展的命名解析和负载均衡接口。
A:基本原理:服务启动后,grpc客户端向命名服务器发名称解析请求,名称会解析为一或多个ip地址,每个ip地址会标识它是服务器地址还是负载均衡地址,以及标识要使用的那个客户端的负载均衡策略或服务配置。客户端实例化负载均衡策略,如解析返回的地址是负载均衡器的地址,则客户端将使用扩展的负载均衡策略,反之客户端使用服务器配置请求的负载均衡策略。负载均衡策略为每个服务器地址创建一个子通道,当有rpc请求时,负载均衡策略决定那个子通道即grpc服务器将接收请求,当可用服务器为空时客户端的请求将被阻塞。
Q:若系统包含一些处理时间较长的请求,如下载一个大数据量报表,这种请求会大大提高该provider平均请求耗时,而发现这种耗时会存在时延,caller仍发送了很多请求到该服务器,这种情况咋看?
A:可考虑背压。
Q:路由策略和负载均衡的结果都是选择一个合适的服务节点,这俩有啥区别?
A:路由一般是规则设定,一般都是路由之后,负载再生效。
Q:心跳检测,我理解是让服务提供方消耗少量的性能,来评估性能并判定是健康还是亚健康。后来说到有个检测服务专门做这件事,然后推给服务调用方。这里又说是caller直接心跳检测。若caller直接调用心跳检测,对caller来说检测及时。但对provider,随caller增多会增加性能损耗,若用注册中心,感知不及时。咋处理较好呢?
A:“冷暖自知”,caller比第三方更准确知道对方的状态。
Q:CPU 核数、CPU 负载以及内存等指标 有什么比较好的获取方式吗?计算每个服务节点的权重 这个是周期性统计计算然后在负载均衡器中更新吗?
A:周期实现起来,最简单,即定时任务。
Q:是不是每个RPC调用方,也就是客户端都存在一个智能LB?那就是每个RPC调用方都能掌握全局的负载信息,要不然无法做LB?其实还是对"负载均衡由RPC框架来做"不理解,这个RPC框架是每个RPC调用方都有一份吗?
A:LB一般都要内置在RPC里,用户也可进行扩展。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。