服务实例注册到nacos注册中心的时候会有临时实例和持久实例两种（spring.cloud.nacos.discovery.ephemeral为true则为临时实例(默认值)，为false则为持久实例）：
临时实例
默认情况，服务实例仅会注册在Nacos内存，不会持久化到Nacos磁盘，其健康检测机制为Client模式，即Client主动向Server上报其健康 状态（类似于推模式）；默认心跳间隔为5秒，在15秒内Server未收到Client心跳，则会将其标记为“不健康”状态；在30秒内若收到了Client心跳，则重新恢复“健康”状态，否则该实例将从Server端内存清除。即对于不健康的实例，Server会自动清除；
持久实例
服务实例不仅会注册到Nacos内存，同时也会被持久化到Nacos磁盘，其健康检测机制为Server模式，即Server会主动去检测Client的健康状态（类似于拉模式）；默认每20秒检测一次，健康检测失败后服务实例会被标记为“不健康”状态，但不会被清除，因为其是持久化在磁盘的，其对不健康持久实例的清除，需要专门进行；
适用场景：
临时实例适合于存在突发流量暴增可能的互联网项目，可以实现弹性扩容，正常生产中的环境就是这样；
持久实例保护阈值，比如说服务A有100个实例，那么当有98个不可用时：
如果是临时实例，则只会返回两个服务，那么大并发量请求这两个服务肯定会造成雪崩的，造成整个服务不可用；
如果是持久实例，实例会全部返回，虽然有98个不可用，消费者可能会请求失败，但不至于剩下的两个健康实例崩溃；
nacos有个保护阀值的概念：可以设置为0-1之间的浮点数，它其实是⼀个⽐例值（当前服务健康实例数/当前服务总实例
数，保护阈值的意义在于当服务A健康实例数/总实例数 < 保护阈值 的时候，说明健康实例不多了，这个时候保护阈值会被触
发（状态true），nacos将会把该服务所有的实例信息（健康的+不健康的）全部提供给消费者，消费者可能访问到不健康
的实例，请求失败，但这样也⽐造成雪崩要好，牺牲了⼀些请求，保证了整个系统的⼀个可用。
namespace 的设计是 nacos 基于此做多环境以及多租户数据(配置和服务)隔离的。
应用场景：
从一个租户(用户)的角度来看，如果有多套不同的环境，那么这个时候可以根据指定的环境来创建不同的 namespce，以此来实现多环境的隔离。例如，你可能有测试，预生产和生产三个不同的环境，那么使用一套 nacos 集群可以分别建以下三个不同的 namespace。
从多个租户(用户)的角度来看，每个租户(用户)可能会有自己的 namespace,每个租户(用户)的配置数据以及注册的服务数据都会归属到自己的 namespace 下，以此来实现多租户间的数据隔离。例如超级管理员分配了三个租户，分别为张三、李四和王五。分配好了之后，各租户用自己的账户名和密码登录后，创建自己的命名空间。
注意：服务注册到不同的命名空间下，服务间无法通过OpenFeign指定服务名进行负载通信!!!
不同的服务可以归类到同一分组。当服务即使处于同一个命名空间，如果不在同一个分组，仍无法使用OpenFeign进行负载调用通信
实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。值为0~1的数值。
应用场景：
服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。但默认情况下 NacosRule 是同集群内随机挑选，不会考虑机器的性能问题。
nacos作为配置中心时也是要区分命名空间和分组的，作用和作为注册中心类似。
nacos同spring-cloud-config一样，可以作为一个配置中心，统一的来管理配置，可以配置多套环境，各个微服务可以按需到nacos配置中心拉取相关配置，并且Nacos消除了在更新配置时重新部署应用程序和服务的需要(通过添加@RefreshScope注解实现)，这使配置更改更加高效和灵活。
灰度配置指的是指定部分客户端IP进行新配置的下发，其余客户端配置保持不变，用以验证新配置对客户端的影响，保证配置的平稳发布。灰度配置是生产环境中一个比较重要的功能，对于保证生产环境的稳定性非常重要。在1.1.0中，Nacos 支持了以IP为粒度的灰度配置。