主要讲解Nacos的概念, 安装, 注册服务
一、注册中心-Nacos
什么是注册中心
注册中心的存在是为了更好更方便的管理应用中的每⼀个服务,是各个分布式节点之间的纽带。注册中心主要提供以下核心功能:
-
服务注册与发现:动态的增减服务节点,服务节点增减后动态的通知服务消费者,而不需要由消费者来更新配置。
-
服务配置:动态修改服务配置,并将其推送到服务提供者和服务消费者而不需要重启服务。
-
健康检查和服务摘除:主动的检查服务健康情况,对于宕机的服务将其摘除服务列表。
Nacos是什么?
Nacos是⼀个开源的分布式服务发现和配置管理平台,它可以帮助开发者更好地管理微服务架构中的服务实例和配置信息。Nacos最初由阿里巴巴开发并开源,⽬前已经成为Apache基金会的顶级项⽬之⼀。
Nacos提供了以下核心功能:
-
服务发现:Nacos可以实时感知服务实例的上下线变化,支持多种服务注册方式,包括REST、DNS和RPC等。
-
配置管理:Nacos可以集中管理所有微服务的配置信息,支持动态配置更新和多种配置格式,如JSON、XML和YAML等。
-
服务路由与负载均衡:Nacos可以根据多种策略进⾏服务路由和负载均衡,如轮询、随机和加权等。
-
服务健康检查:Nacos可以对服务实例进行心跳检测和健康状态检查,及时发现异常实例并剔除。
-
DNS服务:Nacos提供了⼀个内置的DNS服务,可以通过DNS协议直接访问微服务实例。
Nacos 2相比于之前的版本,主要增加了以下特性:
-
分布式配置集群:支持将配置信息分布到多个Nacos节点上进行管理,提高了配置的可靠性和可用性。
-
自动拉取配置:Nacos可以自动拉取外部配置中心的配置信息,并将其同步到本地,保证配置的⼀致性和实时性。
-
数据持久化支持:支持多种数据存储方式,包括MySQL、Oracle和TiDB等,同时支持数据备份和恢复。
-
更好的性能和可伸缩性:Nacos 2优化了核心组件的性能和可伸缩性,支持更高的并发量和更大规模的集群部署。
Nacos能做啥?
-
服务发现(注册中心)和服务健康监测
-
动态配置服务
-
动态 DNS 服务
-
服务及其元数据管理
Nacos的示意图
Nacos就是微服务体系下的"工商局",对整个微服务进行注册登记与健康检查
Nacos安装部署
下载地址 : 项目目录预览 - nacos - GitCode
直接点克隆: 再选择系统类型
第一步:上传Nacos压缩包
第二步:解压Nacos压缩包
第三步:修改/opt/module/nacos/conf下的application.properties全局配置文件,开启登录鉴权。
第四步:启动Nacos
其中-m表示启动模式。
第五步:进入Nacos的控制台:http://192.168.10.111:8848/nacos
输入默认的账号密码
四、使用Nacos
为了学习Nacos,我们准备两个微服务模块。微服务的拆分要与现实中的业务以及开发/运营团队绑定,一个团队可以同时维护多个微服务,而一个微服务只能有独立的一个团队负责。
这里准备 ”文章服务“ 和 ”视频服务“ 两个微服务例子。
1、实现视频服务
1.1、创建一个video-service项目
1.2、编写application.yml配置文件
记得删除原有的application.properties文件!!!
1.3、书写代码
编写实体类
编写mapper接口
编写service
编写controller
1.4、运行视频服务
运行项目后,在控制台输出的日志中,含有如下信息
打开nacos控制台,显示我们刚刚注册的video-service。
在浏览器中输入:http://localhost:8001/video?articleId=1648
2、实现文章服务
2.1、创建一个article-service项目
略
2.2、编写application.yml配置文件
记得删除原有的application.properties文件!!!
2.3、书写代码
编写实体类
编写mapper接口
编写service
编写controller
2.4、运行视频服务
五、基于OpenFeign实现服务间通信
Feign与OpenFeign
-
Feign是一个开源声明式WebService客户端,用于简化服务通信
-
Feign采用“接口+注解”方式开发,屏蔽了网络通信的细节
-
OpenFeign是SpringCloud对Feign的增强,用于简化Feign开发
在文章服务中引入依赖:
在Application应用入口增加@EnableFeignClients
准备实体类,直接从视频服务中copy一个Video实体类即可
创建接口,定义传输细节
通过测试用例验证通信
注意:需要将 ”视频服务“ 和 ”文章服务“ 注册到Nacos!!!
拓展
Nacos 2.x架构设计与重要变化
⽬前Nacos⽀持主流微服务开发语⾔&主流服务框架和配置管理框架,⽐如⽀持Duboo、SpringCloud、SCA,还对接了⼀些云原⽣的组件⽐如coreDNS和sentinel等。客户端语⾔⽅⾯⽬前⽀持 Java,Go,Python 等主流语⾔,最近刚发布正式版本的还⽀持 C# 和 C++。
Nacos 2.X 版本在 1.X 的架构基础上新增了对⻓连接模型的⽀持。通信层⽬前通过grpc实现了⻓连接RPC调⽤和推送能⼒,使⽤⻓链接的好处⼤幅度减少了 1.x 轮询⼼跳频繁导致JVM Full GC。
Nacos 2.x解决了什么问题?
Nacos 1.x 版本 Config/Naming 模块各⾃的推送通道都是按照⾃⼰的设计模型来实现的。
由于配置和服务器模块的数据推送通道不统⼀,http 短连接性能压⼒巨⼤,未来 Nacos 需要构建能够同时⽀持配置以及服务的⻓链接通道,以标准的通信模型重构推送通道。
Nacos 1.x 版本带来的问题
● ⼼跳数量多,导致TPS居⾼不下
通过⼼跳续约,当服务规模上升时,特别是类似Dubbo的接⼝级服务较多时,⼼跳及配置元数据的轮询数量众多,导致集群TPS很⾼,系统资源⾼度空耗。
● 通过⼼跳续约感知服务变化,时延⻓
⼼跳续约需要达到超时时间才会移除并通知订阅者,默认为15s,时延较⻓,时效性差。若改短超时时间,当⽹络抖动时,会频繁触发变更推送,对客户端服务端都有更⼤损耗。
● UDP推送不可靠,导致QPS居⾼不下
由于UDP不可靠,因此客户端测需要每隔⼀段时间进⾏对账查询,保证客户端缓存的服务列表的状态正确,当订阅客户端规模上升时,集群QPS很⾼,但⼤多数服务列表其实不会频繁改变,造成⽆效查询,从⽽存在资源空耗。
● 基于HTTP短连接模型,TIME_WAIT状态连接过多
HTTP短连接模型,每次客户端请求都会创建和销毁TCP链接,TCP协议销毁的链接状态是WAIT_TIME,完全释放还需要⼀定时间,当TPS和QPS较⾼时,服务端和客户端可能有⼤量的WAIT_TIME状态链接,从⽽会导致connect time out错误或者Cannot assign requested address 的问题。
● 配置模块的30秒⻓轮询引起的频繁GC
配置模块使⽤HTTP短连接阻塞模型来模拟⻓连接通信,但是由于并⾮真实的⻓连接模型,因此每30秒需要进⾏⼀次请求和数据的上下⽂切换,每⼀次切换都有引起造成⼀次内存浪费,从⽽导致服务端频繁GC。
Nacos 2.x版本
2.x架构升级为⻓连接模型,在通信层通过gRPC和RSocket实现⻓连接数据传输和推送能⼒,在连接层新增加请求处理器、流控和负载均衡等功能:
● 应⽤POD按照⻓连接维度进⾏⼼跳续约,不需要按照实例级,⼤⼤降低重复请求
● ⻓连接断开时可以快速感知到,不⽤等待续约超时时⻓就可以移除实例
● NIO流式推送机制相对于UDP更可靠,并且可以降低应⽤对账数据频率
● 没有反复创建连接的开销,⼤幅降低TIME_WAIT连接多问题
● ⻓连接也解决了配置模块⻓轮询CMS GC问题
2.0架构带来的问题
● 相对于Tomcat HTTP短连接模型,⻓连接模型需要⾃⼰管理连接状态,增加了复杂性
● ⻓连接gRPC基于HTTP2.0 Stream,相对于HTTP的open API可观测性和易⽤性降低了
2.x架构整体来说降低了资源开销,提⾼了系统吞吐量,在性能上有⼤幅提升,但同时也增加了复杂度
Nacos 2.x版本的性能
2 核 CPU+4G 内存的三节点集群在不同版本下的性能差异:
由此可⻅,Nacos 2.0 确实对性能有较⼤的提升,新⽤户建议直接全部采⽤ Nacos 2.0,⽼⽤户建议先升级 Server 端,然后在逐步升级客户端释放红利。最后从整个压测视⻆的监控,来直观的感受⼀下不同版本在不同阶段的性能表现: