美文网首页
分布式服务框架--第十四章:流量控制

分布式服务框架--第十四章:流量控制

作者: celusing | 来源:发表于2020-11-22 01:08 被阅读0次

    当资源成为瓶颈时,服务框架需要对消费者进行限流,启动流控保护机制。流量控制有多种策略,比较常见的有:针对访问速率的静态流控、针对资源占有的动态流控、针对消费者并发连接数的连接控制和针对并行访问数的并发控制。

    一.静态流控

    静态流控主要是针对客户端访问速率进行控制。

    1.传统静态流控设计方案

    深度截图_选择区域_20201119095552.png

    传统静态流控设计采用安装预分配方案:在软件安装时,根据集群服务节点数和静态流控阈值,计算每个服务节点分摊的QPS(Query Per Second:每秒查询量)阈值,在系统云信时,各个服务节点按照已分配的阈值进行流控,超出流控阈值的请求拒绝访问。
    缺点:
    静态分配方案的最大缺点就是忽略了服务实例的动态变化:

    • 云端服务的弹性伸缩特性,使得服务节点数处于动态变化中。预分配方案行不通。
    • 服务节点宕机,或者有新的服务节点加入,导致服务节点数发生变化,静态分配的QPS需要实时动态调整,否则会导致流控不准。

    2.动态配额分配制

    深度截图_选择区域_20201119105252.png

    其原理是:由服务注册中心以流控周期T为单位,动态推送每个节点分配的流控阈值QPS。当服务节点发生变更时,会出发服务注册中心重新计算每个节点的配额,然后进行推送,这样无论是新增还是减少服务节点数,都能够再下一个流控周期内被识别和处理,这就解决了传统静态分配方案无法适应节点数动态变化的问题。
    分配策略:生产环境中,每台机器或者VM配置可能不同,采用平均分配可能不适合。

    • 一种解决方案:服务注册中心在做配额计算时,根据各个服务节点的性能KPI数据(比如:服务调用平均时延)做加权,进行合理分配,降低流控偏差。
    • 另一种解决方案:配额指标返还和重新申请,每个服务节点根绝自身分配的指标值、处理速率做越策,如果计算结果表明指标还有剩余,则把多余的返回给服务注册中心。对于配额已经使用完的服务节点,重新主动去服务注册中心申请配额,如果连续N次都申请不到新的配额指标,则对新接入的请求消息做流控。

    最后一点就是:结合负载均衡做静态流控,才能实现更精确的调度和控制。消费者根据各服务节点的负载情况做加权路由,性能差的节点路由到的消息更少,由于配额计算也根据负载做了加权调整,最终分配给性能差的节点配额指标也比较少,这样即保证了系统的负载均衡,又实现了配额的更合理分配。

    缺点:

    • 如果流控周期T比较大,服务节点负载变化比较快,服务节点的负载反馈到注册中心,由注册中心统一计算之后再配额均衡,误差较大。
    • 如果流控周期比较小,获取性能KPI数据会有一定的时延,会到之后流控滞后产生误差。
    • 如果采用配额返还的重新申请方式,则会增加交互次数。
    • 扩展性差。

    3.动态配额申请制

    能够解决动态配额分配制的缺点。其工作原理如下:

    1. 系统部署的时候,根据服务节点数和静态流控QPS阈值,拿出一定比例的配额做初始分配,剩余的配额放在配额资源池中。
    2. 哪个服务节点使用完了配额,就主动向服务注册中心申请配额。配额申请策略:如果流控周期位T,则将T分成更小的周期T/N(N位经验值,默认为10),当前的服务节点数位M,则申请的配额为:(总QPS配额-已经分配的QPS配额)/M * T/N
    3. 总的配额如果被申请完,则返回0配额给各个申请配额的服务节点,服务节点对新接入的请求消息进行流控。
      优点:
    • 各个服务节点最清楚自己的负载情况,性鞥KPI数据再本地内存中计算获得,实时性高。
    • 由各个服务节点根据自身负载情况去申请配额,保证性能高的节点有更高的额度,性能差的自然配额就少,这样能够更合理的调配资源,实现流控的准确性。

    二.动态流控

    动态流控的最终目标是为了保命,并不是对流量或者访问速度做精准控制。
    触发动态流控的因子是:资源,资源又分为系统资源和应用资源两大类,根据不同的资源负载情况,动态流控又分为多个级别,每个级别流控系数都不同也就是被拒绝掉的消息比例不同。每个级别都有相应的流控阈值,这个阈值通常支持在线动态调整。

    1.动态流控因子

    动态流控因子包括系统资源和应用资源两大类。
    常用的系统资源包括:

    • 应用进程所在主机/VM的CPU使用率
    • 应用进程所在主机/VM的内存使用率

    常用的应用资源包括:

    • JVM堆内存使用率
    • 消息队列积压率
    • 会话积压率

    具体实现策略是:系统启动时拉起一个管理线程,定时采集应用资源的使用率,并刷新动态流控的应用资源阈值。

    2.分级流控

    通常,动态流控是分级别的,不同级别有不同的流控阈值,系统上线后会提供默认的流控阈值,不同留空因子的流控阈值不同,业务上线之后通常会根据现场的实际情况做阈值调优,因此流控阈值需要支持在线修改和动态生效。
    注意:为了防止系统波动导致的偶发性流控,无论是进入流控状态还是从流控状态恢复,都需要连续采集N次并计算平均值,如果连续N次平均值大于流控阈值,则进入流控状态;同理,只有连续N次资源使用率平均值低于流控阈值,才能脱离流控状态恢复正常。

    三.并发控制

    并发控制针对线程的并发执行数进行控制,它的本质是限制对某个服务或者服务方法过度消费,耗用过多资源而影响其他服务的正常运行。
    并发控制有两种形式:

    • 针对服务提供者的全局控制
    • 针对服务消费者的局部控制

    四.连接控制

    通常分布式服务框架服务提供者和消费者直接此案有长连接私有协议,为了防止因为消费者连接数过多导致服务端负载压力过大,系统需要支持针对连接数进行流控。

    • 服务端连接数流控
    • 消费者连接数流控

    相关文章

      网友评论

          本文标题:分布式服务框架--第十四章:流量控制

          本文链接:https://www.haomeiwen.com/subject/onykiktx.html