微服务_Nacos

简介

Nacos（全称为Dynamic Naming and Configuration Service，“动态服务发现、配置和服务管理平台”）是阿里巴巴开源的一款云原生服务发现和配置管理平台，支持多种语言。它提供了服务发现、配置管理、服务治理和流量管理等功能，使得微服务系统的构建和管理更加便捷。Nacos的特点是能够快速定位服务实例，动态管理服务，实时查看服务状态，实时监控服务流量，提升服务的可用性和稳定性。支持CP也支持AP。
对应Spring Cloud中的Eureka(服务注册与发现) 和 Config + Bus（自动刷新的配置中心）
其相关特性包括：

1.服务发现和服务健康监测

Nacos支持基于DNS和RPC的服务发现，即服务消费者可以使用DNS或者HTTP的方式来查找和发现服务。Nacos提供对服务的实时的健康检查，阻止向不健康的主机或者服务实例发送请求。Nacos支持传输层（Ping/TCP）、应用层（HTTP、Mysql）的健康检查。

2.动态配置服务
动态配置服务可以以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

• 中心化：在配置中心统一配置
• 外部化：并非在服务应用中进行配置，而是在应用外：Nacos中配置
• 动态化：配置可以动态修改，服务不用重启就能感知到配置变化

3.动态DNS服务

支持权重路由，让开发者更容易的实现中间层的负载均衡、更灵活的路由策略、流量控制以及DNS解析服务。

4.服务和元数据管理

Nacos允许开发者从微服务平台建设的视角来管理数据中心的所有服务和元数据。如：服务的生命周期、静态依赖分析、服务的健康状态、服务的流量管理、路由和安全策略等。

什么是配置中心

应用程序在启动和运行的时候往往需要读取一些配置信息,配置基本上伴随着应用程序的整个生命周期,比如:数据库连接参数、启动参数等。

如果项目需要更新新功能（二次发版），修改配置非常麻烦，因此在微服务中引入配置中心

特点

• 配置是独立于程序的只读变量
  配置对于程序是只读的,程序通过读取配置来改变自己的行为,但是程序不应该去改变配置

• 配置伴随应用的整个生命周期
  配置贯穿于应用的整个生命周期,应用在启动时通过读取配置来初始化,在运行时根据配置调整行为。比如:启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。

• 配置可以有多种加载方式
  常见的有程序内部hard code ,配置文件,环境变量,启动参数,基于数据库等

• 配置需要治理
  同一份程序在不同的环境(开发测试生产’)、不同的集群(如不同的数据中心)经常需要有不同的配置，所以需要有完善的环境、集群配置

服务端安装与配置简介

在官网看文档安装：Nacos快速开始

安装完成后修改conf/appliction.properties，改数据库配置，设置保存配置的数据库

默认日志文件夹logs会在配置文件中的{BASEDIR}下生成

客户端用法

引入依赖

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-configartifactId>
    <version>2.2.3.RELEASEversion>
dependency>
 
1
2
3
4
5
6
7

配置（项目模块）

在bootstrap.propertis/yml文件中配置
（bootstrap比application.文件加载的更早，在父环境中就加载）

配置本服务运行的端口号、自己作为spring应用的名称、环境（会用于在nacos匹配配置文件）

以及nacos相关配置

# Tomcat
server: 
  port: 9200

# Spring
spring: 
  application:
    # 应用名称
    name: ruoyi-auth
  profiles:
    # 环境配置
    active: dev
  cloud:
    nacos:
      discovery:
        # 服务注册地址
        server-addr: 127.0.0.1:8848
      config:
        # 配置中心地址
        server-addr: 127.0.0.1:8848
        # 配置文件格式
        file-extension: yml
        # 共享配置
        shared-configs:
          - application-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

共享配置是所有服务共享的配置文件，在本例中，会在nacos中心匹配到application-dev.yml文件。

如果上面因没有配置环境导致${spring.profiles.active}取不到值，nacos会自动忽视中间那个“-”，匹配applicaion.yml，不用担心会发生错误。

nacos配置中心配置

新建数据集（DataId），基本每个dataId对应一个数据文件.

然后我们可以全当在本地写好配置文件一样直接使用，用法没有改变，比如可以通过 @Value(“${配置项}”)将配置的值注入

通常会在Controller里边用@Value取出使用，但是你要是想改变他，就要重新改代码，打包，部署，十分麻烦，我们需要让配置文件的值变得动起来，Nacos也采用了Spring Cloud原生注解@RefreshScope实现配置自动更新。（注解在类上）

经典面试题

Nacos与Eureka的区别有哪些？

接口方式：Nacos与Eureka都对外暴露了Rest风格的API接口，用来实现服务注册、发现等功能
实例类型：Nacos的实例有永久和临时实例之分；而Eureka只支持临时实例
健康检测：Nacos对临时实例采用心跳模式检测，对永久实例采用主动请求来检测；Eureka只支持心跳模式
服务发现：Nacos支持定时拉取和订阅推送两种模式；Eureka只支持定时拉取模式

Nacos的服务注册表结构是怎样的？

Nacos采用了数据的分级存储模型，最外层是Namespace，用来隔离环境。然后是Group，用来对服务分组。接下来就是服务（Service）了，一个服务包含多个实例，但是可能处于不同机房，因此Service下有多个集群（Cluster），Cluster下是不同的实例（Instance）。
对应到Java代码中，Nacos采用了一个多层的Map来表示。结构为Map>，其中最外层Map的key就是namespaceId，值是一个Map。内层Map的key是group拼接serviceName，值是Service对象。Service对象内部又是一个Map，key是集群名称，值是Cluster对象。而Cluster对象内部维护了Instance的集合。

Nacos如何支撑阿里内部数十万服务注册压力？

Nacos内部接收到注册的请求时，不会立即写数据，而是将服务注册的任务放入一个阻塞队列就立即响应给客户端。然后利用线程池读取阻塞队列中的任务，异步来完成实例更新，从而提高并发写能力。

Nacos如何避免并发读写冲突问题？

Nacos在更新实例列表时，会采用CopyOnWrite技术，首先将旧的实例列表拷贝一份，然后更新拷贝的实例列表，再用更新后的实例列表来覆盖旧的实例列表。
这样在更新的过程中，就不会对读实例列表的请求产生影响，也不会出现脏读问题了。

• 父项目pom那个client是啥？
• 在启动的地方有个work目录