1. 概述
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
关键特性包括:
- 服务发现和服务健康监测
- 动态配置服务
- 动态 DNS 服务
- 服务及其元数据管理
相关资料:
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 访问
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添加了应用的配置文件:
- 应用读取配置后只会覆盖本地相同key的配置
- 应用读取配置后会缓存起来,就算停掉Nacos也会生效