云原生架构之配置中心-总述传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，

一 配置中心简介

1.1 配置中心必要性

传统的静态配置方式要想修改某个配置只能修改之后重新发布应用，要实现动态性，可以选择使用数据库，通过定时轮询访问数据库来感知配置的变化。轮询频率低感知配置变化的延时就长，轮询频率高，感知配置变化的延时就短，但比较损耗性能，需要在实时性和性能之间做折中。配置中心专门针对这个业务场景，兼顾实时性和一致性来管理动态配置。

1.2 业界配置中心方案

• Spring Cloud Config：2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
• Apollo：2016年5月，携程开源的配置管理中心，具备规范的权限、流程治理等特性。
• Nacos：2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
• Consul：Spring Cloud 官方声明 Consul 可以作为 Spring Cloud Config 配置中心的替代方案。Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框架、分布式一致性协议实现、健康检查、Key/Value 存储（配置中心）、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 等），使用起来也较为简单。

1.3 不同配置方案对比

功能点	优先级	spring-cloud-config	ctrip apollo	disconf	备注
静态配置管理	高	基于file	支持	支持
动态配置管理	高	支持	支持	支持
统一管理	高	无，需要github	支持	支持
多环境	中	无，需要github	支持	支持
本地配置缓存	高	无	支持	支持
配置锁	中	支持	不支持	不支持	不允许动态及远程更新
配置校验	中	无	无	无	如：ip地址校验，配置
配置生效时间		重启生效，或手动refresh生效	实时	实时	需要结合热加载管理， springcloudconfig需要 git webhook+rabbitmq 实时生效
配置更新推送	高	需要手工触发	支持	支持
配置定时拉取	高	无	支持	配置更新目前依赖事件驱动， client重启或者server端推送操作
用户权限管理	中	无，需要github	支持	支持	现阶段可以人工处理
授权、审核、审计	中	无，需要github	支持	无	现阶段可以人工处理
配置版本管理	高	Git做版本管理	界面上直接提供发布历史和回滚按钮	操作记录有落数据库，但无查询接口
配置合规检测	高	不支持	支持（但还需完善）
实例配置监控	高	需要结合springadmin	支持	支持，可以查看每个配置在哪些机器上加载
灰度发布	中	不支持	支持	不支持部分更新	现阶段可以人工处理
告警通知	中	不支持	支持，邮件方式告警	支持，邮件方式告警
依赖关系	高	不支持	不支持	不支持	配置与系统版本的依赖系统运行时的依赖关系

二 业务痛点

业务痛点使用的Spring Cloud Config方案，需要考虑一下问题：

• 需要独立在K8s中部Config服务；
• 需要考虑Config服务的高可用性；
• 由于Config服务需要链接私网git repo，安全问题和网络互通问题。

三 改进方向

业务在K8s上，所以应尽可能利用K8s原生的能力，将配置中心不可控性托付给K8s，使用K8s原生configmap和secret资源，无需考虑单独部署配置中心，不用引入新服务，configmap/secret发生变更，服务能及时监控到这一变化从而按照配置的配置更新策略进行动态更新或者服务重启。