前言
在微服务架构中，一个用户动作触发的业务功能往往由多个微服务（或叫子系统）共同完成，而这就涉及到了微服务间交互。
一般而言，子系统交互都是通过接口调用完成的，比如一个订单系统，可能涉及几个子系统：（1）用户权限管理子系统：主要管理用户权限，如校验当前用户是否有当前操作权限；（2）库存管理子系统：主要管理库存，如校验当前库存是否充足并进行加减操作；（3）订单管理子系统：主要管理订单内容
用户提交下单请求，订单管理子系统会调用用户权限子系统接口校验当前用户是否有操作权限；然后调用库存管理子系统接口看当前库存是否充足；最后才会生成订单。
即用户权限校验 => 库存校验 => 订单生成
假设，调用过程中，库存管理子系统突然不可用了，那该如何处理呢？业界常用的做法是熔断和降级策略。针对真实的业务场景，此次我们主要讨论降级策略。
背景
在业务处理过程中，由于测试调用权限管理基础服务的接口时进行用户权限校验太过频繁，触发了接口限流机制，从而引发讨论，观点如下：
观点1：建议缓存用户对应的权限，而不要每次都去调用权限管理基础服务接口
观点2：本身用户权限就该是实时查询的，让权限管理基础服务提高接口调用阈值
观点3：可以优先调用接口查并缓存结果，等到触发限流时使用缓存结果，但要考虑数据一致性和可靠性
正在大家争论不休时，专家（架构师）站出来了："大家先不要急，我们一个一个来分析"。
方案
首先是观点1，专家说有点道理，但如果用户此时改变了操作权限，那鉴权是不是就失效了。
其次是观点2，专家说也有点道理，但同样存在一些问题：基础服务是给很多服务提供接口功能的，提高阈值的话万一并发量上来了把服务搞挂了呢。
最后是观点3，专家思考了一会，失声叫道：妙呀！这个思路可以的，同时集成了观点1和观点2的优点，但数据一致性和可靠性确实得好好分析一下，我们可以结合我们自己的业务特点，然后参考业界的降级策略。
降级策略
- 写场景，不做权限性能缓存
- 依赖服务不可用（触发限流）
本服务业务接口调用时
- 优先调用权限校验服务接口进行校验，如果校验成功则返回最新结果并在本地缓存一份数据，并设置过期时间；
- 如果权限校验服务接口调用失败（如触发限流429、服务宕机5XX等）走降级策略
- 降级读取本地缓存数据，如果命中可靠性缓存则返回结果，未命中返回原始接口状态码
- 限流429单独搞错误码和错误消息
过期时间/可靠性缓存TTL：24小时
为解决接口限流的而进行的数据缓存：合理性、数据一致性
