1.为什么将服务注册到nacos？
答：微服务里有很多服务，为了更好的管理和查找服务，将服务注册到nacos中，nacos孵化于阿里巴巴，成长于十年双十一的洪峰考研，简单易用，稳定可靠，性能卓越。

2.在nacos中服务提供者是如何向nacos注册中心（registry）续约的？
答：nacos服务客户端（要注册到nacos的服务）启动时会每隔一段时间（默认5秒）向nacos发送心跳包，nacos注册中心15秒内没有检测到心跳包会默认认为nacos处于一种不健康的状态，30秒还没收到则认为这个服务已不可用。

3.对于nacos服务来讲它是如何判断服务实例的状态的？
答：nacos服务客户端（要注册到nacos的服务）启动时会每隔一段时间（默认5秒）向nacos发送心跳包，nacos注册中心15秒内没有检测到心跳包会默认认为nacos处于一种不健康的状态，30秒还没收到则认为这个服务已不可用。

4.服务启动时如何查找服务启动注册配置类？
答：通过NacosNamingService

5.服务消费方是如何调用服务提供方的资源？
答：通过RestTemplate第三方类来实现

6.@Bean注解的作用是什么？
答：一般用于配置类的内部，描述相关方法，用于告诉spring此方法的返回值要交给spring管理，bean的名字默认为方法名，假如需要指定名字可以@Bean（“bean的名字”）最多的应用场景是整合第三方资源对象

7.@Autowired注解的作用？
答：此注解描述属性，构造方法，set方法等，用于告诉spring框架，按照一定的规则为属性进行DI注入，默认按属性，方法参数类型查找对应的对象，假如只找到一个，则直接注入；类型多时，还会按照属性名或方法参数名

8.nacos中负责负载均衡底层是如何实现的？
答：通过Ribbon实现，Ribbon中定义了负载均衡算法，然后基于这些算法从服务实例中获取一个实例为想要服务方提供服务

-----------------------------------------

Nacos中的保护阈值的作用是什么？
假如现在有一个服务，本来有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。

nacos简介

它是阿里开源的 SpringCloud Alibaba 项目下的一项技术,主要用于服务发现、服务配置和服务管理

SpringCloud Alibaba说明

是阿里提供的微服务开发的一站式解决方案，此项目包含开发分布式应用微服务的必需组件

开源组件：
Sentinel ：用于流量控制、熔断降级、系统负载保护等保护服务的稳定性。
Nacos ：用于动态服务发现、配置管理和服务管理。
RocketMQ ：分布式消息系统。
Dubbo ： 高性能 Java RPC 框架。
Seata ：高性能微服务分布式事务解决方案。
Arthas：开源的Java动态追踪工具。
商业化组件：
Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
Alibaba Cloud OSS : 阿里云对象存储服务。
Alibaba Cloud SchedulerX : 分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
Alibaba Cloud SMS : 短信服务。

nocos提供的功能

主要提供的功能是：

作为微服务的注册中心，提供服务的注册与发现功能

作为微服务的分布式配置中心，提供统一配置管理，动态配置修改等功能

注册中心

注册中心的概念和作用

注册中心用来记录服务实例的地址信息，主要用于服务的发现，方便后续调用

注册中心的机制

服务实例启动之后，通过引用的nacos的sdk主动向注册中心登记自己的地址信息
服务实例停止运行的时候，主动让注册中心销毁自己的信息
服务实例不是主动停止，而是因为故障等原因死掉的，注册中心会通过心跳机制发现示例异常，对其清理
一个服务实例在调用另一个服务时，可以根据服务名称从注册中心获取此服务实例信息列表，从中选取一个实例进行调用。

实例概念

服务具有可访问网络地址（IP:Port）的进程。

权重概念

实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。

健康检查

以指定方式检查服务下挂载的实例 的健康度，从而确认该实例 是否能提供服务。根据检查结果，实例  会被判断为健康或不健康。对服务发起解析请求时，不健康的实例不会返回给客户端。

健康保护阈值

为了防止因过多实例 不健康导致流量全部流向健康实例  ，继而造成流量压力把健康实例压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数占总服务实例数 的比例小于该值时，无论实例是否健康，都会将这个实例 返回给客户端。这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例能正常工作。

服务的发现机制概念

服务调用时必须知道目标服务实例的 IP、端口、API 接口。
而获取这些信息的逻辑原理就是服务发现机制

nacos负载均衡

基于权重的负载均衡：实例权重越大，流量越大

基于标签

Nacos服务是如何判定服务实例的状态？

通过发送心跳包，5秒发送一次，如果15秒没有回应，则说明服务出现了问题，
如果30秒后没有回应，则说明服务已经停止。

配置中心

分布式配置中心概念

服务的多个实例或多个服务都使用同一个配置文件，而不是每个实例或服务都使用自己独有的配置；使用分布式配置中心对于需要修改配置时，不用繁琐的修改每个配置并重启实例，直接修改一个配置文件即可。

nacos的注册表结构

Nacos最外层是namespace隔离环境，然后是group对服务进行分组，然后就是服务，一个服务下 有多个集群，集群下有多个实例。

对应Java代码，Map<String,Map<String,Service>>，最外层的key是namespaceId，值是map，内部map大的key是group拼接serviceName（group@@serviceName），值是service对象；service对象内部又是一个map，key是集群名称，值是Cluster对象，Cluster对象内部维护了实例对象集合。

消费者是如何调用提供者的

通过创建RestTemplate对象来实现。

负载均衡通过什么实现

Ribbon

Nacos配置中心宕机，还能读取到配置吗

可以，客户端读取到配置信息以后会缓存在本地内存，可以在内存中拿到数据

nocos客户端向注册中心续约

为了保证业务方服务的新增机器和机器下线等信息及时同步给消费者，提供者需定期向nacos服务器上报心跳包（默认5秒发送一次），告诉服务器自己还活着，如果nacos服务器15秒没有收到心跳包，就会把这个提供者标示为不健康，并通报给nacos客户端，如果服务器30秒没有收到心跳包，就会在nacos服务器上删除这个提供者，并把最新的提供者列表通过upd协议发送给nacos客户端。

nocosCAP

Nacos的 CP 和 AP 架构的选择，取决于我们配置的服务实例是临时实例还是持久实例

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false   //false:持久化实例，使用 CP架构;true:临时实例，使用 AP架构

Nacos和Eureka区别

临时实例与永久实例

临时实例:是在应用程序启动时注册到Nacos中的，当该实例关闭时，Nacos将自动注销该实例。临时实例通常用于临时的服务实例，例如在容器化的环境中，实例可能在某个容器中启动，并在容器关闭时自动注销。

永久实例:是注册到Nacos中的，它们会一直存在，除非手动从Nacos中注销。永久实例通常用于具有长期生命周期的服务，例如基于物理服务器的服务。