硬核神作|万字带速通Nacos
目录
Nacos注册中心
基本介绍
概述
国内公司一般都推崇阿里巴巴的技术,比如注册中心,SpringCloudAlibaba也推出了一个名为Nacos的注册中心。
Nacos是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。Nacos就是注册中心 + 配置中心的组合Nacos = Eureka+Config +Bus
Nacos的前四个字母分别为Naming和Configuration的前两个字母,最后的s为Service。
Nacos: Dynamic Naming and Configuration Service
特性
- 易于使用 :动态配置管理、服务发现和动态的一站式解决方案 ,20多种开箱即用的以服务为中心的架构特性 ,基本符合生产要求的轻量级易用控制台
- 更适应云架构: 无缝支持Kubernetes和Spring Cloud 在主流公共云上更容易部署和运行(例如阿里云和AWS)多租户和多环境支持
- 生产等级: 脱胎于历经阿里巴巴10年生产验证的内部产品 ,支持具有数百万服务的大规模场景, 具备企业级SLA的开源产品
- 丰富的应用场景: 支持限流、大促销预案和异地多活 ,直接支持或稍作扩展即可支持大量有用的互联网应用场景 ,流量调度和服务治理
服务注册中心 (Service Registry)
服务注册中心,它是服务,其实例及元数据的数据库。服务实例在启动时注册到服务注册表,并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。
Nacos 支持将注册中心(Service Registry)与配置中心(Config Center) 在一个进程合并部署或者将2者分离部署的两种模式。
Nacos服务分级存储模型
所谓多级存储模型就是把一个服务的多个实例放在不同的集群。Nacos的服务分级里面 : 1级是服务, 2级是集群, 3级是实例。
微服务互相访问时,应该尽可能访问同集群实例,因为本地访问速度更快。当本集群内不可用时,才访问其它集群。
比如,现在有四个服务器,服务器1为在广州的订单服务实例,服务2为在广州会员服务示例,服务器3为在湛江的订单服务实例,服务4为在湛江会员服务示例,将服务器1,2作为一个集群放在广州,将服务器3,4作为一个集群放在湛江,如下图所示:
当用户使用订单服务去调用会员服务,如果访问的服务器1应访问服务器2,而不是去访问服务器4。在java代码工程中对于不同集群的划分设置为:
默认的ZoneAvoidanceRule
并不能实现根据同集群优先来实现负载均衡。因此Nacos中提供了一个NacosRule
的实现,可以优先从同集群中挑选实例。修改负载均衡规则:
Nacos权重配置
服务器设备性能有差异,部分实例所在机器性能较好,另一些较差,我们希望性能好的机器承担更多的用户请求。但默认情况下NacosRule是同集群内随机挑选,不会考虑机器的性能问题。因此,Nacos提供了权重配置来控制访问频率,权重越大则访问频率越高。在nacos控制台,找到user-service的实例列表,点击编辑,即可修改权重:
在弹出的编辑窗口,修改权重:
注意:如果权重修改为0,则该实例永远不会被访问
Nacos环境隔离
Nacos提供了namespace来实现环境隔离功能。
-
nacos中可以有多个namespace
-
namespace下可以有group、service等
-
不同namespace之间相互隔离,例如不同namespace的服务互相不可见
Nacos与Eureka的区别
Nacos的服务实例分为两种l类型:
-
临时实例:如果实例宕机超过一定时间,会从服务列表剔除,默认的类型。
-
非临时实例:如果实例宕机,不会从服务列表剔除,也可以叫永久实例。
配置一个服务实例为永久实例:
-
Nacos与eureka的共同点
-
都支持服务注册和服务拉取
-
都支持服务提供者心跳方式做健康检测
-
-
Nacos与Eureka的区别
-
Nacos支持服务端主动检测提供者状态:临时实例采用心跳模式,非临时实例采用主动检测模式
-
临时实例心跳不正常会被剔除,非临时实例则不会被剔除
-
Nacos支持服务列表变更的消息推送模式,服务列表更新更及时
-
Nacos集群默认采用AP方式,当集群中存在非临时实例时,采用CP模式;Eureka采用AP方式
-
Java代码实战
实战架构
俩个为俩个不同的端口的service端,客户端向8002端口的studentservice发送一个请求(/getInfo)以后,8002端口的studentservice需要往teacherservice发送一个请求(/getTeacher)返回数据。
父工程pom文件
student-service服务
pom文件
Application 程序
RestTemplate是Spring提供的用于访问Rest服务的客户端,RestTemplate提供了多种便捷访问远程Http服务的方法,能够大大提高客户端的编写效率。
使用restTemplate访问restful接口非常的简单粗暴无脑。
(url, requestMap, ResponseBean.class)这三个参数分别代表
REST请求地址、请求参数、HTTP响应转换被转换成的对象类型。
yml配置文件
Teacher类
StudentController
teacher-service服务
pom文件
Application 程序
yml配置文件
Teacher类
StudentController
测试
浏览器访问:http://localhost:8082/getInfo
Nacos配置管理
基本介绍
概述
Nacos除了可以做注册中心,同样可以做配置管理来使用。
所谓配置中心:一般SpringBoot项目都使用在resources下创建类似
application.yml
之类的配置文件来管理整个项目的一些配置信息
当微服务部署的实例越来越多,达到数十、数百时,逐个修改微服务配置就会让人抓狂,而且很容易出错。我们需要一种统一配置管理方案,可以集中管理所有实例的配置。
采用本地静态配置,无法保证实时性:修改配置不灵活且需要经过较长的测试发布周期,无法尽快通知到客户端,还有些配置对实时性要求很高,比方说主备切换配置或者碰上故障需要修改配置,这时通过传统的静态配置或者重新发布的方式去配置,那么响应速度是非常慢的,业务风险非常大
动态配置服务
- 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
- 动态配置消除了配置变更时重新部署应用和服务的需要,让配置管理变得更加高效和敏捷。
- 配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。 Nacos 提供了一个简洁易用的UI (控制台样例 Demo) 帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性,帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。
多配置格式编辑器
Nacos支持 YAML、Properties、TEXT、JSON、XML、HTML 等常见配置格式在线编辑、语法高亮、格式校验,帮助用户高效编辑的同时大幅降低格式错误带来的风险。
Nacos支持配置标签的能力,帮助用户更好、更灵活的做到基于标签的配置分类及管理。同时支持用户对配置及其变更进行描述,方便多人或者跨团队协作管理配置。
微服务拉取配置流程
微服务要拉取nacos中管理的配置,并且与本地的application.yml配置合并,才能完成项目启动。但如果尚未读取application.yml,又如何得知nacos地址呢?
因此spring引入了一种新的配置文件:bootstrap.yaml文件,会在application.yml之前被读取
springboot中配置文件的加载是存在优先级顺序的,bootstrap优先级高于application
Data ID
公式:${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}
- prefix 默认为 spring.application.name 的值
- spring.profile.active 即为当前环境对应的 profile,可以通过配置项 spring.profile.active 来配置。
- file-exetension 为配置内容的数据格式,可以通过配置项 spring.cloud.nacos.config.file-extension 来配置
通俗一点就是 “前缀-环境-扩展名”
@RefreshScope
SpringCloud 使用 @RefreshScope
注解,实现配置文件的动态加载。 @RefreshScope 注解是一个基于 Spring Cloud Config 的注解。它允许 Spring Boot 应用程序在运行时动态地刷新配置,而无需重启应用程序。使用 @RefreshScope 注解,可以在不停止应用程序的情况下修改配置。
在 Spring Boot 中,@RefreshScope 注解是基于 Spring Cloud Config 实现的。Spring Cloud Config 是一个用于集中化配置管理的工具。它可以将配置存储在 Git、SVN 或本地文件系统中,并将其提供给多个应用程序。
当应用程序中使用了 @RefreshScope 注解时,Spring Boot 将会监控配置文件的变化。当配置文件发生变化时,Spring Boot 将会重新加载配置并重新初始化相关的 Bean。这样,就可以在应用程序运行时动态地修改配置。
配置共享的优先级
当nacos、服务本地同时出现相同属性时,优先级有高低之分:
实战使用
简单的共享配置
不区分工作环境,即不设置profiles.active,则在Nacos中的配置文件只需要spring.application.name.spring.cloud.nacos.config.file-extension
代码示例:
pom主要依赖
bootstrap.yaml
application.yaml
controller配置类
启动项目以后可以访问下/version得到的是kkk
在Nacos中创建一个配置文件名为:
发布以后再次访问/version得到是yy
开发环境的共享配置
实际开发中,通常一个系统会准备
- dev开发环境
- test测试环境
- prod生产环境。
如何保证指定环境启动时服务能正确读取到Nacos上相应环境的配置文件呢?
我们只要区分工作环境,这次需要设置profiles.active。
修改bootstrap.yaml文件
在Nacos中创建一个配置文件名为:
发布以后再次访问/version得到是wwww
环境隔离-命名空间Namespace
一个大型分布式微服务系统会有很多微服务子项目,每个微服务项目又都会有相应的开发环境、测试环境、预发环境、正式环境,那怎么对这些微服务配置进行管理呢?
Nacos 引入命名空间 Namespace 的概念来进行多环境配置和服务的管理及隔离。例如,你可能存在本地开发环境dev、测试环境test、生产环境prod 三个不同的环境,那么可以创建三个不同的 Namespace 区分不同的环境。
成功创建新命名空间后,就可以在 springboot 的配置文件配置命名空间的 id 切换到对应的命名空间,并获取对应空间下的配置文件,但在没有指定命名空间配置的情况下,默认的配置都是在 public 空间中,指定命名空间的方式如下:
业务隔离-Group分组
Group 也可以实现环境隔离的功能,但 Group 设计的目的主要是做同一个环境中的不同服务分组,把不同的微服务的配置文件划分到同一个分组里面去,Nacos 如果不指定 Group,则默认的分组是 DEFAULT_GROUP。
- 点赞
- 收藏
- 关注作者
评论(0)