Nacos作为注册中心与配置中心

提示：参考文章来源：https://blog.youkuaiyun.com/Zong_0915/article/details/113089265
参考文章来源： https://blog.youkuaiyun.com/m0_62674870/article/details/127737743

---

一、SpringCloud Alibaba简介

提示：本人项目中的服务治理就是用的Nacos来做注册中心(服务发现/注册)与配置中心(动态配置管理)。

  在讲nacos之前，我先讲一下Spring Cloud alibaba，Spring Cloud alibaba为分布式应用开发提供一站式解决方案。它包含开发分布式应用程序所需的所有组件，可以轻松地使用Spring Cloud开发应用程序。只需要添加一些注释和少量配置，就可以将Spring Cloud的应用程序连接到阿里巴巴的分布式解决方案上，并利用阿里巴巴的中间件构建分布式应用系统。

---

二、Nacos简介

1.Nacos概念

  原因：当我们的服务越来越多、越来越大，维护起来越来越麻烦，就需要有那么一个系统来专门的管理我们的服务的注册与发现。

  Nacos归属于 Spring Cloud Alibaba 技术栈下，有很有实用的特性，其中关键特性有动态服务发现、配置和服务管理平台，这些特性能够帮助我们更快速的实现动态服务发现、配置、元数据及流量管理。

2.为什么使用Nacos

  在网上可以看到很多关于Spring Cloud的服务治理组件Eureka已经停止维护的消息。

  Spring Cloud的替代产品，也就是Spring Cloud Alibaba，目前正处于蓬勃发展的态式。由阿里实战过经历了考验，性能强悍，设计合理，开源出来的成套产品还能搭配完善的可视化界面，搭建简单，学习曲线低，文档丰富并且是中文，给开发与运维带来了极大的便利。

3.Nacos数据模型

  Nacos 数据模型 Key 由三元组唯一确定, Namespace默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。
  Namespace：代表不同的环境配置隔离 如：开发、生产；Group：可以代表某一个项目或者应用；DataId：表示配置文件/工程名称，配置系统各种信息。类似于广东省深圳市南山区这种形式。

4.Nacos架构

  图为Nacos官网提供的架构图，其中分为这么几个模块：
  Provider APP是服务提供者、Consumer APP是服务消费者、Name Server：通过Virtual IP或者DNS的方式实现Nacos高可用集群的服务路由。
  Nacos Server：Nacos服务提供者。其中包含：
  OpenAPI：功能访问入口。
  Config Service、Naming Service：Nacos提供的配置服务、名字服务模块。
  Consistency Protocol：一致性协议，用来实现Nacos集群节点的数据同步，使用Raft算法实现。
  Nacos Console：Nacos控制台。
  简单的工作流程大概是，服务提供者通过虚拟IP来访问Nacos Server高可用集群，基于OpenAPI功能访问入口完成服务的注册和服务的查询。Nacos Server的底层则通过数据一致性算法（Raft）来完成节点的数据同步。

三、Nacos作为注册中心

1.基本操作

学一项技术，我们首先是学习怎么使用它，然后再学习它的相关原理。
  1.启动Nacos控制台，修改pom.xml文件，添加Nacos Discovery Starter依赖。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>

  2.在应用的src/main/resources路径下的bootstrap.yml文件中配置nacos discovery的地址，并在bootstrap.yml文件中指定该应用的名称。
  3.给启动类上添加@EnableDiscoveryClient注解。
  4.启动应用，观察到Nacos控制台服务列表已经注册上kafka-monitor服务。
总结：往后我们需要注册更多的服务，都是通过以上步骤注册到注册中心的。

2.注册中心原理

代码如下（示例）：

  该图是Nacos作为注册中心的原理图，大致流程为：服务提供方首先使用Nacos提供的API接口发起服务注册，将服务消费方的地址注册到Nacos容器的Map中，并与Nacos建立心跳机制，定时检查服务状态；服务消费方则从Nacos中订阅服务，从服务注册表中找到相应的服务，并执行一个定时任务，每10秒从Nacos中拉取一次数据，Nacos则根据服务提供者的状态，来及时推送服务状态的变化给消费方。
  总结：Nacos作为注册中心的功能体现在：服务注册、服务发现、健康检查三方面。
  服务注册体现在：服务实例启动时注册到服务注册表、关闭时则注销。
  服务发现体现在：服务消费者可以通过查询服务注册表来获得可用的实例。
  健康检查体现在：服务注册中心需要调用服务实例的健康检查API来验证其是否可以正确的处理请求。

