Spring Cloud Alibaba 微服务框架 Nacos:微服务注册中心和配置中心
2022-05-21 12:08:52 0 举报
AI智能生成
Spring Cloud Alibaba 微服务框架 Nacos 微服务注册中心和配置中心
作者其他创作
大纲/内容
服务地址的管理
服务注册
服务动态感知
注册中心
图片
Provider:服务提供者
Consumer:服务消费者
Name Server:通过VIP(Vritual IP)或者DNS的方式实现Nacos高可用集群的服务路由
Open API
Config Service
Naming Service
Consistency Protocol:用来实现Nacos集群节点的数据同步,这里使用的是Raft算法
Nacos Server:Nacos服务提供者
Nacos Console
架构图
Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI或一个独立的Agent TODO注册Service后,服务消费者可以使用DNS或HTTP&API查找和发现服务。
Nacos提供对服务的实时的健康检查,阻止向不健康的主机或服务实例发送请求。Nacos支持传输层(PING或TCP)和应用层(如HTTP、MySQL、用户自定义)的健康检查。
Nacos提供了agent上报和服务端主动检测两种健康检查模式。
Nacos提供了统一的健康检查仪表盘,帮助用户根据健康状态管理服务的可用性及流量。
服务发现和服务健康监测
动态配置服务可以以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置,可以使配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单,让服务按需弹性扩展变得更容易。
还提供了包括配置版本跟踪、金丝雀发布、一键回滚配置及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性,帮助用户更安全地在生产环境中管理配置变更,降低配置变更带来的风险。
提供了一个简洁易用的UI帮助用户管理所有服务和应用的配置
动态配置服务
动态DNS服务支持权重路由,让开发者更容易地实现中间层负载均衡、更灵活的路由策略、流量控制,以及数据中心内网的简单DNS解析服务。
动态DNS服务
Nacos可以使开发者从微服务平台建设的视角管理数据中心的所有服务及元数据, 包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策
服务及其元数据管理
关键特性
单机:用于测试和单机试用
部署架构图
http://ip1:port/openAPI 直连ip模式,机器挂则需要修改ip才可以使用
http://VIP:port/openAPI 挂载VIP模式,直连vip即可,下面挂server真实ip,可读性不好
http://nacos.com:port/openAPI域名 + VIP模式,可读性好,而且换ip方便,推荐模式
部署说明
环境准备
下载源码或者安装包
在nacos的解压目录nacos/的conf目录下
有配置文件cluster.conf,请每行配置成ip:port
请配置3个或3个以上节点
配置集群配置文件
无需进行任何配置
使用内置数据源
超链接
初始化 MySQL 数据库
application.properties 配置
使用外置数据源
确定数据源
独立模式
集群模式
启动服务器
部署步骤
集群:用于生产环境,确保高可用
解决方案:使用Nacos-Sync 组件来做数据中心之间的数据同步
多集群:用于多数据中心场景
部署模式
Nacos数据模型
Nacos服务分级存储模型
Nacos配置实体模型
数据模型
Nacos提供了SDK及Open API的方式来完成服务注册与发现等操作,由于服务端只提供了REST接口,所以SDK本质上是对于HTTP请求的封装
通过@NacosInjected注入Nacos的NamingService,并提供discovery方法,可以根据服务名称获得注册到Nacos上的服务地址。
API说明
使用客户端上报模式进行健康检查
临时实例需要nacos能够自动摘除不健康实例,而且无需持久化存储实例,那么这种实例就适用于类 Gossip 的协议
临时实例
使用服务端反向探测模式进行健康检查
因为客户端不会上报心跳,nacos不能自动摘除下线的实例
持久化实例
一些基础的组件例如数据库、缓存等,这些往往不能上报心跳,这种类型的服务在注册时,就需要作为持久化实例注册
上层的业务服务,例如微服务或者 Dubbo 服务,服务的 Provider 端支持添加汇报心跳的逻辑,此时就可以使用动态服务的注册方式
相关场景
服务实例
流程图
TTL机制:就是如果客户端在一定时间内没有向注册中心发送心跳,则会将这个客户端摘除(Zookeeper 和 Eureka都支持)
Nacos 目前支持临时实例使用心跳上报方式维持活性
发送心跳的周期默认是 5 秒,Nacos 服务端会在 15 秒没收到心跳后将实例设置为不健康
在 30 秒没收到心跳时将这个临时实例摘除
nacos的TTL机制
关注点:关注客户端上报心跳的方式、服务端摘除不健康客户端的机制
简单
只需要等待心跳,然后刷新 TTL
nacos可以随时摘除不健康实例,减轻服务端的压力
复杂度
客户端健康检查
使用场景:服务无法上报心跳,但是可以提供一个检测接口,由外部去探测
关注点:关注探测客户端的方式、灵敏度及设置客户端健康状态的机制
复杂
需要服务端根据注册服务配置的健康检查方式,去执行相应的接口,判断相应的返回结果,并做好重试机制和线程池的管理
nacos无法摘除不健康实例,这意味着只要注册过的服务实例,如果不调用接口主动注销,这些服务实例都需要去维持健康检查的探测任务
TCP 端口探测
HTTP 接口返回码探测
检查方式
服务端健康检查
nacos同时支持客户端和服务端的健康检查
检查机制
健康检查
Nacos提供了类似于ZooKeeper的集群架构,包含一个Leader节点和多个Follower节点
和ZooKeeper不同的是,它的数据一致性算法采用的是Raft
高可用部署
服务实例在启动时注册到服务注册表,并在关闭时注销。
服务消费者查询服务注册表,获得可用实例。
服务注册中心需要调用服务实例的健康检查API来验证它是否能够处理请求。
注册中心原理
eureka是一个AP的服务注册中心
任何一个Eureka Server都是独立的,可存储所有的服务注册信息
即使任意一台Eureka Server宕机,其余的机器都可以照常工作
保证高可用性,但是不保证数据是一致的
eureka
zookeeper是一个CP的服务注册中心
所有的服务注册信息都存储在leader的机器上,同步给其他的follewer
若leader宕机,则不能提供服务注册的功能了,需要重新选举
保证强一致性,无法保证高可用性
zookeeper
nacos在 1.0.0 正式支持 AP 和 CP 两种一致性协议并存
一个是基于简化的 Raft 的 CP 一致性,一个是基于自研协议 Distro 的 AP 一致性
Raft 协议基于 Leader 进行写入,其 CP 也并不是严格的,只是能保证一半所见一致,以及数据的丢失概率较小
Distro 协议则是参考了内部 ConfigServer 和开源 Eureka,在不借助第三方存储的情况下,实现基本大同小异
nacos
eureka所有的服务实例在每一台Eureka Server中都保存了
大量的服务实例会产生大量的心跳检测等信息,导致Eureka Server无法支持高并发的操作
Eureka不能支持大量的服务实例的原因
zookeeper会将服务实例的上线下线通知到每一个服务实例
如果频繁的上下线的话,会去通知大量的服务实例,导致短时间网络压力增大,性能下降
Zookeeper不能支持大量的服务实例的原因
其他
相关中间件对比
Nacos 注册中心的设计原理详解
Nacos 注册配置中心介绍
Nacos 服务注册与发现原理分析
参考资料
Nacos之注册中心
配置的动态更新:在实际应用中会有动态更新配置的需求,在传统模式下,需要手动修改配置文件并且重启应用才能生效,这种方式效率太低,重启也会导致服务暂时不可用
配置集中式管理:微服务架构中部署的节点很多,一旦配置文件中的某个属性需要修改,本地配置的方式修改工作量是巨大的
配置内容的安全性和权限:配置文件随着源代码统一提交到代码库中,容易造成生产环境配置信息的数据泄露
不同部署环境下配置的管理:通过profile机制来管理不同环境下的配置,这种方式对于日常维护来说比较烦琐
本地配置方式的不足
添加Nacos Config的spring-boot-starter依赖
在application.properties中添加Nacos Server的地址
创建NacosConfigController类,用于从Nacos Server动态读取配置
@NacosPropertySource:用于加载dataId为example的配置源,autoRefreshed表示开启自动更新
@NacosValue:设置属性的值,其中info表示key,而Local Hello World代表默认值。也就是说,如果key不存在,则使用默认值。这是一种高可用的策略,在实际应用中,我们需要尽可能考虑到在配置中心不可用的情况下如何保证服务的可用性
Nacos读取配置的两个注解说明
Nacos集成Spring Boot实现统一配置管理
添加Nacos Config的spring-cloud-starter依赖
创建bootstrap.properties文件,并在bootstrap.properties中添加Nacos Server的连接地址
在Nacos Console中创建如下配置
在启动类中,读取配置中心的数据
Nacos集成Spring Cloud实现统一配置管理
默认加载DataId=${spring.application.name}.${file-extension:properties}为前缀的基础配置
如果明确指定了spring.cloud.nacos.config.prefix=example属性,则会加载DataId=example的配置
spring.profile.active表示多环境支持
默认规则 :${prefix}-${spring.profile.active}.${file-extension}
在bootstrap.properties中声明 spring.cloud.nacos.config.file-extension=yaml
在Nacos控制台上增加配置:Data ID:spring-cloud-nacos-config-sample.yaml
提供了YAML配置格式支持
先加载 ${spring.application.name}.${file-extension:properties}的基础配置(多个环境共同配置)
再加载 ${spring.application.name}-${profile}.${file-extension:properties}的基础配置(每个环境独有配置)
要加载的配置文件
通过-Dspring.profiles.active=${profile}启动可以动态控制要加载的环境配置
DataId配置加载规则
Nacos配置数据模型
默认值:public
解决多环境及多租户数据的隔离问题
在不同的Namespace下,可以存在相同的Group或DataId
Namespace
默认值:DEFAULT_GROUP
用来实现DataId分组管理的机制
可以实现不同环境下的DataId的分组,也可以实现不同应用或者组件下使用相同配置类型的分组
专注在业务层面的数据分组
Group
是Nacos中某个配置集的ID,它通常用于组织划分系统的配置集(应用配置)
示例
spring.cloud.nacos.config.ext-config[n]支持多个Data ID的扩展配置,包含三个属性:data-id、group、refresh
spring.cloud.nacos.config.ext-config[n].data-id指定Nacos Config的Data ID
spring.cloud.nacos.config.ext-config[n].group指定Data ID所在的组
spring.cloud.nacos.config.ext-config[n].refresh控制Data ID在配置发生变更时是否动态刷新,以感知最新的配置值。默认是false,也就是不会实现动态刷新
配置说明
spring.cloud.nacos.config.ext-config[n].data-id的值必须要带文件的扩展名,可以支持properties、yaml、json等
spring.cloud.nacos.config.ext-config[n].data-id配置多个Data ID时,n 的值越大,优先级越高
在ext-config和${spring.application.name}.${file-extension:properties}都存在的情况下,优先级高的是后者
注意点
可以解决多个应用的配置共享问题
优点
自定义扩展DataId配置
DataId
Namespace和Group使用说明
获取配置:从Nacos Config Server中读取配置
监听配置:订阅感兴趣的配置,当配置发生变化时可以收到一个事件
发布配置:将配置保存到Nacos Config Server中
删除配置:删除配置中心的指定配置
配置管理的4种操作
原理图
本质上就是调用Nacos Server的OpenAPI
配置的CRUD
表示客户端从服务端主动拉取数据
在Pull模式下,客户端需要定时从服务端拉取一次数据,由于定时任务会存在一定的时间间隔,所以不能保证数据的实时性。并且在服务端配置长时间不更新的情况下,客户端的定时任务会做一些无效的Pull
Pull模式
表示服务端主动把数据推送到客户端
对于Push模式来说,服务端需要维持与客户端的长连接,如果客户端的数量比较多,那么服务端需要耗费大量的内存资源来保存每个连接,并且为了检测连接的有效性,还需要心跳机制来维持每个连接的状态
Push模式
重点:不是简单的Pull,而是一种长轮询机制,它结合Push和Pull两者的优势
1. 客户端采用长轮询的方式定时发起Pull请求,去检查服务端配置信息是否发生了变更,如果发生了变更,则客户端会根据变更的数据获得最新的配置。 所谓长轮询,是客户端发起轮询请求之后,服务端如果有配置发生变更,就直接返回
2. 如果客户端发起Pull请求后,发现服务端的配置和客户端的配置是保持一致的,那么服务端会先“Hold”住这个请求,也就是服务端拿到这个连接之后 在指定的时间段内一直不返回结果,直到这段时间内配置发生变化,服务端会把原来“Hold”住的请求进行返回
3. Nacos服务端收到请求之后,先检查配置是否发生了变更,如果没有,则设置一个定时任务,延期29.5s执行, 并且把当前的客户端长轮询连接加入allSubs队列
长轮询机制流程图
第一种是在等待29.5s后触发自动检查机制,这时候不管配置有没有发生变化,都会把结果返回客户端。而29.5s就是这个长连接保持的时间
第二种是在29.5s内任意一个时刻,通过Nacos Dashboard或者API的方式对配置进行了修改,这会触发一个事件机制,监听到该事件的任务会遍历allSubs队列,找到发生变更的配置项对应 的ClientLongPolling任务,将变更的数据通过该任务中的连接进行返回,就完成了一次“推送”操作
3.1 有两种方式触发该连接结果的返回
3.2 Nacos长轮询机制的优点:既能够保证客户端实时感知配置的变化,也降低了服务端的压力。其中,这个长连接的会话超时时间默认是30s
Nacos采用Pull模式
配置的动态监听
Nacos Config 实现原理解析
整合了各种各样的外部环境
并且提供统一访问的方法 getProperty(String key)
在Spring启动时,会把配置加载到Environment中
当创建一个Bean时可以从Environment中把一些属性值通过@Value的形式注入业务代码
Spring提供的统一环境配置抽象类Environment
如何将远程服务器上的配置加载到Environment
配置变更时,如何将新的配置更新到Environment中,保证配置变更时可以进行属性值的动态刷新
SpringCloud实现配置的动态刷新,需解决的问题
ApplicationEnvironmentPreparedEvent事件类
PropertySourceBootstrapConfiguration配置类
ApplicationContextInitializer接口
NacosConfigBootstrapConfiguration配置类
NacosPropertySourceLocator加载配置实现类
实现原理流程
Nacos在SpringCloud配置加载实现原理
配置动态刷新机制
客户端长轮询机制
服务端长轮询机制
Nacos Config 核心源码解析
实现原理及源码解析
Nacos之配置中心
如果导图对您有用,请在右上角给点个赞吧
Spring Cloud Alibaba 微服务框架 Nacos:微服务注册中心和配置中心
0 条评论
回复 删除
下一页