「这是我参与2022首次更文挑战的第11天,活动详情查看:2022首次更文挑战」。
做降级,一样的老套路,先想清楚我们的目标是什么。 “降级”只是动作,不是目标,没有目标的动作容易变形不说,还易跑偏。
“降级”是提高系统可用性的一种手段。之前有同学搞不清楚“可用性”和“可靠性”的差别,拿降级举例来说就是:降级未触发前,可用性和可靠性是一致的;降级一旦触发,可用性不变,可靠性降低。
所以我们的目标是提高系统可用性。做事有个目标感,会身心舒畅很多。
最简单的降级方案: (一分钟)
代码里写一个if(isDegradation){...}else{...},一分钟完事,不要看这个粗糙简陋,事情急迫的时候就这么干。也不要尝试引入外部依赖做开关,特别急迫的情况下任何多余动作都是负担累赘。
紧急但是不那么急迫的方案:(10分钟,外部依赖你要简单测一下吧?)
用我团的MCC或Lion配置平台,配置个开关,结合上边的方案做就是一个基本降级方案了。
有点时间的方案:(两天,要设计数据结构和项目内的埋点吧?)
设计一下配置平台的数据结构,可以提供多种降级策略,把降级开关组合起来。比如:
group:3,1,2; // 按群组降级,优先级是后者覆盖前者
[group] // 降级开关群组定义
1[keyA]=true;
2[keyA]=false;
2[keyB]=true;
3[keyA]=true;
3[keyB]=true;
[single] // 单key降级开关定义
keyA=true;
keyB=false;
[time] // 按时间降级开关定义
key1="2020-04-30 12:00:00~2020-04-30 20:30:00#3000"
以上是样例,就是可以有更多设计,比如把true或false的值变换成数字0~10000区间内的数字,代表按多少比例降级等等,这样做可以尽可能的保障可用性的基础上,再控制一下可靠性的跌幅。
你老板给你做专项时间的方案:(时间一周起吧)
除了上述数据结构设计及项目内埋点以外,需要做到一定自动化,配合一下Lion接口服务和Avatar等之类的监控服务,进行全链路压测,反复调整测试降级开关变化及系统瓶颈变化,做好降级策略固化下来,做出自动化降级策略写成服务。注意把手动控制的降级开关设置为最高级,以防误降的时候没有手段处理。
要是再牛逼点做多项目共建降级,原理也差不多,可以做一个多服务的接入层做降级控制,也可以让多项目共用上一套专项方案的降级工具。
当然这里依赖了外部服务配置系统的可靠性,如果不放心,做一些其他本地缓存策略或者定时推拉配置的方案或服务也行。
以上做好了,基本上服务可用性就基本能接受了。但是系统降级做完事了,可靠性保障也要做起来啊。
#今日份十分钟# 分享了些实践思路,细节的话相信我团的同学在实践过程中都能解决的。