Nacos精选
一、Nacos两种健康检查模式
1.1 client端推送检测
客户端（注册在nacos上的其它微服务实例）健康检查。
客户端通过心跳上报方式告知服务端(nacos注册中心)健康状态；
默认心跳间隔5秒；
nacos会在超过15秒未收到心跳后将实例设置为不健康状态；
超过30秒将实例删除；
1.2 服务端主动拉取检测
服务端健康检查。
nacos主动探知客户端健康状态，默认间隔为20秒；
健康检查失败后实例会被标记为不健康，不会被立即删除。
1.3 如何选择检查模式
如果是临时实例服务健康检查模式中的 client 模式,为持久化实例对应的是 server 模式。 （临时工需要自己签到，正式工公司会自动打卡）
二、注册实例支持ephemeral字段
Nacos 在 1.0.0版本 instance级别增加了一个ephemeral字段，该字段表示注册的实例是否是临时实例还是持久化实例。如果是临时实例，则不会在 Nacos 服务端持久化存储，需要通过上报心跳的方式进行包活，如果一段时间内没有上报心跳，则会被 Nacos 服务端摘除。在被摘除后如果又开始上报心跳，则会重新将这个实例注册。持久化实例则会持久化被 Nacos 服务端，此时即使注册实例的客户端进程不在，这个实例也不会从服务端删除，只会将健康状态设为不健康。
同一个服务下可以同时有临时实例和持久化实例，这意味着当这服务的所有实例进程不在时，会有部分实例从服务上摘除，剩下的实例则会保留在服务下。
使用实例的ephemeral来判断，ephemeral为true对应的是服务健康检查模式中的 client 模式,为false对应的是 server 模式。
三、临时实例和持久化实例区别
临时和持久化的区别主要在健康检查失败后的表现，持久化实例健康检查失败后会被标记成不健康，而临时实例会直接从列表中被删除。
这个特性比较适合那些需要应对流量突增，而弹性扩容的服务，当流量降下来后这些实例自己销毁自己就可以了，不用再去nacos里手动调用注销实例。持久化以后，可以实时看到健康状态，便于做后续的告警、扩容等一系列处理。
Nacos中的保护阈值【0-1 的一个范围】的作用是什么？
假如现在有一个服务，本来有10个实例，但是现在挂掉了8个，剩下2个正常实例，此时本来由10个实例处理的流量，就全部交给这个两个正常实例来处理了，此时这两个实例很有可能是处理不过来的，最终导致被压垮，为了应对这种情况，Nacos提供了保护阈值这个功能，我们可以给某个服务设置一个0-1的阈值，比如0.5，那就表示，一旦实例中只剩下一半的健康实例了，比如10个实例，只剩下5个健康实例了，那么消费者在进行服务发现时，则会把该服务的所有实例，也包括不健康的实例都拉取到本地，然后再从所有实例中进行负载均衡，选出一个实例进行调用，在这种情况下，选出来的即可能是一个健康的实例，也可能是挂掉的实例，但是通过这种方式，很好的保护的剩下的健康实例，至少保证了一部分请求能正常的访问，而不至于所有请求都不能正常访问，这就是Nacos中的保护阈值，同时，这个功能在Spring Cloud Tencent中叫全死全活。
Nacos中的负载均衡是怎么样的？
Nacos的负载均衡指的是，在进行服务发现时进行负载均衡，正常情况下，在进行服务发现时，会根据服务名从Nacos中拉取所有的实例信息，但是Nacos中提供了一个功能，就是可以在拉取实例时，可以根据随机策略只拉取到所有实例中的某一个，这就是Nacos中的负载均衡，它跟Ribbon的负载均衡并不冲突，可以理解为Ribbon的负载均衡是发生在Nacos的负载均衡之后的。
Nacos的就近访问是什么意思？
首先，在Nacos中，一个服务可以有多个实例，并且可以给实例设置cluster-name，就是可以再进一步的给所有实例划分集群，那如果现在某个服务A想要调用服务B，那么Naocs会看调用服务A的实例是属于哪个集群的，并且调用服务B时，那就会调用同样集群下的服务B实例，根据cluster-name来判断两个实例是不是同一个集群，这就是Nacos的就近访问。
你是怎么理解CAP理论的？
CAP理论是分布式领域中最为重要的理论，CAP理论可以理解为目前硬件条件下对于分布式架构的一种限制，就是对于一个分布式系统，只能保证AP或CP，而不能同时保证CAP，首先对于一个分布式系统，P，也就是分区容错性是一定要保证的，对于一个分布式系统，得保证在网络出现分区后，分布式系统仍然能工作，所以得保证P，只不过当出现网络分区后，整个分布式系统如果想要保证数据一致性，那么就要损耗系统可用性，或者如果想要保证系统的可用性，就不能保证系统的一致性，这里说的是强一致性，因为如果网络出现问题，分布式系统中的数据就无法进行及时的同步，如果要求强一致性，那么就只能等网络好了之后，数据同步好了之后，才能提供给用户使用，同理，如果要求网络出现后问题，系统要能使用，那就可能数据会不一致，所以对于一个分布式系统，目前来说只能保证CP或AP。
Nacos中保证的是CP还是AP？
通常我们说，Nacos技能保证CP，也能保证AP，具体看如何配置，但其实只不过是Nacos中的注册中心能保证CP或AP，Nacos中的配置中心其实没什么CP或AP，因为配置中心的数据是存在一个Mysql中的，只有注册中心的数据需要进行集群节点之间的同步，从而涉及到是CP还是AP，如果注册的节点是临时节点，那么就是AP，如果是非临时节点，那么就是CP，默认是临时节点。
如何理解Nacos中的命名空间？
命名空间，也就是namespace，其实这个概念并不是Nacos中独有的，在Nacos中，不管是配置还是服务，都是属于某一个命名空间中的，默认情况下都是属于pulibc这个命名空间中的，我们可以在Nacos中新增命名空间，也就相当于开辟了另外一套存放服务和配置的地方，命名空间之间是独立的，完全不冲突的，所以我们可以利用Nacos中的命名空间来实现不同环境、不同租户之间的服务注册和配置。
你觉得注册中心应该是CP还是AP？
我觉得大部分情况下，注册中心应该是AP，如果注册中心是CP的，那么表示，当我们向注册中心注册实例或移除实例时，都要等待注册中心集群中的数据达到一致后，才算注册或移除成功，而这是比较耗时的，随着业务应用规模的增大，应用频繁的上下线，那么就会导致注册中心的压力比较大，会影响到服务发现的效率以及服务调用了，而如果注册中心是AP的，那么注册中心集群不管出现了什么情况，都是可以提供服务的，就算集群节点之间数据出现了不一致，对于业务应用而言，可能拉取到了一个已经下线了的服务节点，但是现在一般的微服务框架或组件都提供了服务容错和重试功能，也可以避免这个问题，而如果是AP，对于注册中心而言就不需要消耗太多的资源来实时的保证数据一致性了，保证最终一致性就可以了，这样注册中心的压力会小一点，另外像Zookeeper来作为注册中心，因为Zookeeper保证的就是CP，但是如果集群中如果大多数节点挂掉了，就算还剩下一些Zookeeper节点，这些节点也是不能提供服务的，所以这个也不太合适，所以综合来看，注册中心应该保证AP会更好，就像Euraka、Nacos他们默认保证的就是AP。
