自适应柔性模型

概要陈述

后台服务里面,绕不开的几个主题:容灾、过载保护、柔性。所谓容灾,其实就是备份,逻辑层容灾保障节点故障服务不受中断,数据层容灾保障节点故障数据不至于丢失,读写服务仍可进行。过载保护,本质上则是让自身模块,服务于其能力所在的请求上限,对于服务能力之外的,尽早丢弃,以免引起队列挤压和上层模块雪崩。柔性,是在过载保护之上的一个命题。过载,其实已意味着服务对象受损,是经过筛检丢弃的,而柔性,旨在不影响主逻辑的情况下,以减少一定的逻辑开销,换取吞吐服务能力。某种意义上,它是服务质量受损。以腾讯IM通信为例,在数据下行可能会试图获取昵称,但是当模块过载,可以关闭这个逻辑,把系统资源留给主线逻辑。本文,则重点旨在对柔性做展开陈述,提出一种自适应柔性的框架概念,其在应用中,也得到了实战的验证。

背景:

“弃车保帅”, 是对柔性的一个最形象的描述。但是传统的柔性,一般存在各种缺陷。以下列举三种:

1. 服务柔性的触发机制和时机?面对网络服务的波动性和大型活动等不可控性,请求可能存在毛刺和突发,好点的系统有流水日志,自动化告警监控,但是等人为发现,然后操作配置甚至发布,事件已经过去,服务已受损相当一段时间。人工24小时关注视图是不可能的,这辈子都不可能的了。这留给我们一个问题:是否可能存在一种自动的监控方法?

2. 如何让柔性的代价最小?在实际部署应用中,因为地域园区部署的不均衡、活动源头的汇聚性、服务器自身性能的差异化等要素,带来的问题是,过载可能仅集中在若干几台服务器。而柔性的手段,像是开关、配置下发,往往是全局性的。一刀切的柔性,有损整体体验。这里说的全局性,指代全量服务器生效,全量的请求生效。这留给我们一个问题:是否可能存在一种可能的柔性方式,1)让柔性只在瓶颈服务器上生效;2)让柔性在本机上只生效一部分,换取的系统资源刚刚好能服务于过载的请求量。

局部过载

3. 如何让服务模块联动起来,整体动态调整?传统的柔性往往是自身去降低本模块的服务质量,换取资源利用。是否存在一种可能的方式,把自身过载的信息传递到上游,换取上游降低对其的调用(如果非关键路径和重试的压力),间接地实现柔性的策略。

实现方式:

单机柔性框架

本文尝试提出一种柔性的框架体系,它简单而言可以用上面的模型去描述。对于某一个服务逻辑分支(比如,上面说的IM的拉取昵称),输入(uin)是号段,当然其他服务系统也可以是类似的离散区段的概念,用于对柔性进行分区区别对待(对应的是一刀切柔性);柔性范围(ctrlRange)反映的是柔性的区间,在此区间的号段,是需要启用柔性策略;监控事件(monitorEvent)是对过载事件的监控,他需要传递的信息的当前本服务器是否过载,如果过载,那么他是在持续/恶化(Positive事件),还是在缓和/恢复(Negative事件)。输出是对本次请求的这个行为,是否需要柔性处理(flexibility),比如,不做拉昵称。

1. input,这个不用多说了,视乎系统,可以是号段,也可以是sessionId。

2. monitorEvent,这个是描述系统过载是否发生,且发生的趋势。一般的后台服务框架,都存在类似一套KV存储(KV存储的载体、如何传输到监控系统这些都是开放的),用于监控和上报一些事件。类似于“打点”。那么过载事件的发生,也就可以认为是一种事件,作为打点一种key,value是其发生的次数。其共制的,都是反映的本服务器的过载事件,数据都在本机上有一份,都是能够有手段获取的,可监控到的。

过载保护

像是一般的系统框架,在proxy层负责把包放入channel,worker层负责消费请求包。proxy在插入的时候打上收包时间戳。worker取包处理的时候发现当前时间间隔已过一个阈值,即表示发现队列挤压,需要丢弃该报文。此时可以往KV存储上报这个监控事件发生,过载已发生。当然了,定义过载的手段不局限上述实现方式,也可以是系统CPU使用率等,这个始终要的是一个过载事件的监控体系和KV存储模块。它需要实现的是,秒级的,本机负载的状态监控。

3. ctrlRange,它反馈的是当前,本机上,柔性的号段范围。是一个动态的、弹性伸缩的区间。旨在以最小的服务质量受损代价,换取服务的可用性。

void ModifyCtrlRange(eventValue)
{

        if(IsPosive(eventValue))
{
                
                ctrlRagne += positiveStep;
        
        }else
{
                ctrlRange -= negativeStep;
        }
}
柔性范围与步长关系

