Nacos 服务注册和配置中心
简介
全名NamingConfiguration,一个更易于构建云原生的动态服务发现,配置管理和服务管理平台.Nacos就是注册中心+配置中心的组合,替代Eureka做服务注册中心,替代Config做服务配置中心
注册进Nacos
- maven
父工程
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.1.3.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
启动类
@EnableDiscoveryClientyml
spring:
application:
name: nacos-payment-provider
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #配置nacos地址
Nacos默认集成了ribbon,所以服务提供者实现负载的情况下,调用方会自动使用默认策略来进行选择
服务注册中心对比
| 服务注册与发现框架 | CAP模型 | 控制台管理 | 社区活跃度 |
|---|---|---|---|
| Eureka | AP | 支持 | 低(2.x版本闭源) |
| Zookeeper | CP | 不支持 | 中 |
| Consul | CP | 支持 | 高 |
| Nacos | AP/CP | 支持 | 高 |
据说 Nacos 在阿里巴巴内部有超过10万的实例运行,已经过了累死双十一等各种大型流量的考验
- Nacos与其他注册中心特性对比
| >> | Nacos | Eureka | Consul | CoreDNS | Zookeeper |
|---|---|---|---|---|---|
| 一致性协议 | CP+AP | AP | CP | / | CP |
| 健康检查 | TCP/HTTP/Mysql/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | / | Client Beat |
| 负载均衡 | 权重/DSL/metadata/CMDB | Ribbon | Fabio | RR | / |
| 雪崩保护 | 支持 | 支持 | 不支持 | 不支持 | 不支持 |
| 自动注销实例 | 支持 | 支持 | 不支持 | 不支持 | 支持 |
| 访问协议 | HTTP/DNS/UDP | HTTP | HTTP/DNS | DNS | TCP |
| 监听支持 | 支持 | 支持 | 支持 | 不支持 | 支持 |
| 多数据中心 | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| 跨注册中心 | 支持 | 不支持 | 支持 | 不支持 | 不支持 |
| SpringCloud | 支持 | 支持 | 支持 | 不支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 不支持 | 不支持 | 支持 |
| K8s集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 |
总之我很欣赏阿里的一点,野心很大!网上可以搜到他的Nacos全景图,几乎所有的覆盖面他都要去做,包括他的官网建议抛弃zookeeper直接Nacos整合Dubbo,也就诞生了唯一一个AP,CP都支持的注册中心
注: C是所有节点在同一时间看到的数据时一致的;而A的定义是所有的请求都会受到响应
何时选择使用何种模式?
一般来说如果不需要存储服务级别的信息且服务实例是从nacos-client注册,并能够保持心跳上报,那么就可以选择AP模式.当前主流的服务如Spring Cloud和Dubbo服务,都适用于AP模式,AP模式为了服务的可能性而减弱了一致性,因此AP模式下只支持注册临时实例
如果需要在服务级别编辑或者存储配置信息,那么CP是必须,K8s服务和DNS服务则适用于CP模式,CP模式下则支持注册持久化实例,此时则是以Raft协议为集群模式运行,该模式下注册实例之前必须先注册服务,如果服务不存在则会返回错误.
Nacos切换CAP选择
curl -X PUT "$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP"
分布式配置中心
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
</dependency>
config 的yml要区分于出来的bootstrap.yml,Nacos同Springcloud-config一样,在项目初始化时,要保证先从配置中心进行配置拉取之后,才能保证项目的正常启动
bootstrap.yml
spring:
application:
name: nacos-config-client
cloud:
nacos:
discovery:
server-addr: 192.168.10.63:8848
config:
server-addr: 192.168.10.63:8848
file-extension: yaml #指定yaml格式的配置
application.yml
server:
port: 3377
spring:
profiles:
active: dev
在控制台添加对应DataId的配置文件,具体规则我们在官网可以查看Nacos Config gitHub
也就是分为三部分组成,实例名称+profile级别+后缀名
感兴趣的也可以看我以前的文章Spring Cloud Config,原理就是用SpringCloudConfig做的,也同时支持动态刷新
发布之后我们就可以用配置中心的文件来进行项目配置了
具体原理是怎么通知到项目,以及项目是怎么以配置中心为基准的我也整理过
Spring Cloud Bus,Nacos 也是参照Cloud一步一步整合升级来的
分类配置
Nacos已经干翻了eureka+config+bus,并且他们没有的他也有,介绍点新功能
- Namespace 命名空间
Nacos默认的命名空间是public,Namespace主要用来实现隔离
比如说我们现在有三个环境:开发,测试和生产环境,我们就可以创建三个Namespace.不同的Namespace之间是隔离的
- Group 组
Group默认DEFAULT_GROUP,Group可以把不同的微服务划分到同一个分组里面去
- Cluster 集群 默认DEFAULT
集群配置&持久化
在单机版启动的情况下,Nacos默认是采用内嵌式数据库derby,所以在我们重启或断点的情况下,只要重启就可以保证我们配置的文件还在,但在我们集群的环境下不可能每个服务去单独配置一遍,并且还不共享,所以官网就推荐我们必须要配置集群环境,并且支持mysql数据库来持久化,官网推荐使用linux环境
修改conf文件里的application.properties,添加数据库对应项和配置,详细看官网
修改启动命令,添加 -p命令
while getopts ":m:f:s:p:" opt
do
case $opt in
m)
MODE=$OPTARG;;
f)
FUNCTION_MODE=$OPTARG;;
s)
SERVER=$OPTARG;;
p)
PORT=$OPTARG;;
修改luster.conf, 配置指定的集群端口
修改启动命令,添加port指定
nohup $JAVA -Dserver.port=${PORT} ${JAVA_OPT} nacos.nacos >> ${BASE_DIR}/logs/start.out 2>&1 &
echo "nacos is starting，you can check the ${BASE_DIR}/logs/start.out"
重启nacos,并端口形式,例: `./startup.sh -p 8849
配置nginx代理
