微服务架构—服务降级

1 简介

        什么是服务降级？当服务器压力剧增的状况下，根据实际业务状况及流量，对一些服务和页面有策略的不处理或换种简单的方式处理，从而释放服务器资源以保证核心交易正常运做或高效运做。

        若是仍是不理解，那么能够举个栗子：假如目前有不少人想要给我付钱，但个人服务器除了正在运行支付的服务以外，还有一些其它的服务在运行，好比搜索、定时任务和详情等等。然而这些不重要的服务就占用了JVM的很多内存与CPU资源，为了能把钱都收下来（钱才是目标），我设计了一个动态开关，把这些不重要的服务直接在最外层拒掉，这样处理后的后端处理收钱的服务就有更多的资源来收钱了（收钱速度更快了），这就是一个简单的服务降级的使用场景。

2 使用场景

        服务降级主要用于什么场景呢？当整个微服务架构总体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，咱们能够将一些 不重要 或 不紧急 的服务或任务进行服务的 延迟使用 或 暂停使用。

3 核心设计

3.1 分布式开关

        根据上述需求，咱们能够设置一个分布式开关，用于实现服务的降级，而后集中式管理开关配置信息便可。具体方案以下：

服务降级-分布式开关

3.2 自动降级

• 超时降级 —— 主要配置好超时时间和超时重试次数和机制，并使用异步机制探测恢复状况

• 失败次数降级 —— 主要是一些不稳定的API，当失败调用次数达到必定阀值自动降级，一样要使用异步机制探测回复状况

• 故障降级 —— 如要调用的远程服务挂掉了（网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常），则能够直接降级

• 限流降级 —— 当触发了限流超额时，可使用暂时屏蔽的方式来进行短暂的屏蔽

        当咱们去秒杀或者抢购一些限购商品时，此时可能会由于访问量太大而致使系统崩溃，此时开发者会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案能够是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

3.3 配置中心

        微服务降级的配置信息是集中式的管理，而后经过可视化界面进行友好型的操做。配置中心和应用之间须要网络通讯，所以可能会因网络闪断或网络重启等因素，致使配置推送信息丢失、重启或网络恢复后不能再接受、变动不及时等等状况，所以服务降级的配置中心须要实现如下几点特性，从而尽量的保证配置变动即便达到：

服务降级-配置中心

• 启动主动拉取配置 —— 用于初始化配置（减小第一次定时拉取周期）

• 发布订阅配置 —— 用于实现配置及时变动（能够解决90%左右的配置变动）

• 定时拉取配置 —— 用于解决发布订阅失效或消失丢失的状况（能够解决9%左右的发布订阅失效的消息变动）

• 离线文件缓存配置 —— 用于临时解决重启后链接不上配置中心的问题

• 可编辑式配置文档 —— 用于直接编辑文档的方式来实现配置的定义

• 提供Telnet命令变动配置 —— 用于解决配置中心失效而不能变动配置的常见

3.4 处理策略

        当触发服务降级后，新的交易再次到达时，咱们该如何来处理这些请求呢？从微服务架构全局的视角来看，咱们一般有如下是几种经常使用的降级处理方案：

• 页面降级 —— 可视化界面禁用点击按钮、调整静态页面

• 延迟服务 —— 如定时任务延迟处理、消息入MQ后延迟处理

• 写降级 —— 直接禁止相关写操做的服务请求

• 读降级 —— 直接禁止相关度的服务请求

• 缓存降级 —— 使用缓存方式来降级部分读频繁的服务接口

        针对后端代码层面的降级处理策略，则咱们一般使用如下几种处理措施进行降级处理：

• 抛异常

• 返回NULL

• 调用Mock数据

• 调用Fallback处理逻辑

4 高级特性

        咱们已经为每一个服务都作好了一个降级开关，也已经在线上验证经过了，感受彻底没问题了。
        场景一：某一天，运营搞了一次活动，忽然跑过来讲，如今流量已经快涨到上限了，有没有批量降级全部不重要服务的方式？开发一脸懵逼的看着，这又不是操做DB，哪里有批量操做呀。
        场景二：某一天，运营又搞事了，说咱们等下要搞一个活动，让咱们赶忙提早把不重要的服务都降级了，开发又是一脸懵逼，我怎么知道要降级哪些服务呀。
        反思：服务降级的功能虽然是实现了，但是没有考虑实施时的体验。服务太多，不知道该降级哪些服务，单个操做降级速度太慢……

4.1 分级降级

        当微服务架构发生不一样程度的状况时，咱们能够根据服务的对比而进行选择式舍弃（即丢车保帅的原则），从而进一步保障核心的服务的正常运做。

        若是等线上服务即将发生故障时，才去逐个选择哪些服务该降级、哪些服务不能降级，然而线上有成百上千个服务，则确定是来不及降级就会被拖垮。同时，在大促或秒杀等活动前才去梳理，也是会有很多的工做量，所以建议在开发期就须要架构师或核心开发人员来提早梳理好，是否能降级的初始评估值，便是否能降级的默认值。

        为了便于批量操做微服务架构中服务的降级，咱们能够从全局的角度来创建服务重要程度的评估模型，若是有条件的话，建议可使用 层次分析法（The analytic hierarchy process，简称AHP） 的数学建模模型（或其它模型）来进行定性和定量的评估（确定比架构师直接拍脑壳决定是否降级好不少倍，固然难度和复杂度也会高许多，即你须要一个会数学建模人才），而层次分析法的基本思路是人对一个复杂的决策问题的思惟和判断过程大致上是同样的。

        如下是我的给出的最终评价模型，可做为服务降级的评价参考模型进行设计：

        咱们利用数学建模的方式或架构师直接拍脑壳的方式，结合服务可否降级的优先原则，并根据台风预警（都属于风暴预警）的等级进行参考设计，可将微服务架构的全部服务进行故障风暴等级划分为如下四种：

评估模型：

• 蓝色风暴 —— 表示须要小规模降级非核心服务

• 黄色风暴 —— 表示须要中等规模降级非核心服务

• 橙色风暴 —— 表示须要大规模降级非核心服务

• 红色风暴 —— 表示必须降级全部非核心服务

设计说明：

• 故障严重程度为：蓝色＜黄色＜橙色＜红色

• 建议根据二八原则能够将服务划分为：80%的非核心服务+20%的核心服务

        以上模型只是总体微服务架构的服务降级评估模型，具体大促或秒杀活动时，建议以具体主题为中心进行创建（不一样主题的活动，因其依赖的服务不一样，而使用不一样的进行降级更为合理）。固然模型可使用同一个，但其数据须要有所差别。最好能创建一套模型库，而后实施时只须要输入相关服务便可输出最终降级方案，即输出本次大促或秒杀时，当发生蓝色风暴时须要降级的服务清单、当发生黄色风暴时须要降级的服务清单……

4.2 降级权值

        微服务架构中有服务权值的概念，主要用于负载时的权重选择，一样服务降级权值也是相似，主要用于服务降级选择时的细粒度优先级抉择。全部的服务直接使用以上简单的四级划分方式进行统一处理，显然粒度太粗，或者说出于同一级的多个服务须要降级时的 降级顺序 该如何？甚至我想要人工智能化的 自动降级，又该如何更细粒度的控制？

        基于上述的这些AI化的需求，咱们能够为每个服务分配一个降级权值，从而便于更加智能化的实现服务治理。而其评估的数值，一样也可使用数学模型的方式进行 定性 与 定量 的评估出来，也能够架构师根据经验直接拍脑壳来肯定。