.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秒钟(这个时间能够更长）主动到服务端校验一次版本号。