实施计划
- 先以测试环境一个应用作为试点，实施配置中心
- 稳定运行至少两周后，在生产环境的该应用上实施配置中心
- 再稳定运行两周后，在测试和生产环境的所有应用都改为使用配置中心
- 配置中心先使用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服务挂了，应用会无法重启
- 不如配置放在项目中那么直观
- 多分支开发的时候，处理不当的话可能会互相影响