1.1:nacos分级存储是什么
1.3:为什么nacos 要引入这么一个服务分级
1.3.1:服务跨集群调用问题
2.1.1:修改文件yml,添加如下内容:
2.1.2:在Nacos控制台可以看到集群变化:
这个服务分级存储模型概念听起来很高级,下面咱们仔细分析一波!!!
服务:之前有服务的概念,之前有user-service 用户服务,和order-service的订单服务,这些都称之为服务。
问题出现:
一个服务可以包含多个实例,不过随着业务规模越来越大那么我们就会考虑更多的问题,比如说你把所有的实例都部署在一个机房,就像鸡蛋放在篮子里面,哪天篮子打翻了,鸡蛋不也就完了,由小比大,把多个实例都放在一个机房,万一机房失火了,断电了,等等因素导致机房罢工了,那么全部的实例都停止,这个服务不也就挂机了嘛!
而我们nacos分级存储模型就是引入了这样一个机房或者说地域的概念
为此也部署了多个实例,像8081,8082,8083,等等,便于下文演示[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传
** 而什么又是集群呢!** 如下图,在上海部署了两个实例,在杭州部署有两个实例,而nacos把同在一个机房中的多个实例称之为:集群,在杭州那就被称之为杭州的user-service集群,在北京的就称之为北京的user-service集群。
那么问题有来了,为什么nacos 要引入这么一个服务分级?为什么非要多加个集群的概念,我直接服务找实例不好嘛?
比方说有个杭州机房,里面有user-service集群,order-service集群,在上海,北京的机房中也同样有这种配置,现在order-service需要访问user-service,那么现在有两种方式访问:第一种访问本地局域网的,另外一种访问,上海或者北京的机房的user-service,那肯定选本地集群,因为局域网内的访问呢!速度快,延迟低,而跨越集群的访问比如访问上海的集群,那肯定延迟就要高了。
所以用集群的方式,把上海的实例,归纳为上海集群,把北京的实例,归纳为北京集群,优先访问同一个集群中的实例
杭州机房内的order-service应该优先访问同机房的user-service。
nacos引入这个分级概念就是为了防止跨集群进行访问或者说是尽可能的避免
如图这边我开启三个实例
查看一下服务中实例的详情信息,可以发现集群默认为DEFAULT
下面给三个实例,分别设为(北京集群),SH(上海集群)
第一个修改了application.yml文件的集群配置:设置该实例在BJ集群
#端口号
server:
port: 8888
spring:
application:
name: service-provider #服务名
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #nacos服务地址
cluster-name: BJ #配置集群名称,也就是机房位置,例如:BJ,北京
第二个修改了application-8081.yml文件的集群配置:设置该实例在JS集群
#server.port=8070
#spring.application.name=service-provider
#spring.cloud.nacos.discovery.server-addr=127.0.0.1:8848
#端口号
server:
port: 8170
spring:
application:
name: service-provider #服务名
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #nacos服务地址
cluster-name: JS #配置集群名称,也就是机房位置,例如:JS,江苏
第三个修改了application-8082.yml文件的集群配置:设置该实例在JS集群
server:
port: 8270
spring:
application:
name: service-provider #服务名
cloud:
nacos:
discovery:
server-addr: 127.0.0.1:8848 #nacos服务地址
cluster-name: JS #配置集群名称,也就是机房位置,例如:JS,江苏
注意:
这两个yml文件的激活,修改启动项
-Dspring.profiles.active=8081
查看一下详情: