SpringCloud Alibaba Nacos服务注册和配置中心

一、概述

一个更易于构建云原生应用的动态服务发现，配置管理和服务管理中心。
主要作用是：替代Eureka做服务注册中心，替代Config做服务配置中心

Nacos 官方文档：https://nacos.io/zh-cn/docs/what-is-nacos.html

nacos 的 CAP 理论

CAP 原则又称 CAP 定理，指的是在一个分布式系统中， Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者不可得兼。

一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本）

可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性）

分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。
如果在某个分布式系统中数据无副本， 那么系统必然满足强一致性条件， 因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。
因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。

nacos 中 AP 和 CP 的切换

curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'

Nacos 配置中心

1. 导入 Maven 依赖

<dependencies>
	<!--nacos-config-->
	<dependency>
		<groupId>com.alibaba.cloud</groupId>
		<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
	</dependency>
	<!--nacos-discovery-->
	<dependency>
		<groupId>com.alibaba.cloud</groupId>
		<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
	</dependency>
	<!--web + actuator-->
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-web</artifactId>
	</dependency>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-actuator</artifactId>
	</dependency>
	<!--一般基础配置-->
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-devtools</artifactId>
		<scope>runtime</scope>
		<optional>true</optional>
	</dependency>
	<dependency>
		<groupId>org.projectlombok</groupId>
		<artifactId>lombok</artifactId>
		<optional>true</optional>
	</dependency>
	<dependency>
		<groupId>org.springframework.boot</groupId>
		<artifactId>spring-boot-starter-test</artifactId>
		<scope>test</scope>
	</dependency>
</dependencies>

2. 添加 yml 配置

nacos 会默认读取 bootstrap.yml 或 bootstrap.properties 中的配置

bootstrap.yml 配置文件

server:
  port: 3377
spring:
  application:
    name: nacos-config-client
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 # 服务注册中心地址
      config:
        server-addr: localhost:8848 # 配置中心地址
        file-extension: yml         # 指定yaml格式的配置（yml和yaml都可以）

#${spring.application.name}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}
#nacos-config-client-dev.yaml  (一定要与file-extension值保持一致)

application.yml 配置文件

spring:
  profiles:
    active: dev

Data ID 的值为：
\${spring.application.name}-\${spring.profiles.active}.\${spring.cloud.nacos.config.file-extension}

注：如果没有指明 spring.profiles.active，则横线链接符 “-” 也将不存在。

根据上面的配置可以总结出 Data ID：nacos-config-client-dev.yml

3. 添加主启动类

@SpringBootApplication
@EnableDiscoveryClient
public class NacosConfigClientMain3377 {
    public static void main(String[] args) {
        SpringApplication.run(NacosConfigClientMain3377.class, args);
    }
}

4. 添加 Controller 业务类

@RestController
@Slf4j
@RefreshScope  //通过SpringCould原生注解 @RefreshScope 实现配置自动更新
public class ConfigClientController {
    @Value("${userLocalConfig:default}")
    private String userLocalConfig;

    @GetMapping("/getUserLocalConfig")
    public String getUserLocalConfig(){
        return userLocalConfig;
    }
}

5. 运行项目，在 Nacos 配置中心中添加配置

1. 新增配置

2. 填写相关信息

3. 发布配置

4. 访问相关接口

Nacos 分环境配置（dev/pro/test）

问题

在实际开发中，通常一个系统会准备：dev 开发环境，test 测试环境，pro 生产环境
一个大型的分布式微服务会有很多微服务子项目，每一个微服务又有相应又会相应的开发环境、测试环境、预发环境、正式环境......那怎么对这些微服务配置进行管理呢？

---

分类配置管理

Nacos 中将配置分为 Namespace、Group、Data ID 三类。

其中最外层的 namespace 是可以用于区分部署环境的，Group 和 DataID 逻辑上区分两个目标对象。

默认情况：Namespace=public，Group=DEFAULT_GROUP，默认Cluster是DEFAULT

• Nacos 默认的命名空间是 public，Namespace 主要用来实现隔离。

  比方说我们现在有三个环境：开发、测试、生产环境，我们就可以创建三个 Namespace，不同的 Namespace 之间是隔离的。

• Group 默认是 DEFAULT_GROUP，Group 可以把不同的微服务划分到同一个分组里面去。Service 就是微服务；一个 Service 可以包含多个 Cluster(集群)，Nacos 默认 Cluster 是 DEFAULT，Cluster 是对指定微服务的一个虚拟划分。

  比方说为了容灾，将 Service 微服务分别部署在了杭州机房和广州机房，这时就可以给杭州机房的 Service 微服务起一个集群名称(HZ)，给广州机房的 Service 微服务起一个集群名字(GZ)，还可以尽量让同一个机房的微服务互相调用，以提升性能。

• 最后是 Instance，就是微服务的实例。