nacos的服务注册以及健康检测机制

namespace：为了可以使nacos上注册的服务和添加的配置实现环境隔离，比如测试环境和生产环境，nacos上可以添加对应的namespace用于区分不同的环境，只有在相同namespace下的服务才可以相互调用

新增namespace步骤如下：

---

注册服务列表相关备注（因为使用的rpc框架有多种，所以这里就不提及相关的rpc配置）

服务名：注册时定义的服务名称

分组名称：用于定义一类系统的分组

集群名称：多个实例可以分成不同的集群，比如10的实例可以分成两个集群，5个实例一个集群

实例个数：相关应用启动的个数

健康实例数：nacos会定时检测相关应用是否健康

---

nacos健康检测机制

为什么服务中心需要健康监测机制?

如果服务中心没有健康监测机制，那么注册的服务挂掉以后（比如两个实例，挂掉了一个），订阅服务如果没有得到通知，仍然是50%的向两台机器发送请求，就会有50%的请求失败，出现严重的系统错误，所以服务中心需要检测到注册服务是否健康，如果有服务挂掉以后，需要主动将当前的可用服务信息通知到订阅方。

---

nacos如何进行健康检查？

nacos有两种健康监测方式，一种是对临时服务，一种是持久化服务，服务注册时通过ephemeral参数进行区分，ephemeral=true代表是临时服务，ephemeral=false代表是持久化服务，所有服务默认为临时服务

临时服务检查机制：由服务主动向服务中心上报心跳，5s上报一次，15s没有上报，服务为不健康服务，30s没有上报，注册中心摘除服务。

持久化服务检查机制：由注册中心主动探测，20s探测一次，探测失败，服务为不健康服务，但是服务不会被摘除。

---

高并发大流量下健康实例摘除引发服务雪崩

A->B->C ,A服务调用B服务，B服务调用C服务，正常情况下，假如C服务有10个实例，每个实例能够达到的QPS为500，那么整个C服务可以达到5000的qps，但是c服务如果宕机了5个服务，注册中心通知B服务目前只有5个实例可用，那么每个c实例每秒需要接收1000次请求，这个显然大大超出了实例的性能范围，机器会被打死，接着B服务也会无法提供服务，继而A服务无法提供服务。

nacos保护阈值如何避免服务雪崩

 每个服务可以设置保护阈值，0到1之间，当健康实例个数比例（健康实例个数/总实例）小于保护阈值时，为了避免服务雪崩，也会向不健康实例发送请求，这样牺牲掉一部请求，避免整个系统无法提供服务。