目前公司内部微服务架构基础设施建设中，技术选型以Spring Cloud技术为主，也被大家俗称作“全家桶”。
本篇主要围绕其中一个组件 分布式配置中心 展开讨论。
Spring Cloud Config配置中心介绍&架构
在微服务架构体系中配置中心是比较重要的组件之一，Spring Cloud官方自身提供了Spring Cloud Config分布式配置中心，由它来提供集中化的外部配置支持，它分为客户端和服务端两个部分。其中服务端称作配置中心，是一个独立的微服务应用，用来连接仓库(如Git、Svn)并未客户端提供获取配置的接口；而客户端是各微服务应用，通过指定配置中心地址从远端获取配置内容，启动时加载配置信息到应用上下文中。因Spring Cloud Config实现的配置中心默认采用了Git来存储配置信息，所以版本控制管理也是基于Git仓库本身的特性来支持的 。
对该组件调研后，主要采用基于消息总线的架构方式，架构图如下所示：
基于消息总线的配置中心架构中需要依赖外部的MQ组件，如Rabbit、Kafka 实现远程环境事件变更通知，客户端实时配置变更可以基于Git Hook功能实现。
同时架构图中看到最右侧，有一个Self scheduleing refresher 这个是我在实践中自己新增的一个扩展功能，目的是当依赖的消息组件出现问题时，此时如果Git仓库配置发生了变更，会导致部分或所有客户端可能无法获取到最新配置，这样就造成了客户端应用配置数据无法达到最终一致性，进而引起线上问题。
经过实际使用你会发现Spring Cloud Config这个配置中心并不是非常好用，如果是小规模的项目可以使用问题不大，但它并不适用于中大型的企业级的配置管理。
因此，我对业界开源的配置中心做个对比后最终选择了携程开源的Apollo配置中心解决了微服务架构配置管理和其他项目中配置管理痛点。
下面就针对Spring Cloud Config和Apollo配置中心做个更加直观的比对：
Apollo VS Spring Cloud Config
通过以上对比图发现Spring Cloud Config缺陷还是挺大的，比如最后一条高可用，Apollo配置中心客户端应用加载配置后本地会生成缓存文件，即使配置中心所有的服务都挂掉，只是配置无法更新，但是不影响你的服务启动。而这Spring Cloud Config是无法做到的，有人会说我们可以在应用classpath下添加应用配置文件作为「兜底使用」，这样做首先配置不会自动同步，而且也不是Spring Cloud Config自身的功能。
另外还有一个原因是因为现阶段项目中也使用了一些自研的配置中心，但都差强人意，有的配置中心仅支持xml格式的，无法支持KV形式；还有的配置中心是基于JMX开发的，但只支持属性配置推送。所以经过对Apollo配置中心的调研和使用发现这款产品不仅适用于微服务配置管理场景，同时也支持多种配置格式，如xml、json、yml，还支持多语言客户端的接入，在配置服务治理方面也是很完善的，在携程内部已经支撑10万+的实例运行，成熟又稳定！
开源配置中心对比
下面这个图详细的开源配置中心对比图：
在上述几个开源配置中心里，Apollo社区是非常活跃的，不断更新迭代，github上的Star数量已达8K+，Fork数量已达2.8K+。
在Apollo出现之前百度开源的disconf配置中心使用的更多些，disconf最新代码更新时间还是2年前的，且与Apollo的对比社区活跃度有所下降。
Apollo配置中心介绍&架构
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，
配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
服务端基于Spring Boot和Spring Cloud开发，不依赖外部容器，便于部署。
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有额外支持。
原生支持Java和.Net客户端，同时也支持其他语言客户端，目前已支持Go、PHP、Python、NodeJS、C++。
主要功能特性：
Apollo总体架构设计：
各组件作用说明：
Apollo HA高可用设计：
Apollo客户端架构：
客户端架构原理：
- 推拉结合方式
客户端与配置中心保持一个长连接，配置实时推送
定时拉配置(默认5分钟) - 本地缓存
配置缓存在内存
本地缓存一份配置文件 - 应用程序
通过Apollo客户端获取最新配置
订阅配置更新通知
Apollo核心概念：
application (应用)
environment (环境)
cluster (集群)
namespace (命名空间)
权限管理
Apollo配置中使用及扩展
使用Apollo配置中心后，做了进一步的功能开发扩展，接入公司的SSO和邮件通知接入。
基于Spring Cloud Config微服务架构体系中，如果之前使用了Spring Cloud Config配置中心，也可以通过下列方式平滑的迁移到Apollo配置中心。
Spring Cloud微服务项目在pom.xml中引入如下依赖：
<dependency>
<groupId>com.letv.micro.apollo</groupId>
<artifactId>micro-apollo-spring-boot-starter</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
该源码参考Github：https://github.com/david1228/micro-apollo-spring-boot-starter，需要自行编译打成jar包使用。
这个jar包对Spring Cloud配置刷新机制集成Apollo客户端做了进一步封装，实现的主要功能如下：
上述jar包已上传公司的Maven私服。具体配置使用示例可以参考「4.Apollo配置中心使用示例」
引入micro-apollo-spring-boot-starter之后，可以将spring-cloud-stater-config依赖从pom.xml中去掉了。
Apollo配置中心公共配置命名规范:
公共配置建议统一放到新创建的项目中，该项目中存放Spring Cloud相关的公共组件的配置，比如Eureka、Zipkin、Stream等配置，比如Eureka地址可能是多个微服务应用共用的，便于在该项目中统一对配置进行管理。
创建项目时，选择的部门如为「微服务公共平台(dpms)」
各微服务应用项目创建后可以添加Namespace，选择关联公共配置。
公共配置命名规则：{部门前缀}.application 或者 {部门前缀}.application-{具体的细分配置}
当Apollo配置发布后，若需让Spring Cloud配置实现动态加载，公共配置命名必须以application关键字开头，在上述依赖的jar包中会对这类命名的Namespace做配置变更监听。
例如：
以上就是对为什么要选择Apollo配置中心的一些介绍，相信你的项目中可能也遇到了类似的配置管理问题或痛点，强烈建议使用Apollo配置中心作为你的配置管理基础服务使用。
关于Apollo更详尽的文档请参考Github：https://github.com/ctripcorp/apollo
