.Net配置中心-简介

最近做了一个.Net配置中心,本质就是将原本放在各个站点下AppSettings中的配置统一管理,可以实现一次更改,自动更新,这里提供了两个版本, 一个是心跳版,一个是zookeeper版。 
 
对于.net系统过来说,配置一般都是保存到Web.Config/App.Config中的Appsettings下的,这种方法在系统较少,或者配置不经常发生变更的时候,还是非常有效的,但随着业务的发展,会出现下面两种情况:
   1.为了性能和高可用性,部署多套系统。
   2. 节点的值会发生改变,比如对于某些业务要举行的活动,要在某个时间点开启,又要在某个时间点结束。需要修改开关的值。
以上两个问题,通过手动修改配置的方式已经不现实了, 容易出错,并且运维也不会让你这么做。那变通的解决方法就是把容易变更的配置节点放入到数据库中,由后台维护,但是程序每次都要从数据库中读取,对数据库也是一种压力,而且也会损耗性能。
因此引出配置中心,配置中心就是将有可能变动的配置数据集中管理,当配置数据发生变更的时候,可以自动更新到各个站点去。 这里有几个要注意的地方:
  1. 配置数据管理 对于配置数据管理,这个不难,就是将容易变化的值存入到数据库或其他存储中,
  2. 配置数据变更 当发生变更的时候,更新到各个站点去,这里有几种解决方案:
      1. 客户端和服务端建立长连接,当服务端的值有变更的时候,及时推送到客户端。
          缺点:需要维护长连接以及心跳检测,并且如果服务端有多个,如何找到客户端对应的长连接也是一件麻烦事。
      2. 借用一些第三方软件,比如zookeeper,或者redis的发布订阅。
      3. 客户端心跳检测,当发现数据有变更的时候,拉取最新数据。
          缺点:数据不能很及时。
  3. 客户端数据保存 当解决了数据推送的问题,客户端可以获取到最新的值,接下来就是客户端如何存储的问题, 
      1. 保存到内存中。 缺点:重启后数据就没有了,而且如果在 启动的时候,配置中心站点还未启动,那相应的站点因为拉不到数据也没有办法启动。 
      2. 保存到临时文件中,这种方法暂时没有什么缺点,当应用启动的时候,首先去拉取最新的值,如果拉不到,就从临时文件中恢复。
      3. 直接存储到web.confgi/App.config的AppSettings 中,和第二条类似,只是临时文件直接就是config文件。 
 
综合以上:本系统对于数据的更新采用第三种方法:即客户端心跳检测更新,如果有更新,则拉取最新的数据。
                 对于数据的保存则使用第三种方法,即直接保存到AppSetting中。
                 最后appsetting节点是在web.config文件中的,如果直接修改appsetting,那会导致站点重启,这里直接是通过configSource属性,将appsetting放在其他文件夹下,解决站点重启问题,又通过刷新解决配置节点生效问题。
 
开发语言:C#
数据库:Sql Server 2012
适用于.net 项目
github地址 :https://github.com/zhaoyb/ConfigCenter/
 
整体思路
配置中心是按照App进行划分的,一个App对应于一个业务站点,同时每个App都有一个版本号,一个App下面有多个配置,每个配置都是简单的K-V结构,当App下面的配置发生变更的时候,会变更App的版本号。
客户端通过定时检测的方式,对比本地版本号和远程版本号,如果不一致,则会拉取最新数据,增量更新本地的appSetting文件,并刷新,之后本地代码通过ConfigurationManager.AppSettings["XX"]读取到的就是最新配置了。
 
 
优势和缺点
缺点: 配置数据没有办法做到实时更新,客户端是10秒钟一次心跳检测, 如果检测到有变化,则更新客户端。 
           仅支持AppSetting的配置方式,不支持对象方式的配置(在一些配置系统中,可以通过对象的方式进行配置,在获取配置的时候,也是以对象的方式获取,比AppSetting要方便很多)。
优点: 站点无需做任何变更,之前是通过AppSetting读取的数据,现在还是通过AppSetting读取数据。
            数据是保存到AppSetting中的。如果以后不想使用配置中心了,直接把相应DLL删除就可以了。
            因为数据是保存在AppSetting中的,所以如果配置中心异常,站点依然是可以启动并运行的。
            客户端和服务端都的是http协议,协议简单,可以跨多个客户端。 
 
但凡说到配置系统,大家似乎都会说到Zookeeper,但是如果你仔细研究过zookeeper,你一定会对zookeeper的watch机制感到诧异。 它并不像我们想象的那样,一次订阅,即可获取之后所有的更新,而是需要你反复的注册的,目前Java的客户端Curator可以简化这个操作。 但是.net的客户端却没有解决。 
因为对zookeeper有过一点肤浅的研究,所以后续也会提供一个zookeeper版的配置中心。

 

posted @ 2016-04-12 18:53  秋夜  阅读(2102)  评论(0编辑  收藏  举报