需求
为什么需要全局配置中心？
- 公共配置零散
比如有一个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结合非常简单。
