需求

为什么需要全局配置中心？

- 公共配置零散

比如有一个memcached集群，有多个项目同时会用到，那么对于管理者来说，他搞不清楚谁用了这个集群。 对于使用者来说，可能也不清楚一个Memcached Client对象是从哪里来的，使用的是哪个集群。

- 公共配置修改的问题 

比如有一个memcached集群，一开始是3个结点的，后面增加到5个结点。如果这个地址改变了的话，需要下游所有的应用都要修改，耗时耗力，而且容易遗漏。

- client jar包里的配置问题

一种常见的情景是： 业务方A提供了一个client jar包，业务方B想要使用业务A的功能时，先把业务方A的client jar加到依赖里，然后还要import业务方A的spring配置文件。 业务方A有自己的配置文件，那么业务方A要么自己隐式加载了配置，要么需要业务方B显式地为业务A增加配置。这两种方式都不理想，还可能会导致配置的key冲突的问题。

- client jar包升级，配置需要升级的问题

业务方B使用了业务方A的client jar包，当业务方A升级了jar，增加了配置，业务方B是否要跟着修改？这样导致流程漫长，而且容易出错。

- 多个配置文件，导致混乱 

项目时间长之后，配置文件会越来越多，逐渐混乱。

- 配置的安全问题

生产环境的数据库连接信息是写在svn里呢，还是放在生产机器上？能否明确有权限的人员才能看到敏感的配置信息？

为什么不使用zookeeper/etcd做为存储？

优点：

- 客户端通过watch监听结节，更新比较方便

缺点：

- 大量连接时，zookeeper压力比较大（360通过增加一个proxy解决）

- 跨机房同步问题

- 权限管理

从实际的开源项目来看，基于zookeeper的都没有实现权限管理（如果有误的话，请告之）。如果有应用恶意删除了zookeeper上的配置，将会是一场灾难，而zookeeper通常是没有备份的。

为什么说基于数据库做配置存储是比较好的方案

- 典型的多读少写（类似传统的web服务）

- 数据库的灾备很成熟，master-master或者master-slave都可以

- 基于数据库比较容易做权限控制（不只是web界面的权限，还要防止恶意读写配置）

为什么不存储Properties文件，或者配置文件？

因为存储多个properties文件，或者其它配置文件，会造成比较混乱，用户不能直观的得到所有的配置。即使用key冲突也不能及时的发现。

在XDiamond里是以key/value方式来存储值，一个项目里只有一个key/value的map，这样清晰直观，所见即所得。

##XDiamond配置中心的解决方案

- 类maven的依赖关系，抽取公共配置，通过依赖关系解决公共配置，client jar配置的问题

- 支持足够复杂的维度，参考maven：groupId, artifactId, version（仅有group维度不够）

- 支持多种环境/profile（实际业务是复杂的，仅支持product/dev/test不够）

- 一个应用只有一个最终的properties，界面所见即所得

- 结合Spring PropertyPlaceholder 机制，应用轻松迁移

- 应用启动时打印配置，避免隐藏加载

- 通过权限控制，结合Secret key，保证配置的安全

- 配置缓存在本地，防止应用因为网络问题而不能启动

权限设计

- Group里的用户有access等级：owner, master, developer, reporter, guest

- Profile可以设置access等级，只有owner/master的用户才可以查看修改product环境下的配置

- 组/用户管理，可以同步LDAP数据

- 用secretkey防止恶意访问

XDiamond Server

- tcp端口5678，长连接，主动推送修改的配置

- http api

- 配置以key/value方式保存

---

XDiamond Client

客户端用以下的参数来获取配置

- groupId

- artifactId

- version

- profile

- secretkey（可选）

对于应用来说，获取到的是一个properties对象，结合Spring的PropertyPlaceholderConfigurer。

对于应用来说，迁入迁出成本非常低。迁入只要在spring xml里增加一个Bean，迁出可以直接改回传统的加载Properties文件的方式。应用不需要编写任何代码，和Spring结合非常简单。