「这是我参与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等之类的监控服务，进行全链路压测，反复调整测试降级开关变化及系统瓶颈变化，做好降级策略固化下来，做出自动化降级策略写成服务。注意把手动控制的降级开关设置为最高级，以防误降的时候没有手段处理。
要是再牛逼点做多项目共建降级，原理也差不多，可以做一个多服务的接入层做降级控制，也可以让多项目共用上一套专项方案的降级工具。
当然这里依赖了外部服务配置系统的可靠性，如果不放心，做一些其他本地缓存策略或者定时推拉配置的方案或服务也行。
以上做好了，基本上服务可用性就基本能接受了。但是系统降级做完事了，可靠性保障也要做起来啊。
#今日份十分钟# 分享了些实践思路，细节的话相信我团的同学在实践过程中都能解决的。