前言

运维八荣八耻 ：

• 以可配置为荣，以硬编码为耻
• 以互备为荣，以单点为耻
• 以随时重启为荣，以不能迁移为耻
• 以整体交付为荣，以部分交付为耻
• 以无状态为荣，以有状态为耻
• 以标准化为荣，以特殊化为耻
• 以自动化工具为荣，以手动和人肉为耻
• 以无人值守为荣，以人工介入为耻

目前我们交付进K8S集群的两个dubbo微服务和monitor，它们的配置都是写死在容器里的

配置管理的现状 ：

• 配置散乱格式不标准（XML、ini、conf、yaml...）
• 主要采用本地静态配置，应用多副本集下配置修改麻烦
• 易引发生产事故（测试环境、生产环境配置混用）
• 配置缺乏安全审计和版本控制功能（config review）
• 不同环境的应用，配置不同，造成多次打包，测试失败

配置中心是什么？ ：

• 顾名思义，就是集中管理应用程序配置的“中心” 常见的配置中心：
• SprigCloudConfig
• K8S ConfigMap
• Apollo：基于SprigCloudConfig
• ...

目前具有争议的一般是使用Apollo还是SprigCloudConfig，看对比图，所以我们使用Apollo，而且Apollo是基于SprigCloudConfig，也就是你交付了Apollo也相当于交付了微服务