服务发现可用方案
服务发现包含服务消费者（Consumer）和服务提供者（Provider）。
Consumer 端高可用
通过推空保护、服务降级等手段，达到 Consumer 端的容灾目的。
推空保护
可以应对开头讲的案例，服务空列表推送自动降级到缓存数据。
服务消费者（Consumer）会从注册中心上订阅服务提供者（Provider）的实例列表。
当遇到突发情况（例如，可用区断网，Provider端无法上报心跳） 或 注册中心（变配、重启、升降级）出现非预期异常时，都有可能导致订阅异常，影响服务消费者（Consumer）的可用性。
无推空保护
·Provider 端注册失败（比如网络、SDKbug 等原因）
· 注册中心判断 Provider 心跳过期
· Consumer 订阅到空列表，业务中断报错
开启推空保护
· 同上
· Consumer 订阅到空列表，推空保护生效，丢弃变更，保障业务服务可用
开启方式
开启方式比较简单：
开源的客户端 nacos-client 1.4.2 以上版本支持
配置项
· SpingCloudAlibaba 在 spring 配置项里增加：spring.cloud.nacos.discovery.namingPushEmptyProtection=true
· Dubbo 加上 registryUrl 的参数：namingPushEmptyProtection=true
提空保护依赖缓存，所以需要持久化缓存目录，避免重启后丢失，路径为：${user.home}/nacos/naming/${namespaceId}
服务降级
Consumer 端可以根据不同的策略选择是否将某个调用接口降级，起到对业务请求流程的保护（将宝贵的下游 Provider 资源保留给重要的业务 Consumer 使用），保护重要业务的可用性。
服务降级的具体策略，包含返回 Null 值、返回 Exception 异常、返回自定义 JSON 数据和自定义回调。
MSE 微服务治理中心中默认就具备该项高可用能力。
Provider 端高可用
Provider 侧通过注册中心和服务治理提供的容灾保护、离群摘除、无损下线等方案提升可用性。
容灾保护
容灾保护主要用于避免集群在异常流量下出现雪崩的场景。
下面我们来具体看一下：
无容灾保护（默认阈值 =0）
· 突发请求量增加，容量水位较高时，个别 Provider 发生故障；
· 注册中心将故障节点摘除，全量流量会给剩余节点；
· 剩余节点负载变高，大概率也会故障；
· 最后所有节点故障，100% 无法提供服务。
开启容灾保护（阈值=0.6）
· 同上；
· 故障节点数达到保护阈值，流量平摊给所有机器；
· 最终****保障 50% 节点能够提供服务。
容灾保护能力，在紧急情况下，能够保存服务可用性在一定的水平之上，可以说是整体系统的兜底了。
这套方案曾经救过不少业务系统。
离群实例摘除
心跳续约是注册中心感知实例可用性的基本途径。
但是在特定情况下，心跳存续并不能完全等同于服务可用。
因为仍然存在心跳正常，但服务不可用的情况，例如：
· Request 处理的线程池满
· 依赖的 RDS 连接异常或慢 SQL
微服务治理中心提供离群实例摘除
· 基于异常检测的摘除策略：包含网络异常和网络异常 + 业务异常（HTTP 5xx）
· 设置异常阈值、QPS 下限、摘除比例下限
离群实例摘除的能力是一个补充，根据特定接口的调用异常特征，来衡量服务的可用性。
无损下线
无损下线，又叫优雅下线、或者平滑下线，都是一个意思。首先看什么是有损下线：
Provider 实例进行升级过程中，下线后心跳在注册中心存约以及变更生效都有一定的时间，在这个期间 Consumer 端订阅列表仍然没有更新到下线后的版本，如果鲁莽地将 Provider 停止服务，会造成一部分的流量损失。
无损下线有很多不同的解决方案，但侵入性最低的还是服务治理中心默认提供的能力，无感地整合到发布流程中，完成自动执行。免去繁琐的运维脚本逻辑的维护。
配置管理高可用方案
配置管理主要包含配置订阅和配置发布两类操作。
配置管理解决什么问题？
多环境、多机器的配置发布、配置动态实时推送。
基于配置管理做服务高可用
微服务如何基于配置管理做高可用方案？
发布环境管理
一次管理上百台机器、多套环境，如何正确无误地推送、误操作或出现线上问题如何快速回滚，发布过程如何灰度。
业务开关动态推送
功能、活动页面等开关。
容灾降级预案的推送
预置的方案通过推送开启，实时调整流控阈值等。
上图是大促期间配置管理整体高可用解决方案。比如降级非核心业务、功能降级、日志降级、禁用高风险操作。
客户端高可用
配置管理客户端侧同样有容灾方案。
本地目录分为两级，高优先级是容灾目录、低优先级是缓存目录。
缓存目录：每次客户端和配置中心进行数据交互后，会保存最新的配置内容至本地缓存目录中，当服务端不可用状态下，会使用本地缓存目录中内容。
容灾目录：当服务端不可用状态下，可以在本地的容灾目录中手动更新配置内容，客户端会优先加载容灾目录下的内容，模拟服务端变更推送的效果。
简单来说，当配置中心不可用时，优先查看容灾目录的配置，否则使用之前拉取到的缓存。
容灾目录的设计，是因为有时候不一定会有缓存过的配置，或者业务需要紧急覆盖使用新的内容开启一些必要的预案和配置。
整体思路就是，无法发生什么问题，无论如何，都要能够使客户端能够读取到正确的配置，保证微服务的可用性。
服务端高可用
在配置中心侧，主要是针对读、写的限流。限制连接数、限制写：
· 限连接：单机最大连接限流，单客户端 IP 的连接限流
· 限写接口：发布操作&特定配置的秒级分钟级数量限流
控制操作风险
控制人员做配置发布的风险。
配置发布的操作是可灰度、可追溯、可回滚的。
配置灰度
发布历史&回滚
变更对比
动手实践
最后我们一起来做一个实践。
场景取自前面提到的一个高可用方案，在服务提供者所有机器发生注册异常的情况下，看服务消费者在推空保护打开的情况下的表现。
实验架构和思路
上图是本次实践的架构，右侧是一个简单的调用场景，外部流量通过网关接入，这里选择了 MSE 产品矩阵中的云原生网关，依靠它提供的可观测能力，方便我们观察服务调用情况。
网关的下游有 A、B、C 三个应用，支持使用配置管理的方式动态地将调用关系连接起来，后面我们会实践到。
基本思路：
1、部署服务，调整调用关系是网关->A->B->C，查看网关调用成功率。
2、通过模拟网络问题，将应用B与注册中心的心跳链路断开，模拟注册异常的发生。
3、再次查看网关调用成功率，期望服务 A->B 的链路不受注册异常的影响。
为了方便对照，应用 A 会部署两种版本，一种是开启推空保护的，一种是没有开启的情况。最终期望的结果是，推空保护开关开启后，能够帮助应用 A 在发生异常的情况下，继续能够寻址到应用B。
网关的流量打到应用 A 之后，可以观察到，接口的成功率应该正好在 50%。
本文内容不用于商业目的，如涉及知识产权问题，请权利人联系51Testing小编(021-64471599-8017)，我们将立即处理
