分布式配置中心

分布式配置中心方案

---

一、配置中心定位：为了解决什么问题？

在应用生命周期管理里面，开发人员通常会将应用中需要变更的一些配置项或元数据信息从代码中分离出来，放在一个单独的配置文件里面；这些单独管理的内容就称为应用配置；对于应用配置的维护，在传统的架构中，应用配置的变更，需要登录服务器手动修改配置来生效；这样就带来以下几个问题：

1. 应用配置无法统一管理，无法保证不同的环境同一份代码，无法做到 
   配置和代码隔离
2. 应用配置中，对于runtime的配置，配置修改完，需要重启服务器才
   能生效
3. 应用配置中，对于一些安全敏感的配置信息，变得不安全
4. 在分布式集群环境中，通过手动管理配置，配置漂移问题

对于配置和代码隔离，做环境区分，通常有几种做法：

1. 应用配置不要写在代码中，全部放在配置文件里面，放在服务器的某
   个位置，不同的环境维护不同的配置文件，编译的时候覆盖掉代码的
   占位符
2. 如果代码部署方式采用docker部署的方式，通过maven的profile编译
   时不同环境激活不同的docker文件
3. 成熟的配置中心中间件产品，应用依赖配置中心客户端

二、配置中心目前成熟的技术方案有哪些？

大型互联网公司也有自己成熟的配置中心中间件产品；例如淘系内部的diamond，阿里云中间件产品ACM，携程开源的Apollo配置中心项目，spring cloud配置中心等等；其中diamond和acm大同小异，这里主要列举一下Acm、Apollo、Spring cloud对比

三、配置中心技术选型要求

分布式配置中心以后用来管理所有汽车后应用的配置；必须保证系统的高可靠，但由于系统通过HTTPS方式推送配置更新，所以系统设计按照CP原则来设计；对于配置中心宕机，通过本地文件备份保证可靠性

1. 配置中心以后支持灰度发布，对于配置更新的推送拉取采用HTTPS长连接的方式，不用消息控制数据的推送拉取，同时保证数据传输安全
2. 配置数据利用三级缓存，采用一级热点缓存guava cache，二级缓存redis，对于redis要弱依赖；三级缓存采用本地文件的方式备份缓存数据，本地文件采用集中式缓存Ehcache;对于配置中心服务端挂掉情况下，依然保证系统可用；
3. 系统设计采用模块化设计，便于系统的扩展、解耦
4. 配置中心接入，需要应用系统以来客户端；考虑现在系统的技术架构，JDK采用1.7，springBoot框架，版本号为1.x版本，数据库采用mysql
5. 提供Restful风格接口，便于以后控制台页面前后端分离

4.配置中心技术架构

分布式配置中心JDiamond功能；可以将功能拆分，分期开发；前期满足多环境管理配置基本功能

整个配置中心核心分成三个模块：控制台、客户端、服务端；

核心功能：

• 配置的增删改查，权限控制配置更新
• 配置的导入导出：方便用户在多环境间同步配置
• 配置描述：方便他人理解配置用途
• 在线编辑多种文件格式：支持语法高亮、预发校验，提升在线编辑效率，减少编辑错误

高级特性：

• 灰度发布
• 变更Diff
• 变更历史
• 推送轨迹
• 变更配置，短息邮件通知

稳定性：

• 多级缓存：主备数据库、redis全量缓存，本地文件缓存、热点数据Guava cache缓存
• 流量控制：防止对配置中心服务端错误访问
• 同城容灾：防止不可控因素

安全合规：

• 数据加密
• HTTPS
• 鉴权

---

概念：配置空间 + 配置节点 + 配置集 + 配置域 + 配置项

配置空间：在配置中心注册应用之后，就为每个应用分配一个配置空间
配置节点：配置节点树形结构，存在子孙节点，每个节点称为配置节点
配置集：配置集为Namespace，为一组KV集合，类似配置文件的概念
配置域：配置集下面的文件内容，这个称作配置域
配置项：配置域下面的每条数据称为配置项

实现核心思路：

配置加载：主要利用ApplicationContext中PropertyResource配置管理，以及Spring生命周期管理，bean初始化之前，初始化Bean工厂
配置动态刷新：客户端和服务端保持长连接，默认每隔一段时间从服务端拉取配置；而用户在控制台更新配置后，会插入一条变更记录；同时配置服务开启一个守护线程会每秒扫描变更记录表，有新的消息记录，通知所有的消息监听器

应用接入：只需要在服务器antx.properties文件中声明配置中心注册的应用AppId，以及配置中心地址；对于Xml配置的spring文件通过scheme声明空间替代，对于springBoot java config配置，通过注解方式配置

待续…