👨🎓作者简介:一位大四、研0学生,正在努力准备大四暑假的实习
🌌上期文章:详解SpringCloud微服务技术栈:强推!源码跟踪分析Ribbon负载均衡原理、Eureka服务部署
📚订阅专栏:微服务技术全家桶
希望文章对你们有所帮助
上一节已经使用Eureka实现了服务注册和服务发现,并给源码分析了Ribbon是如何进行负载均衡的,整个项目是如何进行服务拉取的等等。
Nacos也可以做到这一点,而且相对来说更常用。
Nacos
- 认识与安装Nacos(Windows版)
- Nacos快速入门
- 服务分级存储模型
- 服务跨集群调用问题
- NacosRule负载均衡
- 服务实例的权重设置
- 环境隔离——namespace
- Nacos与Eureka的对比
认识与安装Nacos(Windows版)
Nacos是阿里巴巴的产品,现在是SpringCloud的组件,比起上一节的Eureka,功能更加丰富,相对来讲更常用。
Nacos的安装,可以去官网下载,比较慢,这里提供了一个网盘的地址:
链接:https://pan.baidu.com/s/1XBShX7krth5RLlkGpTXFqw?pwd=lu54
提取码:lu54
安装完毕就直接解压到无中文的路径就可以了。
target里面是一个jar包,这就是一个基于java语言去实现的
conf是配置文件,里面的端口是8848,如果这个端口被占用了可以自行去做修改
bin是可执行文件
最简单的启动方式是点击startup.cmd,但是我这里是启动异常的,也可以进入cmd去用命令行启动:
startup.cmd -m standalone
-m表示model模式,standalone表示单机模式启动。
控制台的网址可以直接访问,进去以后登录的用户名和密码都是nacos:
提交,即可进入Nacos的控制台了:
至此,Nacos安装完毕。
Nacos快速入门
利用Nacos实现服务注册。
1、在cloud-demo父工程中添加spring-cloud-alibaba的管理依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-alibaba-dependencies</artifactId>
<version>2.2.5.RELEASE</version>
<type>pom</type>
<scope>import</scope>
</dependency>
2、注释order-service与user-service中关于Eureka的依赖。
3、添加nacos的客户端依赖:
<dependency>
<groupId>com.alibaba.cloud</groupId>
<artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
4、在Yaml配置文件中配置Nacos的服务地址,并且可以将之前Eureka的相关配置注释了。
重启服务,打开控制台能看到服务列表证明成功实现服务注册了:
这个页面看起来比Eureka的更直观一点,点进去也可以查看更详细的信息。
服务分级存储模型
其实分级存储的概念早就接触过了,demo中的服务是user-service以及order-service,这是一级,而user-service又有多个实例,分别有着不同的端口号,这实际上就是一种多级存储模型。
然后随着服务越来越大,实例可能也越来越多,为了防止危险,尽可能将实例存储到多个地方,这样即便发生问题也能减小损失。
若干个实例组成的即为集群。
分级存储模型:服务-集群-实例
服务跨集群调用问题
服务之间的调用(比如order-service调用user-service),可以在一个集群内访问实例,也可以跨集群,即访问其他集群的实例。
服务调用的时候需要尽量满足:
1、服务调用尽可能选择本地集群的服务,跨集群调用延迟较高
2、本地集群不可访问时,再去访问其它集群
而打开Nacos,可以看到实习并不在特定集群中,因此需要手动配置集群的属性。
1、修改application.yml,添加如下内容:
将2台实例启动,相当于将这两台集群放入了湖中大集群:
修改一下配置:
这时候启动UserApplication3,就相当于将这台实例放入了NUAA集群了:
2、在Nacos控制台可以看到2集群,3实例:
NacosRule负载均衡
修改配置,使得当运行order-service的时候,优先去调用本地的集群。
先给order-service配置集群,配置到HNUCM,重启orderService。
多次访问网址:http://localhost:8080/order/101 或者102、103等等。
可以发现8083端口进行了数据库查询的操作:
这说明了,目前的负载均衡只考虑了实例,没有考虑集群。
解决方法:在order-service中设置负载均衡的IRule为NacosRule,这个规则会优先寻找与自己同集群的服务:
userservice:
ribbon:
NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 负载均衡规则
重启order-service,不会再访问8083端口,且8081与8082的选择是一种随机方式的访问,而不是轮询方式。
把8081端口和8082端口的实例停止,再次刷新order的访问网址,将会在端口8083进行访问,同时我们可以打开orderApplication的控制台,可以发现发出了警告WARN:
显示了这是跨集群的访问。
服务实例的权重设置
实际部署的时候会遇到这样的场景:
服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们自然是希望性能好的机器承担更多的请求
而Nacos提供了权重配置来控制访问的频率,权重越大则频率越高。
在Nacos控制台可以看到权重都是默认为1的,我们可以编辑权重(范围为0到1),将8081端口的权重设置为0.1,自行测试就可以发现其被访问的频率就大大降低了。
权重调成0的时候,这个实例根本就不会被调用,这种情况比较常见在实例版本的升级的时候,这时候就可以讲这个实例的权重调成0,版本升级完成以后再添加权重。
环境隔离——namespace
Nacos中服务存储和数据存储的最外层都是一个名为namespace的东西,用来做最外层隔离。其内部可以分组Group,Group内就是具体的服务-集群-实例了。
也就是说,环境隔离namespace就是在对服务做隔离,而这里的Group是将相关度比较高的服务进行分组。
当我们没有配置的情况下,服务都是在public的命令空间下的:
可以创建新的命名空间:
要将服务放入一个命名空间,需要修改代码:
修改order-service的application.yml,添加namespace:
重启后可以看到它放在了dev的命名空间里了。
同时,这时候无法再访问8081、8082、8083的内容了。
总结:
1、namespace用来做环境隔离
2、每个namespace都有唯一id
3、不同namespace下的服务不可见
Nacos与Eureka的对比
在做服务注册和服务发现的时候,Nacos与Eureka的过程都是差不多的,即:
1、服务提供者在注册中心注册服务信息
2、服务消费者会定时向注册中心拉取服务
3、拉取到的服务会存入服务列表缓存,提高效率
4、服务消费者对服务提供者实行负载均衡的远程调用
Nacos与Eureka的区别体现在下面几点:
1、健康检测
为了让消费者在远程调用的时候能够调用正常健康的提供者,服务的提供者需要在注册中心进行健康检测,Eureka的方式是心跳检测,而Nacos却有些不一样。
1、服务提供者的实例分为临时实例和非临时实例(永久),只有临时实例会采用心跳检测来体现健康状况,当不健康的话,Nacos会将该实例从服务列表中剔除
2、对于非临时实例,Nacos会主动进行询问,询问是否健康,若不健康,Nacos也不会将该实例从服务列表中剔除,而仅仅是标记为不健康,直到它恢复健康
2、服务列表缓存
Eureka只使用了pull方式进行缓存更新,效率较慢,而Nacos是采用了pull/push(消息推送)结合的方式,当有宕机的情况出现的时候,Nacos会迅速的将该消息push给它
服务注册到Nacos时,可以选择注册为临时实例还是非临时实例,通过下面的配置来设置:
如果把服务关机,将会迅速查出不健康,但是服务列表中,该服务永远存在。
总结:
1、共同点
(1)支持服务注册和服务拉取
(2)都支持服务提供者心跳方式做健康检测
2、不同点:
(1)Nacos支持服务端主动检测提供者的状态:临时实例用心跳模式,非临时实例采用主动检测模式,但是这种方式压力会更大一点
(2)临时实例心跳不正常会被剔除,非临时实例则不会被剔除
(3)Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
(4)Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP方式;Eureka只能采用AP方式(暂时没学这方面内容,只能大致知道CP方式更强调数据的一致性和可靠性,因此当有非临时实例的时候需要转换为CP方式)