分布式配置中心 - 1. 配置中心介绍

实施计划

• 先以测试环境一个应用作为试点，实施配置中心
• 稳定运行至少两周后，在生产环境的该应用上实施配置中心
• 再稳定运行两周后，在测试和生产环境的所有应用都改为使用配置中心
• 配置中心先使用Spring Cloud Config。不够用的话再考虑评估Apollo和Nacos

选型的考量

Spring Cloud Config的原理和架构相对比较容易理解，所以先以Spring Cloud Config作为一个具体的实例，介绍一个简化版本的配置中心。如果只是小团队的话，Spring Cloud Config已经足够用了。
但对于大一些的团队来说，还是存在以下两个不足：

• UI只能依赖Gitlab的界面
• 依赖于Git的权限控制粒度比较粗，也很难扩展

什么是配置中心

这里引用几篇配置中心的科普文。

第一篇

动态调整的基础 —— 配置中心
这篇应该是淘宝在2016年之前的方案。
虽然相对于现在已经比较out-of-date，但其中提到的几点比较有意思：

• 配置动态化的需求发展历程
• 应用 - 平台 - 版本 - 模块的元信息模型。在spring cloud config里，对应{application}/{profile}/{label}的三个层次。在Apollo里，对应Namespace。
• 把配置中心拆分成网关、核心服务和界面系统三个部分。在Apollo里，也拆分为Meta Server/Config Service/Admin Service三块。
  去年的一次分享上听一个阿里的技术专家说，他进阿里第一个月做的事情就是写开关配置。光20多行的代码就加了5个开关。阿里的这个“不要写死”的要求，在加强了灵活性的同时，对配置管理也提出了很高的要求。

第二篇

下面这篇提出了一个通用版的配置中心的架构图。
为什么需要分布式配置中心？ - 徐刘根

第三篇

一篇好TM长的关于配置中心的文章 | 阿里中间件团队博客
顺便提一句，文中提到的淘宝的开源配置中心项目Diamond，但已经5年没有维护了。。。

配置中心的优点与缺点

优点

• 避免敏感信息在源代码中暴露，安全性提升
• 可以实现不重启应用就动态刷新配置
• 可以在应用间共享配置。原本只能在应用内共享配置
• 配置集中化管理，易于全局管理所有配置
• 对配置进行权限管理

缺点

• 原本下载应用代码就可以启动，现在还增加依赖spring cloud config server服务/Apollo服务
• 如果config服务挂了，应用会无法重启
• 不如配置放在项目中那么直观
• 多分支开发的时候，处理不当的话可能会互相影响

本文永久链接 [ https://galaxyyao.github.io/2019/03/26/分布式配置中心-1-配置中心介绍/ ]