1 服务注册和配置中心 Nacos
Nacos简介
Nacos:Dynamic Naming and Configuration Service
一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。 Nacos就是注册中心+配置中心的组合(Eureka+Config+Bus)
安装运行成功后访问http://localhost:8848/nacos(默认账号密码为nacos)
Nacos作为服务注册中心
服务提供者注册
1.新建模块cloudalibaba-provider-payment-9001
2.引入pom
- spring-cloud-starter-alibaba-nacos-discovery
- spring-boot-starter-web
- spring-boot-starter-actuator
- spring-boot-starter-test
3.配置yml
1 | server: |
4.添加主启动
1 |
|
5.处理业务
1 |
|
6.测试
- 启动nacos和9001
- 访问http://localhost:9001/payment/nacos/1
服务消费者注册和负载
1.新建cloudalibaba-consumer-nacos-order-83
2.引入pom
3.配置yml
1 | server: |
4.添加主启动
5.添加配置
由于nacos自带负载均衡,其包引入ribbon,故配置restTemplate
1 |
|
5.处理业务
1 |
|
6.测试
- 启动nacos、9001、9002、83
- 访问http://localhost:83/consumer/payment/nacos/1
服务注册中心对比
Nacos支持AP和CP模式的切换
C是所有节点在同一时间看到的数据是一致的,而A的定义是所有的请求都会收到响应
如果不需要存储服务级别的信息且服务实例是通过nacos-client注册,并能够保持心跳上报,那么可以选择AP模式。当前主流的服务如SpringCloud和Dubbo服务,都适用于AP模式。AP模式为服务的可能性而减弱了一致性,因此AP模式下只支持注册临时实例
如果需要在服务级别编辑或者存储配置信息,那么CP是必须,K8S服务和DNS服务则适用于CP模式。CP模式下则支持注册持久化实例,此时则以Raft协议为集群运行模式,该模式下注册实例之前必须先注册微服务,如果服务不存在,则返回错误
1 | 模式切换 |
Eureka | AP | 支持 | 低(2.X版本闭源) |
---|---|---|---|
服务注册与发现框架 | CAP模型 | 控制台管理 | 社区活跃度 |
Zookeeper | CP | 不支持 | 中 |
Consul | CP | 支持 | 高 |
Nacos | AP | 支持 | 高 |
Nacos作为服务配置中心
基础配置
1.新建cloudalibaba-config-nacos-client-3377
2.引入pom
spring-cloud-starter-alibaba-nacos-config
spring-cloud-starter-alibaba-nacos-discovery
3.配置yml
Nacos与SpringCloud Config一样,在项目初始化时,要保证先从配置中心进行配置拉取,拉取配置后,才能保证项目的正常启动,SpringBoot中配置文件的加载是存在优先级顺序的,bootstrap优先级高于application
bootstrap.yml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 # nacos配置
server:
port: 3377
spring:
application:
name: nacos-config-client
cloud:
nacos:
discovery:
server-addr: localhost:8848 #Nacos服务注册中心地址
config:
server-addr: localhost:8848 #Nacos作为配置中心地址
file-extension: yaml #指定yaml格式的配置
# ${spring.application.name}-${spring.profile.active}.${spring.cloud.nacos.config.file-extension}application.yml
1
2
3
4
5 spring:
profiles:
active: dev # 表示开发环境
#active: test # 表示测试环境
#active: info
4.添加主启动
5.处理业务
@RefreshScope:通过SpringCloud原生注解@RefreshScope实现配置的自动更新
1 |
|
Nacos中匹配规则
Nacos中的dataid的组成格式及与SpringBoot配置文件中的匹配规则
在 Nacos Spring Cloud 中,dataId
的完整格式如下:
1 | ${prefix}-${spring.profiles.active}.${file-extension} |
prefix
默认为spring.application.name
的值,也可以通过配置项spring.cloud.nacos.config.prefix
来配置。spring.profiles.active
即为当前环境对应的 profile,详情可以参考 Spring Boot文档。 注意:当spring.profiles.active
为空时,对应的连接符-
也将不存在,dataId 的拼接格式变成${prefix}.${file-extension}
file-exetension
为配置内容的数据格式,可以通过配置项spring.cloud.nacos.config.file-extension
来配置。目前只支持properties
和yaml
类型。
公式
1 | # nacos-config-client-dev.yaml |
测试
- 启动需要在nacos客户端-配置管理-配置管理模块下有对应的yaml文件
- 运行cloud-config-nacos-client-3377
- 调用接口查看配置信息 http://localhost:3377/config/info
自带动态刷新
修改Nacos中的yaml配置文件,再次调用查看配置的接口,就会发现配置已经刷新
分类配置
多环境多项目管理的问题
问题1
实际开发中,一个系统会准备
- dev开发环境
- test测试环境
- prod生产环境
如何保证指定环境启动时服务能正确读取到Nacos相应环境的配置文件?
问题2
一个大型分布式微服务系统会有很多微服务子项目,每个微服务项目又会有相应的开发环境、测试环境、预发环境、正式环境等,
如何对这些微服务配置进行管理?
配置管理
命名空间
Namespace+Group+DataID
1.是什么
类似Java里面的包名和类名,最外层的namespace可以用于区分部署环境,Group和DataID逻辑上区分两个目标对象
2.三种情况
默认情况
Namespace=public, Group=DEFAULT_GROUP,默认Cluster是DEFAULT
- Nacos默认的命名空间是public,Namespace主要用于实现隔离
- Group默认是DEFAULT_GROUP,Group可以把不同的微服务划分到同一个分组里面去
Service就是微服务,一个Service可以包含多个Cluster(集群),Nacos默认Cluster是DEFAULT,Cluster是对指定微服务的一个虚拟划分
Instance就是微服务实例
DataID方案配置
指定spring.profiile.active和配置文件的DataID来使不同环境下读取不同的配置
默认空间+默认分组+新建dev和test两个DataID
通过spring.profiile.active属性进行多环境下配置文件的读取
1 | spring: |
Group方案配置
通过Group实现环境区分,新建Group,在Nacos图形界面控制台新建配置文件
bootstrap+application
在config下增加一条group的配置,可以配置为DEV_GROUP或者TEST_GROUP
1 | # nacos配置 |
Namespace方案配置
新建dev/test的Namespace
bootstrap.yml
1 | # nacos配置 |
application.yml
1 | spring: |
Nacos集群和持久化配置
默认Nacos使用嵌入式数据库实现数据的存储。所以,如果启动多个默认配置下的Nacos节点,数据存储是存在一致性问题的。为了解决该问题,Nacos采用集中式存储的方式来支持集群化部署,目前仅支持MYSQL的存储