【Spring Cloud】Nacos注册中心

【Spring Cloud】Nacos注册中心

文章目录

​​五、Nacos注册中心​​

​​5.1 认识和安装Nacos​​​​5.2 服务注册到nacos​​

​​1）引入依赖​​​​2）配置nacos地址​​​​3）重启​​

​​5.3 服务分级存储模型​​

​​5.3.1 给user-service配置集群​​​​5.3.2 同集群优先的负载均衡​​

​​5.4 权重配置​​​​5.5 环境隔离​​

​​5.5.1 创建namespace​​​​5.5.2 给微服务配置namespace​​

​​5.6 Nacos与Eureka的区别​​

五、Nacos注册中心

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba也推出了一个名为Nacos的注册中心。

5.1 认识和安装Nacos

​​Nacos​​是阿里巴巴的产品，现在是​​SpringCloud​​中的一个组件。相比​​Eureka​​功能更加丰富，在国内受欢迎程度较高。

安装方式可以参考： ​​Nacos安装指南​​

5.2 服务注册到nacos

​​Nacos​​是​​Spring Cloud Alibaba​​的组件，而​​Spring Cloud Alibaba​​也遵循​​Spring Cloud​​中定义的服务注册、服务发现规范。因此使用​​Nacos​​和使用​​Eureka​​对于微服务来说，并没有太大区别。

主要差异在于：

依赖不同服务地址不同

1）引入依赖

在​​cloud-demo​​父工程的​​pom​​文件中的​​​​中引入​​Spring Cloud Alibaba​​的依赖：

com.alibaba.cloud spring-cloud-alibaba-dependencies 2.2.6.RELEASE pom import

然后在​​user-service​​和​​order-service​​中的​​pom​​文件中引入​​nacos-discovery​​依赖：

com.alibaba.cloud spring-cloud-starter-alibaba-nacos-discovery

注意：不要忘了注释掉eureka的依赖。

2）配置nacos地址

在​​user-service​​和​​order-service​​的​​application.yml​​中添加​​nacos​​地址：

spring: cloud: nacos: server-addr: localhost:8848

注意：不要忘了注释掉eureka的地址

3）重启

重启微服务后，登录nacos管理页面，可以看到微服务信息：

​​返回顶部​​

5.3 服务分级存储模型

一个服务可以有多个实例，例如我们的​​user-service​​，可以有:

127.0.0.1:8081127.0.0.1:8082127.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​​。

5.3.1 给user-service配置集群

集群默认的是​​Default​​，需要我们进行配置：

修改​​user-service​​的​​application.yml​​文件，添加集群配置：

spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ # 集群名称，模拟机房位置-杭州

重启两个​​user-service​​实例后，我们可以在​​nacos​​控制台看到下面结果：

我们再次复制一个​​user-service​​启动配置，添加属性：

-Dserver.port=8083 -Dspring.cloud.nacos.discovery.cluster-name=SH

配置如图所示：

启动​​UserApplication3​​后再次查看​​nacos​​控制台：

​​返回顶部​​

5.3.2 同集群优先的负载均衡

默认的​​ZoneAvoidanceRule​​并不能实现根据同集群优先来实现负载均衡。

因此​​Nacos​​中提供了一个​​NacosRule​​的实现，可以优先从同集群中挑选实例。

1）给​​order-service​​配置集群信息

修改​​order-service​​的​​application.yml​​文件，添加集群配置：

spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ # 集群名称

重新启动​​orderservice​​，在​​nacos​​中可以看到我们的​​orderservice​​被添加到了​​HZ​​集群中。

2）修改负载均衡规则

修改​​order-service​​的​​application.yml​​文件，修改负载均衡规则：

userservice: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则

可以看到，修改负载均衡规则后我们访问的三次结果。隶属于​​HZ​​集群的​​8081​​、​​8082​​端口服务实例均被使用到了，而隶属于​​SH​​的​​8083​​端口实例未被使用。

当我们关闭​​HZ​​集群的两个​​userservice​​，再次进行访问，此时只能使用​​SH​​集群的​​userservice​​，并且会报跨集群访问信息提示。

​​返回顶部​​

5.4 权重配置

实际部署中会出现这样的场景：

服务器设备性能有差异，部分实例所在机器性能较好，另一些较差，我们希望性能好的机器承担更多的用户请求。

但默认情况下​​NacosRule​​是同集群内随机挑选，不会考虑机器的性能问题。

因此，​​Nacos​​提供了​​权重配置​​来控制访问频率，权重越大则访问频率越高。

在弹出的编辑窗口，修改权重：

注意：如果权重修改为0，则该实例永远不会被访问

​​返回顶部​​

5.5 环境隔离

​​Nacos​​提供了​​namespace​​来实现环境隔离功能。

​​nacos​​​中可以有多个​​namespace​​​​namespace​​​下可以有​​group​​​、​​service​​等不同​​namespace​​​之间相互隔离，例如不同​​namespace​​的服务互相不可见

5.5.1 创建namespace

默认情况下，所有​​service​​、​​data​​、​​group​​都在同一个​​namespace​​，名为​​public​​：

然后，填写表单：

就能在页面看到一个新的​​namespace​​：

5.5.2 给微服务配置namespace

给微服务配置​​namespace​​只能通过修改配置来实现。

例如，修改​​order-service​​的​​application.yml​​文件：

spring: cloud: nacos: server-addr: localhost:8848 discovery: cluster-name: HZ namespace: 2f393f8f-03b5-4dee-bb34-d6d63aa8d4a4 # 命名空间，填ID

重启​​order-service​​后，访问控制台，可以看到下面的结果：

此时访问​​order-service​​，因为​​namespace​​不同，会导致找不到​​userservice​​，控制台会报错：

​​返回顶部​​

5.6 Nacos与Eureka的区别

Nacos的服务实例分为两种l类型：

临时实例：如果实例宕机超过一定时间，会从服务列表剔除，默认的类型。非临时实例：如果实例宕机，不会从服务列表剔除，也可以叫永久实例。

配置一个服务实例为永久实例：

spring: cloud: nacos: discovery: ephemeral: false # 设置为非临时实例

配置好后，我们将​​orderservice​​重启后并关闭，到浏览器查看状态。此时我们的非临时服务实例并没有被删除，依然保留，仅是不健康状态。

​​Nacos​​和​​Eureka​​整体结构类似，服务注册、服务拉取、心跳等待，但是也存在一些差异：

Nacos与eureka的共同点

都支持服务注册和服务拉取都支持服务提供者心跳方式做健康检测

Nacos与Eureka的区别

Nacos支持服务端主动检测提供者状态：临时实例采用心跳模式，非临时实例采用主动检测模式临时实例心跳不正常会被剔除，非临时实例则不会被剔除​​Nacos​​支持服务列表变更的消息推送模式，服务列表更新更及时​​Nacos​​​集群默认采用​​AP​​模式（数据可用性），当集群中存在非临时实例时，采用​​CP​​模式（数据可靠性、一致性）；​​Eureka​​​采用​​AP​​方式

​​返回顶部​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。