分布式框架设计中的服务降级

业务高峰期，为了保证核心服务，需要停掉一些不太重要的业务，eg 商品评论、论坛或者粉丝积分等

另外一些场景就是某些服务不可用时，又不能直接让整个流程失败就本地Mcok(模拟)实现，做流程放通

eg 用户登录余额鉴权服务不能正常工作，需要做业务放通，记录消费话单允许用户继续访问，而不是返回失败

为了保证以上两种场景的正常服务，服务需要有降级

服务降级主要包括容错降级和屏蔽降级

屏蔽降级：1）throw null 不发起远程调用，直接返回空

         2）throw exception 不发起远程调用，直接抛出指定异常

         3）execute bean 不发起远程调用，直接执行本地模拟接口实现

服务降级是可逆操作，当系统压力恢复到一定值不需要降级服务时，要重新发起远程调用，服务状态改为正常

容错降级：非核心服务不可调用时，可以对故障服务做业务放通，保证主流程不受影响

1）RPC异常：通常指超时、消息解码异常、流控异常、系统拥塞保护异常等

2）Service异常 eg登录校验异常、数据库操作失败异常等

容错降级和屏蔽降级的区别在于：

1）触发条件不同：屏蔽降级往往是人工根据系统的运行，手动设置

                容错降级是根据服务调用返回的结果，结合当前的服务级别，自动匹配触发

2）作用不同：容错降级是服务不可用时，让消费者执行业务放通

            屏蔽降级主要目的是将原属于降级业务的资源调配出来供核心业务使用

3）调用机制不同，一个发起远程服务调用，一个只做本地调用

执行业务放通的Mock接口往往放在消费者端

1）执行业务放通时可能会依赖本地的资源，包括但不限于消费者依赖的服务、数据结构、数据库等资源，这些事消费者私有的，服务提供者不可见，若放到服务提供者，会造成资源依赖，导致系统耦合

2）不同的消费者消费同一个服务时，对失败之后的处理策略存在差异，若都搬到服务提供者的Mock接口，会造成代码臃肿，难以维护

服务降级的优先级是  消费者配置策略>服务提供者配置策略

屏蔽降级高于容错降级

实现服务降级需要考虑几个问题

1）那些服务是核心服务，哪些服务是非核心服务

2）那些服务可以支持降级，那些服务不能支持降级，降级策略是什么

3）除服务降级之外是否存在更复杂的业务放通场景，策略是什么？