Nacos注册中心
Nacos注册中心
CAMELLIANacos注册中心
Nacos是SpringCloudAlibaba推出的一款注册中心。
1. 服务注册到nacos
Nacos是SpringCloudAlibaba的组件,而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说,并没有太大区别。
主要差异在于:
- 依赖不同
- 服务地址不同
1.1 引入依赖
在cloud-demo父工程的pom文件中的<dependencyManagement>
中引入SpringCloudAlibaba的依赖:
1 | <dependency> |
然后在user-service和order-service中的pom文件中引入nacos-discovery依赖:
1 | <!--nscos客户端依赖--> |
注意:要注释掉eureka的依赖,不然引起冲突。
1.2 配置nacos地址
在user-service和order-service的application.yml中添加nacos地址:
1 | spring: |
注意:要注释掉eureka的配置。
1.3 引入LoadBalancer依赖
从 Spring Cloud 2020.0 版本(代号为 Ilford)开始,Spring Cloud 官方宣布不再推荐使用 Netflix 提供的组件,如 Ribbon、Hystrix、Zuul 等。相应地,Spring Cloud 提供了替代方案,例如:
负载均衡:使用 Spring Cloud LoadBalancer 代替 Ribbon。Spring Cloud LoadBalancer 是一个灵活且可扩展的负载均衡器,完全集成了 Spring Cloud 生态系统。
断路器:使用 Resilience4j 代替 Hystrix。Resilience4j 提供了一个轻量级的、函数式的弹性编程框架,支持断路器、重试、限流、隔离舱等多种弹性机制。
API 网关:使用 Spring Cloud Gateway 代替 Zuul。Spring Cloud Gateway 是基于 Spring WebFlux 构建的 API 网关,提供了路由、过滤、限流、重试等功能。
因此,在新版本的 Spring Cloud 中,推荐使用这些替代方案来实现相应的功能。Ribbon 的负载均衡功能可以通过 Spring Cloud LoadBalancer 来实现。
虽然在这里使用 Spring Cloud LoadBalancer,但是配置步骤和 Netflix 几乎一样。
引入依赖
配置nacos
服务拉取和负载均衡
这一步有所不同,我们需要额外在消费者中添加Spring Cloud LoadBalancer依赖。
1
2
3
4
5<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-loadbalancer</artifactId>
<version>4.1.4</version>
</dependency>
到此就可以运行程序了,注意nacos服务要运行,不然报错。
重启微服务后,登录nacos管理页面,可以看到微服务信息:
2. 服务分级存储模型
一个服务可以有多个实例,例如我们的user-service,可以有:
- 127.0.0.1:8081
- 127.0.0.1:8082
- 127.0.0.1:8083
假如这些实例分布于全国各地的不同机房,例如:
- 127.0.0.1:8081:在上海机房
- 127.0.0.1:8082:在上海机房
- 127.0.0.1:8083:在杭州机房
Nacos就将同一机房内的实例 划分为一个集群。
也就是说,user-service是服务,一个服务可以包含多个集群,如杭州、上海,每个集群下可以有多个实例,形成分级模型,如图:
微服务互相访问时,应该尽可能访问同集群实例,因为本地访问速度更快。当本集群内不可用时,才访问其它集群。例如:
杭州机房内的order-service应该优先访问同机房的user-service。
2.1 给user-service配置集群
修改user-service的application.yml文件,添加集群配置:
1 | cloud: # nacos配置 |
重启两个user-service实例后,我们可以在nacos控制台看到下面结果:
我们再次复制一个user-service启动配置,添加属性:
1 | -Dserver.port=8083 |
配置如图所示,添加虚拟机选项:
启动UserApplication3后再次查看nacos控制台:
2.2 同集群优先的负载均衡
默认的ZoneAvoidanceRule
并不能实现根据同集群优先来实现负载均衡。
因此Nacos中提供了一个NacosRule
的实现,可以优先从同集群中挑选实例。
1)给order-service配置集群信息
修改order-service的application.yml文件,添加集群配置:
1 | spring: |
2)修改负载均衡规则
修改order-service的application.yml文件,修改负载均衡规则:
1 | userservice: |
3. 权重配置
实际部署中会出现这样的场景:
服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求。
但默认情况下NacosRule是同集群内随机挑选,不会考虑机器的性能问题。
因此,Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高。
在nacos控制台,找到user-service的实例列表,点击编辑,即可修改权重:
在弹出的编辑窗口,修改权重:
[!tip]
当权重为0时,该实例永远不会被访问。可以利用这个特性来无感升级系统,增强用户体验。
4. 环境隔离
Nacos提供了namespace来实现环境隔离功能。
- nacos中可以有多个namespace
- namespace下可以有group、service等
- 不同namespace之间相互隔离,例如不同namespace的服务互相不可见
4.1 创建namespace
默认情况下,所有service、data、group都在同一个namespace,名为public:
通过点击页面新增按钮,添加一个namespace:
然后,填写表单:
就能在页面看到一个新的namespace:
4.2 给微服务配置namespace
给微服务配置namespace只能通过修改配置来实现。
例如,修改order-service的application.yml文件:
1 | spring: |
重启order-service后,访问控制台,可以看到下面的结果:
此时访问order-service,因为namespace不同,会导致找不到userservice,控制台会报错:
*5. Nacos与Eureka的区别
Nacos的服务实例分为两种l类型:
临时实例:如果实例宕机超过一定时间,会从服务列表剔除,默认的类型。
非临时实例:如果实例宕机,不会从服务列表剔除,也可以叫永久实例。
配置一个服务实例为永久实例:
1 | spring: |
Nacos和Eureka整体结构类似,服务注册、服务拉取、心跳等待,但是也存在一些差异:
Nacos与eureka的共同点
- 都支持服务注册和服务拉取
- 都支持服务提供者心跳方式做健康检测
Nacos与Eureka的区别
- Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式。
- 临时实例心跳不正常会被剔除,非临时实例则不会被剔除
- Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
- Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式