总的来说,需要定义一个模型函数(IsPositive),它描述了当前机器,过载是否在持续发生/恶化(Positive事件),又或者是在缓和/恢复(Negative事件),Positive事件发生时,应该逐渐增加柔性的区段范围,Negative事件发生时,应该减少柔性的区间范围。并且整体而言,Positive事件发生时应该迅速启用柔性(斜率大),Negative事件发生时则试探性地收窄柔性区间,缓慢探测回落(这个决策模型函数是开放的,自行定义即可)。

4. flexibility, 决策最后这个请求是否需要执行柔性策略,它的实现逻辑很简单,这里反映出来的特质是,他是一个渐变的区间,不是一个二元的配置。

bool NeedFlexibility(uin)
{
    if(uin%MAX_RANGE < ctrlRange)
        return true;

    else

        return false;

}

正常情况下,柔性的启用会引起负载的下降,而柔性的关闭则带来负载的上涨,因此这里会是一个反馈的过程

柔性调节的反馈机制

在柔性的范围上,反映出来的则是一个动荡收敛的过程:

柔性范围动荡收敛

这里的理念是,始终尝试以最小的服务质量代价,换取可用性。在此期间,试探性“牺牲”一些请求报文,去探测服务是否恢复可用,最后缓慢回落着地。

5. 模型的扩展性,至此,我们讨论的都是如何在单机上做负载的监控、柔性、调整。如何实现上下游节点的级联,让整个系统联动起来。

模块间的自适应柔性

这里的理念还是用的上述的柔性模型,event换成下游是否过载(这个信息可通过过载的模块,在已处理的请求里面,在返回rsp里面把这个信息夹杂着盘带回去上游),而上游柔性的行为,则改为减少对过载模块的调用(如果非关键节点)或者减少重试以减轻对其的负荷。依然的,这套体系符合整个动态柔性调整的模型。

原创声明,本文系作者授权云+社区-专栏发表,未经许可,不得转载。

如有侵权,请联系 zhuanlan_guanli@qq.com 删除。

编辑于

后台系统海量服务

1 篇文章1 人订阅

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏养码场

工作还是游戏?程序员:我选择边玩游戏边工作!

一方面体现在“数据”构造上仍有广阔的待开发空间,另一方面则是应用场景,除了做客观评价和“讲故事”,还需打通更多的商业模式。

591
来自专栏视频直播

世界杯直播技术揭秘及视频云直播回源系统的应用

近些年,视频直播应用蓬勃发展,带宽也是日渐新高,腾讯云旗下的视频云直播为斗鱼、快手、虎牙、龙珠、CNTV广大的企业客户提供了很大的支持,在行业内起到了引领的作用...

752
来自专栏风口上的猪的文章

终于,我也要出一本C#的书了 - 我的写作历程与C#书单推荐

我于2012年3月开始工作,到现在马上就满六年了。这六年里,我从一个连Sql server是什么都不知道,只会写最简单的c#的程序员开始做起,一步一步从一个籍籍...

664
来自专栏祝威廉

数据天生就是流式的

部门目前核心其实就是流式计算,从根部开始(一个超大的Kafka集群)开始,延伸出一个超级庞大的树形结构。整个过程都是数据自我驱动进行流转,没有使用类似Azkab...

634
来自专栏高性能架构

一文看懂DPDK

从我们用户的使用就可以感受到网速一直在提升,而网络技术的发展也从1GE/10GE/25GE/40GE/100GE的演变,从中可以得出单机的网络IO能力必须跟上时...

5809
来自专栏微信公众号:Java团长

成为优秀Java程序员的10个要点

如果你是一个热衷于技术的Java程序员, 那么下面的10个要点可以让你在众多Java开发人员中脱颖而出。

652
来自专栏Flutter入门到实战

关于烂代码的那些事 – 评价代码优劣的方法

秦迪,微博研发中心技术专家,2013 年加入微博,负责微博平台通讯系统的设计和研发、微博平台基础工具的开发和维护,并负责微博平台的架构改进工作,在工作中擅长排查...

682
来自专栏coding

初识vue

765
来自专栏阿杜的世界

持续学习杂谈:总结与反思一、总结与反思二、微服务技术栈

去年在一篇文章中看到:工作后的学习,可以从两个方面着力——大的理论和底层的基础,对于中间的知识点可以放宽一点。可能是我对此理解得不对,按照这个思路,我调整了自己...

612
来自专栏Albert陈凯

2018-08-16 不知道是不是最通俗易懂的《数据一致性》剖析了一、为什么需要分布式系统?二、分布式系统的副作用三、产生数据不一致的原因四、详解一致性五、结语

https://juejin.im/user/5978b281f265da3e292a3d1c/activities

601

扫描关注云+社区