05-Nacos注册中心
五、Nacos注册中心
5.1、认识和安装Nacos
- Nacos是阿里巴巴的产品,现在是SpringCloud中的一个组件
- 相比Eureka功能更加丰富,在国内受欢迎程度较高
- 官网
5.2、Windows安装
开发阶段采用单机安装即可
同时Linux系统上Nacos的安装跟Windows上差不多,下载好相对应的压缩包后,直接解压即可使用
5.2.1、下载安装包
- 在Nacos的GitHub界面,提供又下载连接,可以下载编译好的Nacos服务端或者源代码
- GitHub主页
- GitHub的Release下载页
5.2.2、解压
- 解压好后,其目录结构如下所示
bin
文件- 启动脚本
conf
文件- 配置文件
5.2.3、端口配置
- Nacos的默认端口是8848,如果你电脑上的其他进程占用了8848端口,请先关闭该进程,或者进入nacos的conf目录,修改
application.properties
配置文件中的端口
5.2.4、启动
- 启动nacos非常简单,进入bin目录后,打开cmd终端界面
- 执行
startup.cmd -m standalone
命令,即可启动standalone
的意思是以单服务器模式启动(因为此时还没配置nacos集群)
- 执行后的效果如图所示
如果闲麻烦的话,windows上还可以用创建快捷方程式的方法,指定该命令,以后再向单机启动nacos直接点击快捷方程式即可;感兴趣可自行配置
5.2.5、访问
- 在浏览器输入地址
- 默认的账号和密码都是nacos,进入后的界面如下所示
5.3、服务注册到Nacos
- Nacos是SpringCloudAlibaba的组件,而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说,并没有太大区别
- 主要差异在于
- 依赖不同
- 服务地址不同
5.3.1、引入依赖
在引入Nacos依赖之前,需要将Eureka的依赖注释或者删除,否则会引起冲突
-
①、在cloud-demo父工程的pom文件中的
<dependencyManagement>
标签中引入SpringCloudAlibaba的依赖-
<!--alibaba相关的依赖,其中有nacos--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-alibaba-dependencies</artifactId> <version>2.2.6.RELEASE</version> <scope>import</scope> <type>pom</type> </dependency>
-
-
②、在子工程user-service和order-service中的pom文件中引入nacos-discovery依赖
-
<!--nacos discovery--> <dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency>
-
5.3.2、配置nacos地址
配置yml文件之前,也要先将Eureka的相关配置注释或删除
-
在user-service和order-service的application.yml中添加nacos地址
-
spring: cloud: nacos: server-addr: localhost:8848
-
5.3.3、重启
- 重启微服务后,登录nacos管理界面,可以看到微服务信息如下所示
5.3.4、小结
- 使用nacos作为注册中心需要操作的步骤
- ①、导入依赖,删除eureka相关依赖
- ②、在yml文件删除eureka的注册中心地址,编写server-add的nacos地址
5.4、服务分级存储模型
- 一个服务可以有多个实例,例如本次案例的user-service,可以有:
- localhost:8081
- localhost:8082
- localhost:8083
- 假如这些实例分布于全国各地不同的机房,例如
- localhost:8081(上海机房)
- localhost:8082(上海机房)
- localhost:8083(广州机房)
- Nacos就将同一机房内的实例,划分为一个集群
- 也就是说,user-service是服务,一个服务可以包含多个集群,如杭州、上海,每个集群下可以有多个实例,行程分级模型,如下图所示
- 微服务互相访问的时候,应该尽可能访问同集群实例,因为本地访问速度更快。本集群内不可用的时候,才访问其他集群,如下图所示
- 杭州机房内的order-service应该优先访问同机房内的user-service
5.4.1、给user-service配置集群
-
修改user-service的application.yml文件,添加集群配置
-
8081和8082在GZ集群,8083在SH集群
-
spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ # 集群名称
-
-
重启两个user-service实例,点击详情,查看集群
-
将8083端口的配置设置集群为SH,添加属性
-
-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH
-
配置如图所示
-
上图写错了,cluster.name应该改为cluster-name
-
-
启动UserApplication8083,再次查看nacos详情
5.4.2、同集群优先的负载均衡
-
默认的
ZoneAvoidanceRule
并不能实现根据同集群优先来实现负载均衡 -
因此Nacos中提供了一个
NacosRule
的实现,可以优先从同集群中挑选实例 -
配置步骤
-
①、给order-service配置集群信息
-
修改order-service的application.yml文件,添加集群配置,放在GZ这个集群中
-
spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ # 集群名称
-
-
②、修改负载均衡规则
-
修改order-service的application.yml文件,修改负载均衡规则
-
userservice: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
-
-
③、重启OrderApplication,访问浏览器
-
刷新多次,发现所有的请求都在8081和8082这两个服务器
-
在本地集群中服务器的选择采用的是随机的负载均衡方式
-
-
④、将8081和8082的服务器关闭
- 这时同一个集群中的所有服务器都关闭了,只能访问其他集群了
-
⑤、再次访问8083服务器
- 访问8083端口的服务器的时候,OrderApplication控制台会有警告信息,说是出现了跨集群访问
-
5.4.3、小结
- 分级存储
- 实现方式
- 使用集群
- 配置集群方式
- 使用cluster-name指定集群名称,也会收到负载均衡策略影响
- 实现方式
5.5、权重配置
-
在实际部署中,有可能会出现如下的场景
- 服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求
-
但是默认情况下NacosRule是同集群内随机挑选,不会考虑机器的性能问题
-
因此,Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高
-
①、再次启动8081和8082服务器
-
②、在nacos控制台,找到userservice的实例列表,点击编辑,即可修改权重
-
③、在弹出的编辑窗口,修改权重
-
④、再次访问,会发现8081被访问到的次数少得多,大约只有8082的五分之一
-
PS:userservice微服务重启以后,权重会还原
-
-
⑤、如果将8081权重修改为0,则该实例永远不会被访问
-
-
应用场景
- 当系统升级的时候,可以将用户清除,升级之后再放入少量用户测试访问
5.6、环境隔离
- Nacos既是注册中心,又是数据中心。为了便于管理,Nacos提供了
namespace
来实现环境隔离功能。用于进行租户级别隔离 - 我们最常用的就是不同环境下比如测试环境,线上环境进行隔离
- nacos中可以有很多个
namespace
namespace
下可以有group等- 业务相关性比较强的可以放在一组,比如:支付和订单
- 不同
namespace
之间相互隔离,即不同namespace
的服务互相不可见
5.6.1、创建namespace
- 应用场景
- 基于不同的开发环境变化做隔离操作
- 默认情况下,所有service、group都在同一个namespace,名为public,如下图所示
- 创建步骤
- ①、点击页面的新增按钮,添加一个namespace
- ②、填写数据
- ③、在页面可以看到一个新的namespace
- ①、点击页面的新增按钮,添加一个namespace
5.6.2、微服务配置namespace
-
①、修改order-service的application.yml文件
-
给微服务配置namespace只能通过修改配置来实现
-
# nacos 配置 cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ namespace: 88335441-8805-441a-9964-3628d17634ac # 命名空间的ID
-
-
②、重启order-service后,查看管理页面,可以看到在public下没有orderservice服务
-
③、点旁边的dev可以看到另一个空间的服务只有orderservice
-
④、此时访问order-service,因为namespace不同,会导致找不到userservice,控制台会报错
-
⑤、修改user-service中的application.yml,把它的namespace也设置成同一个命名空间
-
# nacos 配置 cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ # 集群名称 namespace: 88335441-8805-441a-9964-3628d17634ac # 命名空间的ID
-
-
⑥、重启UserApplication8081的服务,查看nacos的服务列表
-
⑦、再次访问可以正常访问
5.7、Nacos和Eureka的区别
5.7.1、Nacos的服务实例
- 临时实例
- 如果实例宕机超过一定时间,会从服务列表剔除(默认类型)
- 非临时实例
- 如果实例宕机,也不会从服务列表提出,也可以称为永久实例
- Naccos和Eureka整体结构类似(服务注册、服务拉取、心跳等待),但是也存在一些差异
- 服务消费者会每隔30秒从注册中心去拉取一次服务列表,缓存下来
- Nacos和Eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
- Nacos和Eureka的区别
- Nacos支持服务端主动检测提供者状态
- 临时实例采用心跳模式,非临时实例采用主动检测模式
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新更及时,Eureka只能支持服务的拉取,不支持主动推送
- Nacos支持服务端主动检测提供者状态
5.7.2、配置一个服务实例为永久实例
-
①、目前是临时实例,在关闭OrderApplication服务器后,等待几秒钟,查看服务列表会发现这个实例就会被剔除
-
②、修改配置order-service为非临时实例
-
# nacos 配置 cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: GZ # 集群名称 namespace: 88335441-8805-441a-9964-3628d17634ac # 命名空间的ID ephemeral: false # 设置为非临时实例
-
-
③、查看管理界面
-
④、关闭OrderApplication实例,会发现这个实例并不会被剔除,并且马上就能看到管理页面变红了
5.7.3、小结
- Nacos和Eureka的区别
- 相同点
- 都支持服务的注册和服务的拉取
- 都支持心跳方式的服务监测
- 不同点
- Nacos有临时实例和非临时实例,eureka没有临时实例概念
- 临时实例是支持心跳监测的,非临时实例是Nacos主动监测
- 临时实例超过30秒没有心跳,会从服务删除;非临时实例不会删除
- Nacos不单支持服务的拉取,还支持服务的主动推送
- Nacos有临时实例和非临时实例,eureka没有临时实例概念
- 相同点