全局配置中心架构设计与实现

架构设计导读：设计层面需要有扎实的技术广度和深度以及实践经验，实现层面需要权衡取舍技术选型（简单成熟可靠、实现部署成本低、运行效率高、使用体验好、其次是追求超越需求的高性能和并发负载能力，追求极致的可靠性、再其次是可扩展性、可维护性、可迁移性），什么地方合适使用什么技术。设计的第一目标是满足功能性需求，第二目标是非功能性需求，第二目标是架构设计的难点和重点。

GCC 类似YHD ycc,taobao diamond，类似组件还有360、百度的产品：disconf qconf等

工程架构：

GCC-CLIENT 客户端：

1.配置文件分类：properties\xml\json\txt\...,优先支持前2种，可以扩展解析规则。

2.配置文件读取：注解配置、xml里{}配置，与spring \spring boot的配置加载机制结合。

采用xml{}的方式，需要改造spring动态配置加载代码：

a.重写加载配置文件类

b.根据配置文件名、pool名等唯一标志从配置中心读取配置文件。

c.将读取的各种格式的配置数据解析成MAP或自定义的数据结构，xml可以放入本地缓存中，然后合并不同配置文件数据，供spring注入到xml里{}配置项值。Xml的数据可以有需要的客户端api自己从本地缓存获取初始化客户端。

d.读取数据的顺序：首先是本地文件夹的local下，其次是snapshot目录下，再是缓存，再是配置中心服务器：顺序是读取服务器目录、容灾目录、配置数据库。

e.本地启动定时线程拉取最新配置数据，更新本地文件和缓存，注册器监听并动态初始化连接客户端等。

f. 提供api实时获取配置项，封装的http请求。

g.多环境多机房支持，通过环境变量配置区分。

h. 注解扩展，spring初始化时能解析注解并赋给配置值

i. 一个应用对应一个配置组groupId，一个配置文件对应一个配置dataId,配置文件还有配置项。

j. 动态配置监控，监控后，编辑时通过zk及时推送，注册监听事件，获取数据后重新初始化数据库连接池，缓存连接池等。

k. 读取的高性能、高可靠，配置变更的高可靠通知。

3.客户端jar开发。

GCC-SERVER(上传、下载服务)

1.配置数据库设计，包括其他的权限、流程分类元数据设计。

a.数据库模型设计：

机房、环境、配置组、状态、模糊查询条件（全文检索）数据模型

配置、配置项、种类的数据模型

操作日志、错误日志、性能耗时日志的模型

操作权限模型

数据字典模型

Sso的用户模型

统计分析模型

b.创建配置组，创建/上传配置，配置标准化

c.管理配置组，复制，编辑，删除、查看、下载配置文件。

d.配置组发布，修改，提交审核，取消审核，打回，通过，自动发布上线。

e.扩展非核心功能，略。

1.文件存储目录、其他机器容灾目录，目录变化自动同步监控执行脚本

数据库中配置模型与文件目录要一致性。

2.提供api服务，可以实时从服务端读取配置项、配置文件数据。

GCC-ADMIN WEB 编辑管理UI （为了简化架构，与GCC-SERVER合并）

架构目标：配置数据集中统一高性能和高可靠的读取和实时动态更新，创建、上传、编辑多环境、分组、分项的标准流程和界面功能，集成程序上线过程中的配置的自动发布机制和手动更改下发并重启生效机制。

部署架构：

文件目录最好只有一个地方，和容灾目录同步。具体看部署架构，

文件数据和数据库数据如何保证一致性，先保存文件，采用md5采集摘要，如果和现存的摘要不一致，才需要更新文件，更新文件成功后再保存数据库，如果保存数据库失败，那么回滚文件上一个版本或补偿保存数据库。

考虑合适的缓存策略，几分钟的缓存可以的。发布的时候一般要审核等，缓存早就更新了。

数据库架构：主备部署，读写分离

文件存储高可用架构：客户端本地文件目录、客户端本地缓存、客户端定时拉取更新、被动通知更新，api实时读取配置，服务端数据库、服务端文件目录、异地服务器容灾目录，文件目录自动同步。

模块工程架构：client server

长按以下二维码，关注公众号