在服务降级what服务压力急剧增加的情况下，根据实际业务状况和流量，不按策略处理某些服务和页面，或者以简单的方式处理，释放服务器资源以保证核心事务的正常执行
如果整个使用场景微服务架构的负载超过预设的上限，或者预计未来的业务将超过预设的阈值，则服务不重要的服务或任务以确保重要或基本服务正常工作
要设计核心分布式交换机，只需设置分布式交换机以实现服务降级，并集中管理交换机配置信息。 具体方案如下：
开关可以在配置中心维护
客户端任务的抽取配置为pull。
主动通知所有客户端配置更改，并更新内存中的配置信息推送。
自动降级超时降级：主要构成超时时间和超时重试次数机制，并使用异步机制检测恢复情况。
失败次数下降：主要是不稳定的API，失败调用次数达到一定阈值时自动下降，同样采用异步机制检测恢复情况。
在要调用的远程服务挂起、网络故障、DNS故障、HTTP服务返回错误的状态代码以及RPC服务抛出异常时，可以直接降级：
如果触发上限值，则限流降级：可以采用临时屏蔽方案执行临时屏蔽。
例如，如果您在秒内杀死或抢购购物限制商品，则访问次数过多可能会导致系统崩溃。 在这种情况下，请使用限制流来限制访问次数。 当达到限制流阈值时，后续请求将被降级。
降级后的解决方案是：提示页面(引导用户进入队列页面，稍后重试)、无商品(错误页面) )如果事件爆发过多，稍后重试)。
服务降低-由于配置中心的配置中心和APP应用程序之间需要网络通信，网络刷新和网络重新启动等因素可能会导致配置推送信息丢失，重新启动和网络恢复后无法接受，也可能会发生变化因此，在服务低下的配置中心中，必须实现以下特性，以尽可能保证配置更改：
启动活动的拉式配置：以初始化配置。 减少第一个定时的拉动周期。
订阅配置：用于实现配置的及时更改。 可以解决约90%的配置更改。
客户端定时抽取配置：用于解决分发订阅过期或丢失而丢失的情况。 可以解决9%左右的订阅到期的邮件更改。
脱机文件缓存配置：用于临时解决重新启动后无法连接到配置中心的问题
可编辑的配置文档：用于以直接编辑文档的方式实现配置定义。
引起处理战略服务降级后，如果新交易再次到达，该如何处理这些请求？
从微服务体系结构的全球角度看，通常有以下几种常见的降级处理方案：
第一部分是手动降级，在代码中写if (xx标志)进行降级逻辑，然后在配置中心配置该值。 需要降级时，修改配置中心的该值进行降级逻辑。
第二部分是自动降级，包括：
1 .超时降级
如果访问的数据库/HTTP服务/远程调用响应缓慢或长时间响应缓慢，且该服务不是核心服务，则可以在超时后自动降级。 使用异步机制检测恢复情况。
例如，商品详细页面有推荐内容/评价，但推荐内容/评价暂时不展示，对用户的购物流程没有很大影响。 这样的服务允许您超时降级。 如果要调用其他人的远程服务，请与对方定义服务响应的最长时间，如果超时，则自动降级。 请注意，在实际场景中，需要设置超时时间、超时重试次数和机制。
2 .统计失败次数降级
调用外部机票服务，在失败时呼叫次数达到一定阈值时，可能依赖不稳定的API，例如自动降级(保险丝)。 然后使用异步线程检测服务是否已恢复，如果已恢复，则解除降级。
3 .故障降级
例如，如果要调用的远程服务瘫痪(网络故障、DNS故障、HTTP服务返回错误的状态代码、RPC服务抛出异常)，则可以继续进行降级。 作为升级后处理方案，缺省值(例如，库存服务锁定时返回默认实物)、驱动数据(例如，在广告锁定时返回若干预先准备的静态页面)、高速缓存
4 .限流降级
如果我们去秒杀或者抢购限购商品，访问量太大，系统可能会崩溃。 在这种情况下，开发人员使用限制流来限制访问次数，当达到限制流阈值时，后续请求将被降级。 降级后的解决方案包括：队列页面(引导用户进入队列页面，等待一段时间后重试)、无商品(错误页面) )如果事件过于爆发，则稍后重试)。
对于后端代码级别的降级处理策略，通常使用抛出异常、返回NULL、调用Mock数据、调用Fallback处理逻辑等处理来执行降级处理
dubbo服务的降级通常运行，在运行失败后再运行相应的mock逻辑
mock=故障：
直接运行相应的mock逻辑
mock=force
将在zk上创建配置器s的子节点
MockClusterInvoker逻辑：
首先获取mock参数
如果未配置，则直接使用FailoverClusterInvoker向提供程序发出请求；
如果配置为以force开头，请直接运行domockinvoke (invocation invocation，RpcExc )
eption e)，不再向provider发送请求；如果配置为以fail开头的，则先使用FailoverClusterInvoker去正常的向provider发出请求，如果失败抛出了非业务异常，则执行doMockInvoke(Invocation invocation, RpcException e)； spring cloud hystrix
将获得的返回结果为：fallback。我们从eureka-client的控制台中，可以看到服务提供方输出了原本要返回的结果，但是由于返回前延迟了5秒，而服务消费方触发了服务请求超时异常，服务消费者就通过HystrixCommand注解中指定的降级逻辑进行执行，因此该请求的结果返回了fallback。这样的机制，对自身服务起到了基础的保护，同时还为异常情况提供了自动的服务降级切换机制。