开发者学堂课程【服务发现与配置管理高可用最佳实践：服务发现与配置管理高可用最佳实践】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/968/detail/14889
三、服务发现高可用
服务发现包含两个角色服务消费者( Consumer ) 和服务提供者( Provider )。
(1) 消费者( Consumer )：
通过 MSE 提供推空保护、服务降级能力达到容灾的目的。
推空保护应对开头的案例，服务空列表推送到Consumer 时，可以自动缓存数据，不会报到下游，没有实例异常。
服务消费者会从注册中心上订阅服务提供者的实例列表。当遇到突发情况（例如，可用区断网,Provider端无法上报心跳)或注册中心(变配、重启、升降级）出现非预期异常时，都有可能导致订阅异常，影响服务消费者的可用性。
为了应对不可预知的情况下订阅列表异常，可以在Consumer侧配置推空保护。
(2) 服务提供者 ( Provider ):
可以通过注册中心和服务治理提供的容灾保护，离群摘除，无损下线能力，提升整体服务的可用性。
服务提供者容灾保护主要是用于避免集群在异常流量下出现雪崩。
1. Consumer 端-推空保护：
(1)Consumer没有推空保护:
假如 Provider 出现注册失败的异常(网络.SDK.bug.dns )的故障;
在注册中心可能就判断Provider心跳过期，使自动下线;
Consumer定位到空列表，业务就会中断报错。
(3) 开启了推空保护:
Consumer定位到空列表，会把空列表的变更丢弃，直接使用缓存来保障业务服务的可用。
开启方式：
(4)配置项
sCA:
spring.cloud.nacos.discovery.namingPushEmptyProtection=true Dubbo
持久化缓存目录，避免重启后丢失:
${user.home}/nacos/naming/${namespaceld}
2.Consumer 端-服务降级
服务降级是当下游的某一个接口出现异常时可以做一些策略上的保护。
例如：这个接口可能是不重要的功能，可能在下游的这个服务上有更重要的业务，也需要调用这个服务，可以通过特定的规则进行配置，将这个接口进行降低保证重要的功能可用性。((将宝贵的下游 Provider 资源保留给重要的业务 Consumer 使用))
服务降级的具体策略：包含返回 Null 值、返回 Exception 异常、返回自定义 JSON 数据和自定义回调
3.Provider 端-容灾保护
Provider的高可用有容灾保护。
(1) 无容灾保护能力：
业务类似于大促，可能都会有突发的流量。在突发请求量过来时，如果流量超过了容量水位,个别 Provider 可能就会发生故障,例如 java 应用可能就会发生一些短期的故障，会增加请求的延迟。整个 Provider 处理能力，吞吐量就下降。在这个时候，这个节点可能会发生异常，心跳可能续不上；
注册中心会将故障的节点摘除，剩余的流量就会就给剩下的节点；
如果流量还是比较大，剩余的节点可能负载也会变高，可能也会出现故障；
最后不断的循环过程，注册中心会将大部分的节点都摘除，最后全部流量的都会压给剩余的少量节点。可能100%流量就给剩下的两个节点。可以看到就是前面4个节点都有两个节点异常。剩下的流量这两个节点的大概也无法负载。最后所有的服务都不可用，100%不能提供服务。
(2) 开启容灾保护;
可以设定一个阈值。发生这个情况时，当故障的节点数量达到保护阈值时，注册中心会做保护的操作，会将这些流量返回所有的实例列表。
作用：将所有的流量都平摊给所有的机器。不管这个机器是否故障，会将原先所有的实例都返回给上游。所有的流量就会平摊里所有机器，从下图看到剩余的两个节点，只接收50%流量。
目的：在发生较大故障时，可以保护集群不会完全雪崩，至少能够保留50%的可用性。
(3)开启方式：
命令控制行；控制台开启(即将推出)
(3) 容灾保护在紧急的情况下，能够保证服务的可用性在一定的水平之上，所以它是一种兜底的策略。
4. Provider 端-离群实例摘除
心跳续约的是注册中心感知实例可用性的基本的一种方法，在注册中心也没有其他能力做探测。
(1) 在特定的情况下，会有心跳正常，但是服务不可用的情况
例如：专门处理业务请求的线程线程池满。Java 的进程是存活的，并且虚拟机没有异常，心跳是正常，只是线程池是满的，所以本质上是不可用的，但是注册中心还是会将他的可用性暴露给他的上游；
依赖的底层的 RDS 连接异常或者渗透慢，它可用性有损，但心跳不能完全感知到。
(2)微服务治理中心-离群实例摘除
基于异常检测的摘除策略:包含网络异常和网络异常+业务异常(HTTP 5xx)；
设置异常阈值、 QPS 下限、摘除比例下限。
(3) 离群实例摘除对于可用性探测是一种补充，能够根据特定的接口的调用异常的特征去衡量服务可用性，所以它应该是更完备的机制补充心跳和可用性的标准。
5.Provider 端-无损下线（平滑下限）
(1)有损下线：
Provider 变更，升级或者是重启，下线的过程中，心跳在注册中心存约以及变更生效都有一定的时间，并且在存约失效之后，变更推送到它的上游也有一定的时间，所以在这个时间内，如果 Consumer的订阅列表没有更新，如果把 Provider 直接停止服务。那么 Consumer 的请求就会有一定的流量报错，直接损失。
(2)无损下线：
保障在下线的过程中不会有流量出现异常，有很多不同的解决方案，包括一些注册中心本身也是存在能力
通过推送些机制（对应用进行停止、部署、回滚、缩容、重置等操作），能够减少变更生效的时间，但是微服务治理中心提供无损下线的能力是侵入性最低的，并且能够让我们无感的去整合到发布的流程中，完全自动执行。
免去繁琐的运维脚本逻辑的维护。
四、配置管理高可用
配置管理主要包含配置订阅和配置发布两类操作。
配置管理：解决在多环境，多机器的配置发布以及配置动态实时更新推送的问题。
1.微服务基于配置管理做高可用的方案：
(1)发布环境管理：
通过基于配置环境管理的能力可以一致性管理上百个的机器，不同的环境如何能够正确的推送，能够避免些人为的误操作，或者是在出现线上问题的时候，能够将这些问题快速的回滚；发布的过程中可以做一些灰度。
(2) 业务开关动态推送：
实时的，能够推送到业务系统上，例如：一些功能或者活动页面的开关，
(3) 内置容灾降级预案：
预案通过配置直接推送下发，包括流量的阈值能实时通过配置去调整。
(4)双11大促配置管理高可用解决方案：
例如：消耗比较大的非核心的业务做降级；对一些服务配置白名单(一些重要的业务，在大促期间要做变更)；禁用一些高风险的操作；调整日志采样；在系统压力大的时候去降级一部分的功能和一部分请求做限流。
2.配置管理客户端容灾方案：
例如：客户端本地的目录，主要分为两级，高优先级的是容灾目录，低优先级的是缓存目录。
当配置中心不可用的时候，本地的客户端的会优先查看容灾目录的配置，否则使用之前拉取到的配置。
(1)缓存目录∶每次客户端和配置中心进行数据交互后，会保存最新的配置内容至本地缓存目录中，当服务端不可用状态下，会使用本地缓存目录中内容。
(2)容灾目录：因为缓存目录里面可能不一定会有，或者业务可能需要紧急的变更配置，开启预案或者措施。如果这个时候配置中心不可用，需要容灾目录帮助业务绕开该配置中心的问题，解决配置下发的问题。总的来说，不管发生什么样的风险，我们都要能够使配置的客户端能够读取到正确的配置，从而保证微服务（整个系统）的可用性。
3.在配置中心高可用的方案：
(1)配置中心高可用：
针对读写的限流，例如：
限制连接数：特定的单机限流，可以支持特定的 IP 限流；
限写接口：特定的配置或发布操作的限流。
(2)配置发布：
控制人的风险，人做配置发布或者配置管理的过程中，可能会有一些误操作，例如环境看错或配置写错。配置发布也有一些、置是可灰度的，可以追溯它的发布历史，并且能够一键快速回滚。
