目前新项目基本是微服务架构，关于配置的常规方案是将配置信息抽离写入 xml、properties文件中，然后随着应用一块打包发布。如果有开发、测试、预发、生产等多套环境，则通过配置各自独立的文件以区分不同的环境，维护起来特别麻烦。虽然具备了一定的扩展性，但每次配置参数变更都要重新启动或者发布应用，灵活性较差，所以我们需要一个统一的配置中心，以下是技术选型的对比。
一、开源配置中心
经过一段时间的整理，大概有以下几个开源配置中心：
1、Apollo
Apollo（阿波罗）是2016年5月携程框架部门研发的开源的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。
2、Diamond（不在维护，这里就不作介绍了）
Diamond是淘宝研发的分布式配置管理系统。使用Diamond可以让集群中的服务进程动态感知数据的变化，无需重启服务就可以实现配置数据的更。
3、Disconf
专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。2014年7月百度开源的配置管理中心，同样具备配置的管理能力，不过目前已经不维护了，最近的一次提交是两年前了。
4、spring-cloud/spring-cloud-config
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
5、Nacos
2018年6月，阿里开源的配置中心，Nacos致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
二、配置中心对比
1、功能特性
先从功能层面来进行对比：
| 功能特性 | 重要性 | Spring Cloud Config | Apollo | Disconf | Nacos |
|---|---|---|---|---|---|
| 静态配置管理 | 高 | 基于file | 支持 | 支持 | 支持 |
| 动态配置管理 | 高 | 支持 | 支持 | 支持 | 支持 |
| 统一管理 | 高 | 无，需要github | 支持 | 支持 | 支持 |
| 多环境 | 中 | 无，需要github | 支持 | 支持 | 支持 |
| 本地配置缓存 | 高 | 无 | 支持 | 支持 | 支持 |
| 配置锁 | 中 | 支持 | 不支持 | 不支持 | 不支持 |
| 配置校验 | 中 | 无 | 无 | 无 | 无 |
| 配置生效时间 | 高 | 重启生效，或手动refresh生效 | 实时 | 实时 | 实时 |
| 配置更新推送 | 高 | 需要手工触发 | 支持 | 支持 | 支持 |
| 配置定时拉取 | 高 | 无 | 支持 | 配置更新目前依赖事件驱动， client重启或者server端推送操 | 支持 |
| 用户权限管理 | 中 | 无，需要github | 支持 | 支持 | 支持 |
| 授权、审核、审计 | 中 | 无，需要github | 支持 | 无 | 支持 |
| 配置版本管理 | 高 | Git做版本管理 | 界面上直接提供发布历史和回滚按钮 | 操作记录有落数据库，但无查询接口 | 界面操作，支持回滚 |
| 配置合规检测 | 高 | 不支持 | 支持（但还需完善） | 支持 | 支持 |
| 实例配置监控 | 高 | 需要结合spring admin 支持 | 支持，可以查看每个配置在哪些机器上加载 | 支持 | 支持 |
| 灰度发布 | 中 | 不支持 | 支持 | 不支持部分更新 | 支持 |
| 告警通知 | 中 | 不支持 | 支持，邮件方式告警 | 支持，邮件方式告警 | 支持 |
2、技术路线兼容性
引入配置中心，需要考虑和现有项目的兼容性，以及是否引入额外的第三方组件。
| 功能点 | 优先级 | Spring Cloud Config | Apollo | Disconf | Nacos |
|---|---|---|---|---|---|
| SpringBoot支持 | 高 | 原生支持 | 支持 | 与spring boot无相关 | 支持 |
| SpringCloud支持 | 高 | 原生支持 | 支持 | 与spring cloud无相关 | 支持 |
| 客户端支持 | 低 | Java | Java,.Net Go、Python、NodeJS、PHP、C++ |
Java | Java, Go,.Net,C++,Python等 |
| 业务系统侵入性 | 高 | 侵入性弱 | 侵入性弱 | 侵入性弱，支持注解及xml方式 | 侵入性弱 |
| 依赖组件 | 高 | Eureka | Eureka | zookeeper | 无 |
3、可用性与易用性
引入配置中心后，所有的应用都需要依赖配置中心，因此可用性需要重点关注。
| 功能点 | 优先级 | Spring Cloud Config | Apollo | Disconf | Nacos |
|---|---|---|---|---|---|
| 单点故障(SPOF) | 高 | 支持HA部署 | 支持HA部署 | 支持HA部署,高可用由zookeeper保证 | 支持HA部署 |
| 多数据中心部署 | 高 | 支持 | 支持 | 支持 | 支持 |
| 配置获取性能 | 高 | unknown | 比较高（据官方说比Spring快） | 比较高 | |
| 配置界面 | 中 | 无，需要通过git操作 | 统一界面 | 统一界面 | 统一界面 |
三、结论
综合来说，Nacos配置文件支持比较多的格式，支持yaml、text、json、xml、html、Properties，apollo只支持xml、text、Properties的格式，没有兼容spring boot中比较通用的yaml配置。虽然 Nacos支持多格式的配置文件，但是解析上没有Apollo做的好，Apollo虽然支持的配置格式较少，不过会进行解析，使每个配置看起来比较直观，修改的时候比较直观，可以对单个进行修改。
另外，Apollo用户管理以及权限管理做的比较好和全面，适合做部门或者公司级的配置中心。Nacos比较简洁，权限这块目前还比较偏弱。Apollo的社区生态活跃，github最近一直都有活跃提交，而且文档也比较清晰和完善。另外使用的公司特别多，常见的坑基本都被踩完了，也经过了更多社区用户的验证，使用踩坑的几率会比较低。
当然Nacos作为后起之秀，又有互联网大厂阿里巴巴做背书，目前市场活跃度也非常高，大家可以结合自家情况选择，如果想稳妥点建议选择Apollo。
Apollo 介绍
Apollo（阿波罗）是一款可靠的分布式配置管理中心，诞生于携程框架研发部，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。
.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。
特性
基于配置的特殊性，Apollo在设计之初就立志于成为一个有治理能力的配置发布平台，目前提供了以下的特性：
- 统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zk的地址等
- 通过命名空间（namespace）可以很方便的支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
- 配置界面支持多语言（中文，English）
- 配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序。
- 版本发布管理
- 所有的配置发布都有版本概念，从而可以方便的支持配置的回滚
- 灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例。
权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便的追踪问题。
客户端配置信息监控
- 可以方便的看到配置在被哪些实例使用
提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成
- 支持Spring Placeholder，Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
- 同时提供了Http接口，非Java和.Net应用也可以方便的使用
- 提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。
- 不过Apollo出于通用性考虑，对配置的修改不会做过多限制，只要符合基本的格式就能够保存。
- 在我们的调研中发现，对于有些使用方，它们的配置可能会有比较复杂的格式，如xml, json，需要对格式做校验。
- 还有一些使用方如DAL，不仅有特定的格式，而且对输入的值也需要进行校验后方可保存，如检查数据库、用户名和密码是否匹配。
- 对于这类应用，Apollo支持应用方通过开放接口在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
- 部署简单
- 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
- 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
- Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
说明
- 更多Apollo的文档资料可以查阅使用文档
- Apollo本地快速部署请参见Quick Start
- 选择Nacos的小伙伴也可以查看官方文档，了解更多Nacos的特性和使用方法.