.Net配置中心-Zookeper版

简介

zookeeper的基本概念和作用这里不做介绍,现在很多的公司都在使用它,说起它的作用,可能最先想到的是配置中心,可以将配置项作为一个node存储在zookeeper中,其他应用可以“关注”这个节点,当配置的值发生变化的时候,其他应用可以很快的被通知到。

这里有一个细节,就是通知的次数,我在初次认识zookeeper的时候,以为“关注”了某个节点后,之后这个节点的值发生变化都可以通知到,但是实际情况是客户端在“关注”了某个节点后,这个节点的首次变化会被通知到,之后的变化都不会再通知,如果想得到之前的变化,需要在首次变更通知到后,再次“关注”这个节点,也就是说,zoookeeper中的“关注”通知是一次性的,类似于Web中Request/Response。

基于这种情况,zookeeper的Java客户端Curator做了一定的优化,但是.Net还没有,基于此,我写了一个zookeeper Watch的帮助类,可以实现“一次关注,多次通知”。

ZookeeperWatchHelp

ZookeeperWatchHelp的核心很简单,就是在"关注"了某个节点后,当节点发生变更,通知到应用程序后,立刻再次"关注",之后才执行变更的处理程序。

目前代码已经开源,地址是:https://github.com/zhaoyb/ZookeeperWatcherHelp

配置中心zookeeper版本

之前的配置中心是基于心跳的,当配置发生变化,并不能立刻通知到客户端,对于某些应用场景可能不适用,所以升级为zookeeper版本。

zookeeper版本的核心思想: 将应用Id(AppId)作为一个node存入到zookeeper中,node的data是应用的版本号,修改配置的时候,除了修改应用的版本号,还要修改zookeeper中对用node的data。 客户端在启动的使用,注册对指定节点数据变更的关注,当节点的值发生变化,会通知到客户端,客户端请求服务端拉取最新的配置。

zookeeper版配置中心-服务端

在启动的时候,主动创建一个节点,作为配置中心的根节点。

在配置发生变化的时候,处理更新版本号,还要更新zookeeper中对应节点的data。节点的名称就是应用的名称。

zookeeper版配置中心-客户端

客户端的启动方式和之前类似

在启动的时候,首先会实例化zookeeper对象,需要zookeeper服务器的host和port,这些其实也是配置,所以会到服务端指定的应用下面获取配置(这些配置需要事先配置好),在拉取到zookeeper的配置后,实例化zookeeper配置,并注册关注。

zookeeper的客户端本身具有重连机制,所以当某个服务器宕机,会自动重连到另外的机器,这些对上层应用来说是透明的,但是为了保证高可用,还是做了一个降级处理,就是会每隔20秒钟(这个时间可以更长)主动到服务端校验一次版本号。

时间: 2024-08-01 06:37:04

.Net配置中心-Zookeper版的相关文章

springcloud(九):配置中心和消息总线(配置中心终结版)

Spring Cloud BusSpring cloud bus通过轻量消息代理连接各个分布的节点.这会用在广播状态的变化(例如配置变化)或者其他的消息指令.Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展,也可以用来建立一个多个应用之间的通信频道.目前唯一实现的方式是用AMQP消息代理作为通道,同样特性的设置(有些取决于通道的设置)在更多通道的文档中. Spring cloud bus被国内很多都翻译为消息总线,也挺形象的.大家可以将它理解为管理和传播

Spring Cloud(九):配置中心(消息总线)【Finchley 版】

Spring Cloud(九):配置中心(消息总线)[Finchley 版] 发表于 2018-04-19 |  更新于 2018-05-07 | 我们在 Spring Cloud(七):配置中心(Git.Refresh) 中讲到,如果需要客户端获取到最新的配置信息需要执行refresh,我们可以利用 Webhook 的机制每次提交代码发送请求来刷新客户端,当客户端越来越多的时候,需要每个客户端都执行一遍,这种方案就不太适合了.使用 Spring Cloud Bus 可以完美解决这一问题. Sp

SpringCloud学习系列之五-----配置中心(Config)和消息总线(Bus)完美使用版

