分布式服务框架-原理与实践:15---服务降级-学习笔记

2019独角兽企业重金招聘Python工程师标准>>>

下面，我们来学习降级

===

大促或者高峰时，为了保证核心业务的SLA,往往需要停掉一些不太重要的业务，例如商品评论，论坛或者粉丝积分等。

另外一种场景就是某些服务因为某种原因不可用，但是流程不能直接失败，需要本地mock服务端实现，做流程放通。

以图书阅读为例，如果用户登录余额鉴权服务不能正常工作，需要做业务放通，记录消费话单，让用户继续阅读，而不是返回失败！

===

上面2种场景，都使用到了分布式服务框架的一个重要服务治理功能：服务降级。

服务降级主要包括容错降级和屏蔽降级2种模式，下面我们就2种服务降级的策略和设计进行讲解。

15.1 屏蔽降级

在1个应用实例中，服务往往是合理设置的，尽管可以通过线程池隔离等方式保证服务之间的资源隔离，

但是100%的隔离是不现实的。

特别是对缓存，网络IO，磁盘IO，数据库等资源无法隔离，在业务高峰期或者大促时，服务之间往往存在激烈的竞争，导致订购等核心服务运行质量下降，影响系统的稳定运行和客户体验。

 

此时需要对非核心服务做强制降级，不发起远程服务调用，直接返回空，异常或者执行特定的本地逻辑，减少自身对公共资源的消费，把资源释放出来供核心服务使用。

 15.1.1 屏蔽降级的流程

屏蔽降级的全流程如下所示：

略

===

1)运维登录控制台，具备服务治理的全套权限

2)运维人员选择服务降级菜单，在服务降级界面选择屏蔽降级

3)通过服务查询界面选择需要降级的服务，注意服务的分组和版本信息，指定具体的降级策略，返回null,返回指定异常还是执行本地Mock接口实现。

4)服务治理通过服务注册中心客户端SDK，将屏蔽降级指令和相关信息发送到服务注册中心。

5+6),服务注册中心接收到屏蔽降级信息后，以事件的形式分别群发给服务提供者集群和服务消费者集群。

7)服务消费者接收到通知后，获取相关内容，更新本地缓存的服务订阅信息，当发起远程服务调用时，需要与屏蔽降级策略做匹配，如果匹配成功，则执行屏蔽降级策略，不发起远程服务调用。

8)服务提供者集群接收到屏蔽降级事件通知之后，获取相关内容，更新本地的服务发布缓存信息，将对应的服务降级属性修改为屏蔽降级

9)操作成功之后，服务注册中心返回降级成功的应答消息，由服务治理Portral界面展示。

10)运维人员查询服务提供者列表，查看状态

11)服务注册中心返回服务状态位屏蔽降级状态！

===

15.1.2 屏蔽降级的设计实现

通常用于服务运行态治理，开发时不会配置，当外界的触发条件达到某个临界值时，

通过控制台进行人工降级，取值有如下3种:

1)mock=force:return null.

2)mock=force:throw Exception

3)mock=force:execute Bean:<BeanName>

对于第3种降级策略，被执行的spring bean 需要实现服务提供者的接口，代码示例如下：

见文档

===

服务发布模型中，需要支持服务降级属性，配置示例如下：

略

===

屏蔽降级操作是可逆的，当系统压力恢复正常时，可以恢复，一切恢复。

15.2 容错降级

当非核心服务不可用时，可以对故障服务做业务逻辑放通，分布式服务框架的业务放通实际属于容错降级的一种。

容错降级不仅仅只用于业务放通，它也常用于服务提供方在客户端执行容错逻辑，容错逻辑主要包括2种：

1)rpc异常：超时异常，消息解码异常，流控异常，系统拥塞保护异常等

2)service异常:登录校验异常，数据库操作失败异常等。

 

15.2.1 容错降级的工作原理

容错降级与屏蔽降级的主要差异如下：

1)触发条件不同: 容错降级是根据服务调用结果，自动匹配触发的；而屏蔽降级往往是通过人工根据系统运行情况手工操作触发的。

2)作用不同：容错降级是当服务提供者不可用时，让消费者执行业务放通，屏蔽降级的主要目的是将原属于降级服务的资源调配出来供核心业务使用。

3)调用机制不同：一个发起远程过程调用，一个只做本地调用

通常实现在消费端实现！

容错降级的策略如下：

1)mock=fail:throw Exception

2)mock=fail:execute Bean:beanName

通常在开发态就需要指定容错降级的策略

需要指出的是：无论是屏蔽降级还是容错降级，都支持从消费者或者服务提供者2个维度去配置，从消费端配置策略灵活，可以实现差异化降级策略，当然是用起来更麻烦。

 

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

屏蔽降级高于容错降级。

 

15.2.2 运行时容错降级

如果开发态没有指定容错策略，系统上线以后，临时增加容错降级策略，服务框架也需要支持在线动态增加容错降级策略，它的工作流程与屏蔽降级类似，如图所示:

略

 

15.3 业务层降级

在实际业务开发过程中，可能会存在比较复杂的业务放通场景，针对一个流程的执行结果做放通，这种场景由于本地方法调用并不经过分布式服务框架，因为需要业务自己做放通处理。

 

服务降级并不能100%满足所有业务放通场景，对于不满足的特殊场景需要业务自己开发业务层的降级框架。

 

15.4 总结

xxx

基于分布式服务框架的服务降级功能，可以有效的提升线上的服务治理效率，保障服务的SLA,

尽管服务降级更多是为了提升服务线上运行质量，但是它反向对服务的设计和开发也有约束。它要求服务在设计之初就要做如下识别：

1)哪些服务是核心服务

2)哪些服务支持降级，降级策略是什么

===

系统的高效、健康运行仅仅依赖线上服务治理和运维是解决不了的，运维的需求通过分布式服务框架的特性反向映射到设计和开发态，从设计阶段就开始考虑未来如何高效运维，才能在根本上提升服务和产品的质量，这也是矛盾对立和统一的一个具体体现。

 

 

 

 

 

 

 

转载于:https://my.oschina.net/qiangzigege/blog/983527