配置中心：将依赖于服务器环境的变量进行统一的管理，如：FTP账号密码、三方云服务的服务地址及相应的授权信息，以及部分公司内部平台的基本配置。
配置中心解决什么痛点：
1、将系统的基本配置与应用代码隔离，在一定程度上提高系统安全性、杜绝基础配置被误改的情况。
2、基础配置统一管理，便于维护，需要修改某一配置时不需要登录到应用集群中的每一台服务器上进行修改，只需要在配置中心的统一管理平台进行修改然后作推送操作（这需要看配置中心具体的实现）。
3、配置中心从某种角度上可以监控应用的运行状态（通过client端和server端的链接），虽然没有提供专业的监控服务。
配置中心的实现：
1、开源实现：github上有很多开源的配置中心的实现，阿里早期开源的diamond、以及很多兴趣爱好者自研的配置中心，下面我给出一个由java实现的也是github上热度比较高的配置中心：https://github.com/melin/super-diamond，之前我们公司内部就是用它进行对配置的统一管理。当然github上还有很多其他比较实用热度也很高的配置中心解决方案、其中也有用python实现的。
下面就我们在使用super-diamond过程中遇到的一些问题进行梳理（抽出相对共性具有代表性的问题），以及我们是如何针对这些问题怎样对其进行改造、在改造过程中遇到的问题及应对之策，最后介绍我们当前架构设计存在的不足及下一步架构发展的方向。
存在问题：
（1）服务端的单点问题，高可用性不强。
（2）前端功能、界面不友好，对某一工程模块下某个key配置困难。
（3）自身协议，client与server之间需要双向通信（client可以pull，server可以push）等。
（4）服务端的数据安全问题，对client端进行白名单或者签名验证，保证工程配置不被外部环境窃取。
（5）在统一配置管理界面，对某一工程配置修改后，工程需要重启才能拉取新配置。
2、改造实现：
2.1 对于前端功能界面不友好的问题，改造时新添加了针对工程、模块、配置项的基本搜索，以及对配置的批量修改功能、服务端配置推送功能（同步推送、异步补偿）、单server客户端实时监控等。下面给出两张样例图：
图1 配置界面
图2 client端监控界面
在图1界面中对各工程的配置进行统一的管理、配置，支持批量配置及按module的维护进行推送任务的创建、消费。图2中显示了某一台server对外client端连接的基本情况，同时也在第一列显示了推送任务的消费状态，便于观察任务消费情况。
2.2 针对服务端的单点问题，在架构设计上新添加了zk集群、HA来做前端的负载均衡工程、nginx代理。下面来看一张当前的系统架构图：
图3 架构图
从上图中可以看出，server端和client端采用netty进行通信，netty是一个十分优秀的异步事件驱动的网络通信框架（Netty is an asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients.），目前很多rpc的框架都采用它来通信，比如：hadoop rpc的avro，如果读者对netty没有接触过或者不是很熟悉的话，建议参看官网netty.io或http://blog.csdn.net/zxhoo/article/details/17264263上的系列文章。客户端可以主动从server端拉取自己的工程配置（大部分的配置中心的设计为在应用启动时拉取，如果拉取不到或者client选择不覆盖则加载client端本地的配置文件），服务端也可以主动向与此连接的客户端推送配置（客户端也可自由选择是否接受服务端推送过来的配置）。client在连接一个server时，通过域名（不是ip）来连接，可以通过nginx来做一定的负载及容灾（当然也可以通过服务端的服务心跳检测来做）。client与server连接上后，client端会对这个channel进行心跳检测，当channel失效时，会重新与server端建立连接。
zk在当前架构中需要担任的角色是客户端连接信息的存储和推送任务的存储，当客户端连接上某一台server时，会通过server向client进行注册，其目的也是为了推送任务的创建；当用户在配置管理界面对配置修改后，通过创建对工程模块下的配置推送任务，及任务的成功消费来实现将修改后的配置推送至client。zk的客户端选用的是curator，curator应该是目前最好的zk的客户端，与zkClient比优势很多，它里面提供了对zk节点（也可包括子节点）结构、信息变化的事件监听，事件的类型有创建、更新、删除等。当推送任务被创建时会获取到一条更新事件，然后根据该事件内容已经具体处理。
下面我们考虑一种情况，当某台server端由于发版或者其他原因，突然重启或宕机时，原先与之连接的client channel将全部失效，虽然通过client端的心跳检测可以连接到另外的server上，但对于原先已经创建好但没有成功消费的推送任务怎么处理？我们的处理方式是建立了一个job对这些任务进行异步推送补偿。
该架构上还有一个重点的点在图中的map上，map主要用来缓存应用内部与该server相连接的client信息，用于推送任务的消费，客户端的monitor是其次。
该架构存在的不足或者不完善的地方有很多，就拿服务组的高可用而言就不是业界rpc调用的首选解决方案，另外也存在单点、单数据节点的问题、对与某一server group所有建立连接的client信息的统一监控维护。下面对该架构进行改进设想，同时也将是下一步发展的方向。
图4 改进架构
新的架构中改进的地方有：
（1）server的可用性通过向zk注册来实现（临时节点），client端在连接server或者当监听到server的节点失效时来再次维护本地server group缓存，实际连接时，直接从server group缓存中根据均衡算法获取一条server ip即可。
（2）利用redis来进行server group全局的client信息的缓存，便于对client的全局监控及server group全局任务推送状态的监控维护。
（3）数据库分库分表（可按照project的属性作为分库的key，这一点可能并不是所有公司都需要，只是一个架构设想，因为配置的数据与业务系统的数据比起来量少的太多），同时需要备库来对主库进行备份，提高可用性。
2.3 对与上述协议的问题，需要根据各公司或者团队的实际需求来调整，并没有一个统一的标准方案。
2.4 server group的配置数据安全问题也与2.3相似，实现方式还是需要根据各公司内部的习惯来做，可以通过白名单的方式、也可通过认证签名的方式、也可生产白名单其它环境认证签名，如果是确定完全走内网通信的话，非生产环境也可不做安全限制。
2.5 配置中心的配置修改后，client端需不需要重启应用来拉取新的配置完全依赖于client server的自身实现，可以不用重启，也可通过设置client端的配置来决定是否选择覆盖本地工程配置。
最后提醒一点：client端尽量不要对应用配置做缓存，不然就配置中心就失去了意义，当然这里可以通过监听配置中心推送过来的配置变化来刷新缓存，不过个人认为完全没有这样的必要。
网友评论