服务降级方案初步设计

服务降级

在公司负责APP首页的后端服务，因为是首页，如果服务稍微出现一点问题就有领导来找我，近一周内已经找我3次了（虽然不全是因为我的服务有问题导致的，大部分情况下是我依赖的下游服务的问题）。为了首页接口的问题，感觉是时候加入一些服务监控和自动降级的功能了，现记录一下大概的方案设计。

目标

1. 通用
2. 代码侵入性小
3. 与服务主逻辑隔离

粒度

1. 服务级别， sop服务层面， 粒度粗，与逻辑耦合低
2. 方法级别， 自己代码逻辑层面，粒度细，与逻辑耦合高

系统构成

1. 开关 控制程序逻辑是否被调用，可以手动修改，或者自动降级 开关状态 （1） 程序内部的静态变量，对外暴露服务接口修改/外部系统通知变更 （2） Redis/db存储，保存全局状态，分布式环境保证数据一致性，轮询
2. 采样，收集需要监控的方法的执行时间，异常等信息 （1） 基于日志的采样，需要统一被监控方法日志格式 （2） 程序逻辑内采样
3. 自动降级开关触发策略 一定时间内异常超过阈值，程序平均耗时超过阈值等，通知服务开关/修改全局开关位
4. 自动升级 开关关闭时，保留少量请求继续采样，当样本达到要求打开开关