前言 在上篇中介绍了SpringCloud Config的使用,本篇则介绍基于SpringCloud(基于SpringBoot2.x,.SpringCloud Finchley版)中的分布式配置中心(SpringCloud Config)的配置刷新和消息总线(RabbitMQ和Kafka)使用教程. SpringCloud Config Refresh 在上一篇中我们介绍了springcloud配置中心的本地使用和Git使用的用法,但是当重新修改配置文件提交后,客户端获取的仍然是修改前的信息,需

SpringCloud04 服务配置中心、消息总线、远程配置动态刷新

1 环境说明 JDK:1.8 MAVENT:3.5 SpringBoot:2.0.5.RELEASE SpringCloud:Finchley.SR1 2 创建服务注册中心(Eureka服务端) 说明:本博文仅仅以一个单例的注册中心为例,高可用的服务注册中心请参见 2.1 引入依赖 利用IDEA创建服务注册中心项目时只需要引入 spring-cloud-starter-netflix-eureka-server 一个依赖就可以啦 <dependency> <groupId>org.

跟我学SpringCloud | 第六篇:Spring Cloud Config Github配置中心

SpringCloud系列教程 | 第六篇:Spring Cloud Config Github配置中心 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明,本系列教程全采用以上版本 随着分布式项目越来越大,勤劳的程序猿们会开始面临一个挑战,配置文件会越来越繁杂,虽然spring提供了一个鸡肋版的解决方案,spring.profiles.active,在大型的分布式项目体系中,聊胜于无吧,手动维护配置文件的痛苦,生产,UAT,测

jenkins 配置子项目发版

刚接手公司的项目虽说也多模块.分布式部署,但是模块之间却没有被父项目管理,每个模块是一个小的父子项目,管理了两个子项目,单独维护着当前模块内使用的依赖,版本等,模块之间自然有很多重复引用的依赖,我不知道当初为什么这样创建,在我集成apollo配置中心的时候我改掉了这样依赖结构,所有的模块的依赖都和版本都统一由一个父pom管理,这也为后面埋下一个坑. 测试环境上线的时候,使用的jenkins自动部署,原以为更换了源码路径就可以了,但是发版错误提示没有定义版本号,×××的是要部署的模块代码,其他模块

kubernetes实战-配置中心(三)配置服务使用apollo配置中心

使用配置中心,需要开发对代码进行调整,将一些配置,通过变量的形式配置到apollo中,服务通过配置中心来获取具体的配置 在配置中心修改新增如下配置: 项目信息: 配置: 重新打包镜像,使用apollo版本的代码: 修改dp.yaml,将镜像使用我们刚刚打包的这个: 应用资源配置清单: # kubectl apply -f http://k8s-yaml.od.com/dubbo-server/dp.yaml 创建dubbo服务消费者: apollo中新建一个项目:dubbo-demo-web,新

记录一个 spring cloud 配置中心的坑,命令行端口参数无效,被覆盖

spring cloud 配置中心 结合GIT , 可以运行时更新配置文件.发送指令让应用重新读取配置文件. 最近在测试服务器实现了一套,结果CPU 实用率暴增,使用docker compose启动 restart always 多节点的服务一直重启关闭重启关闭. 日志文件记录了一个异常: 国内国外搜了一遍都没有解决 org.springframework.beans.factory.BeanCreationNotAllowedException: Error creating bean wit

ZooKeeper实现配置中心的实例(原生API实现)(转)

说明:要实现配置中心的例子,可以选择的SDK有很多,原生自带的SDK也是不错的选择.比如使用I0Itec,Spring Boot集成等. 大型应用通常会按业务拆分成一个个业务子系统,这些大大小小的子应用,往往会使用一些公用的资源,比如:需要文件上传.下载时,各子应用都会访问公用的Ftp服务器.如果把Ftp Server的连接IP.端口号.用户名.密码等信息,配置在各子应用中,然后这些子应用再部署到服务器集群中的N台Server上,突然有一天,Ftp服务器要换IP或端口号,那么问题来了?),而是如