微服务轮子项目（12） - nacos注册中心（上）

1. 概述

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

关键特性包括:

• 服务发现和服务健康监测
• 动态配置服务
• 动态 DNS 服务
• 服务及其元数据管理

相关资料：

• Github
• Nacos手册
• Spring Cloud for Nacos Config
• Spring Cloud for Nacos Discovery

2. 设计模型

2.1 ER模型

2.2 资源模型

3. 部署

3.1 依赖环境

• 64 bit OS，支持 Linux/Unix/Mac/Windows，推荐选用 Linux/Unix/Mac
• 64 bit JDK 1.8+
• Maven 3.2.x+

3.2 编译

进入nacos的目录执行以下maven指令

mvn -Prelease-nacos clean install -U

3.3 运行

#进入nacos/distribution目录下，找到对应版本的编译后的文件夹
cd distribution/target/nacos-server-$version/nacos/bin
#Linux/Unix/Mac
sh startup.sh -m standalone
#Windows
cmd startup.cmd

3.4 访问

http://127.0.0.1:8848/nacos

4. 配置中心

4.1 集成项目

引入jar：

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

bootstrap.yml增加以下配置：

spring:
  cloud:
    nacos:
      config:
        server-addr: ip:prot  #nacos的地址
        file-extension: yml   #配置文件格式
        shared-dataids: common.yml #公共配置文件

4.2 核心功能介绍

4.2.1 全局共用配置

可通过以下方式配置所有项目共享的配置项:

spring:
  cloud:
    nacos:
      config:
        shared-dataids: common.yml
        refreshable-dataids: common.yml

shared-dataids: 配置全局的配置名称

refreshable-dataids: 配置需要自动刷新的全局配置(默认不支持自动刷新)

4.2.2 自动刷新

//配置类上添加RefreshScope注解
@RefreshScope

4.2.3 不同环境的配置文件隔离

1.Nacos本身的地址

• 直接通过运行参数设置
• 例如开发环境的nacos地址为127.0.0.1:8848，而生产环境的nacos地址为192.168.28.130，部署生产环境时只需要在项目的启动参数添加以下内容

//以下参数是本项目个性化的，能同时影响配置中心和注册中心的地址
-Dzlt.nacos.server-addr=192.168.28.130:8848

2.业务配置项，总共有3种方法实现(选择一种即可)

1.通过spring.profiles.active

//通过运行参数设置
-Dspring.profiles.active=dev

2.通过Nacos 的 Group

//通过运行参数设置
-Dspring.cloud.nacos.config.group=DEVELOP_GROUP

3.通过Nacos 的 Namespace

//通过运行参数设置，值是namespace对应的id，id值可以在Nacos的控制台获取
-Dspring.cloud.nacos.config.namespace=b3404bc0-d7dc-4855-b519-570ed34b62d7

4.2.3.1 多环境总结

第一种：通过DataID与profile实现

• 优点：这种方式与Spring Cloud Config的实现非常像，用过Spring Cloud Config的用户，可以毫无违和感的过渡过来，由于命名规则类似，所以要从Spring Cloud Config中做迁移也非常简单。
• 缺点：这种方式在项目与环境多的时候，配置内容就会显得非常混乱。配置列表中会看到各种不同应用，不同环境的配置交织在一起，非常不利于管理。
• 建议：项目不多时使用，或者可以结合 Group对项目根据业务或者组织架构做一些拆分规划。

第二种：通过Group实现

• 优点：通过 Group按环境讲各个应用的配置隔离开。可以非常方便的利用 DataID和 Group的搜索功能，分别从应用纬度和环境纬度来查看配置。
• 缺点：由于会占用 Group纬度，所以需要对 Group的使用做好规划，毕竟与业务上的一些配置分组起冲突等问题。
• 建议：这种方式虽然结构上比上一种更好一些，但是依然可能会有一些混乱，主要是在 Group的管理上要做好规划和控制。

第三种：通过Namespace实现

• 优点：官方建议的方式，通过 Namespace来区分不同的环境，释放了 Group的自由度，这样可以让 Group的使用专注于做业务层面的分组管理。同时，Nacos控制页面上对于 Namespace也做了分组展示，不需要搜索，就可以隔离开不同的环境配置，非常易用。
• 缺点：没有啥缺点，可能就是多引入一个概念，需要用户去理解吧。
• 建议：直接用这种方式长远上来说会比较省心。虽然可能对小团队而言，项目不多，第一第二方式也够了，但是万一后面做大了呢？

多环境注意：不论用哪一种方式实现。对于指定环境的配置（spring.profiles.active=DEV、spring.cloud.nacos.config.group=DEV_GROUP、spring.cloud.nacos.config.namespace=83eed625-d166-4619-b923-93df2088883a），都不要配置在应用的bootstrap.properties中。而是在发布脚本的启动命令中，用-Dspring.profiles.active=DEV的方式来动态指定，会更加灵活！

Nacos使用注意:Nacos本身的相关配置必须都放在bootstrap.yml文件中，如果在Nacos添加了应用的配置文件：

1. 应用读取配置后只会覆盖本地相同key的配置
2. 应用读取配置后会缓存起来，就算停掉Nacos也会生效