3.Nacos注册表结构

  服务注册到Nacos以后，会保存在一个本地注册表中，其结构如上图所示：
  首先最外层是一个Map，key：是namespace_id，起到环境隔离的作用。namespace下可以有多个group，value：又是一个Map<String, Service>，代表分组及组内的服务。
  一个组内可以有多个服务，key：代表group分组，不过作为key时格式是group_name:service_name，value：分组下的某一个服务，例如userservice，用户服务。类型为Service。
  内部也包含一个Map<String,Cluster>，一个服务下可以有多个集群，key：集群名称，value：Cluster类型，包含集群的具体信息。
  一个集群中可能包含多个实例，也就是具体的节点信息，其中包含一个Set，就是该集群下的实例的集合。- Instance：实例信息，包含实例的IP、端口号、健康状态、权重等等信息。
  总结：每一个服务去注册到Nacos时，就会把信息组织并存入这个Map中。Nacos是多级存储模型，最外层通过namespace来实现环境隔离，然后是group分组，分组下就是服务，一个服务有可以分为不同的集群，集群中包含多个实例。

四、Nacos作为配置中心

1.基本操作

配置中心的实现步骤与注册中心大体相似，只不过需要在Nacos控制台新建配置文件。
  1.启动Nacos控制台，修改pom.xml文件，添加Nacos Config Starter依赖。

<dependency>
    <groupId>com.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

  2.在应用的src/main/resources路径下的bootstrap.yml文件中配置nacos config的地址，并在bootstrap.yml文件中指定该应用的名称。
  3.根据配置文件中的信息在nacos控制台创建对应的命名空间、group以及配置文件kafka-test.yml。
  4.启动应用，在配置文件kafka-test.yml中新增topic或者更改topic，优先读取的都是Nacos配置中心的配置，配置中心中没有的，才读取本地中的值。

2.配置中心的思路

配置中心思路：
  1.首先把项目中各种配置全部都放到一个集中的地方进行统一管理。
  2.当各个服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。
  3.当配置中心中的各种参数有更新的时候，也能通知到各个服务实时的过来同步最新的信息，使之动态更新。

Nacos配置中心针对配置的管理提供了4种操作：
  获取配置，从Nacos配置中心中读取配置。
  删除配置：删除配置中心的指定配置。
  发布配置：将配置保存到Nacos配置中心。
  监听配置：订阅感兴趣的配置，当配置发生变化的时候可以收到一个更新事件。
而从原理层面来看，可以归类为两种类型：配置的CRUD和配置的动态监听。

3.配置的CRUD

对于Nacos配置中心来说，主要是提供了配置的集中式管理功能，然后对外提供CRUD的访问接口使得应用系统可以完成配置的基本操作。
  对于服务端来说：需要考虑的是配置如何存储，是否需要持久化。
  对于客户端来说：需要考虑的是通过接口从服务器查询得到相应的数据然后返回。
  Nacos服务端的数据存储默认采用的是Derby数据库（也支持Mysql）。Derby属于内嵌式数据库，做一些小型工程时，不想安装Mysql，可使用这类嵌入内嵌式数据库存储数据，简单方便，类似于 SQLite 数据库。

4.配置的动态监听

  Nacos的客户端和服务端之间存在着数据交互的一种行为用于做到实时数据更新，而对于这种交互行为共有两种方式：Pull模式与Push模式。
  Pull模式下，客户端需要定时从服务端拉取一次数据，由于定时带来的时间间隔，因此不能保证数据的实时性，并且在服务端配置长时间不更新的情况下，客户端的定时任务会做一些无效的Pull操作。
  Push模式下，服务端需要维持与客户端的长连接，如果客户端的数量比较多，那么服务端需要耗费大量的内存资源来保存每个资源，并且为了检测连接的有效性，还需要心跳机制来维持每个连接的状态。
  Nacos采用的是Pull模式，并且采用了一种长轮询机制。客户端采用长轮询的方式定时的发起Pull请求，去检查服务端配置信息是否发生了变更，如果发生了变更，那么客户端会根据变更的数据获得最新的配置。
  长轮询：客户端发起轮询请求后，服务端如果有配置发生变更，就直接返回。
详细地来说：
  如果客户端发起Pull请求后，发现服务端的配置和客户端的配置是保持一致的，那么服务端会“Hold”住这个请求。（服务端拿到这个连接后在指定的时间段内不会返回结果，直到这段时间内的配置发生变化），一旦配置发生了变化，服务端会把原来“Hold”住的请求进行返回。

  Nacos服务端收到请求后，会检查配置是否发生了变更，如果没有，那么设置一个定时任务，延期29.5秒执行。同时并且把当前的客户端长轮询连接加入到allSubs队列。 这时候有两种方式触发该连接结果的返回：
  第一种：等待29.5秒（长连接保持的时间）后触发自动检查机制，这时候不管配置有无发生变化，都会把结果返回给客户端。
  第二种：在29.5秒内的任意一个时刻，通过Nacos控制台或者API的方式对配置进行了修改，那么触发一个事件机制，监听到该事件的任务会遍历allSubs队列，找到发生变更的配置项对应的ClientLongPolling任务，将变更的数据通过该任务中的连接进行返回，即完成了一次推送操作。

---

总结

以上就是今天要讲的内容，本文仅仅简单介绍了nacos的注册中心与配置中心，帮助本人自己复习nacos的重点知识，仅供参考，参考的文章都已标注出处。