系统简介

最近做了一个.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版的配置中心。