1.背景与介绍
随着微服务架构的发展，企业级项目由无数的服务组成，这时候急需用到集中管理、治理的配置的组件，来统一管理各个服务的开关、配置参数、数据库地址、服务器等等，然而这还不够，还要对这个管理配置的组件有着修改后实时发布、多环境、灰度发布、权限控制、审核等等机制，由此配置中心出现了，而由携程开源的apollo(阿波罗)人气最高、高可用性、各种功能非常完善，当然最关键选择apollo的一点是，文档真的非常非常完善，==本篇文章主要介绍基于docker版本的apollo搭建，apollo的一些核心概念、架构设计以及中间遇到的一些问题解决方案。
2.apollo核心概念
- application 就是字面意思应用，比如在apollo上新建一个配置项目，就是这个应用名称，设置一个appid做为唯一标识。
- environment 环境，apollo支持多环境配置管理，比如dev、fat、uat、pro，每个环境部署的代码，从对应的环境中读取配置。
- cluster 集群，apollo支持，同一个application应用+环境，按照不同集群来读取不同的配置，这个我没有实战中试过，感兴趣的可以去试试，根据官方文档来操作。
- namespace 命名空间，在apollo上建立项目(应用)时候，会默认在application命名空间下，我们的配置中，有许多项目都共同使用，比如数据库连接、服务发现KEY/VALUE等等各种公共的配置项，这时候就可以放到共享命名空间下，开放给所有客户端去拉取这个命名空间下的配置。
3.apollo架构设计
这是apollo官方提供的架构图，由图可见，这是典型的微服务架构，如果做过微服务的同学看起来比较容易，这里面涉及的服务、中间件拆分细节如下：
- ConfigService 配置服务，依赖configDb数据库，提供配置获取接口，为客户端推送配置更新通知，客户端直连或者通过slb地址连接。
- AdminService 后端服务，依赖configDb数据库，提供配置管理接口，提供配置增删改查等等接口，Portal管理界面使用该服务。
- Client 就是我们的API服务，依赖ConfigService，通过configService获取应用配置，或者长连接实时更新；
- Portal 阿波罗的管理界面，依赖Portal数据库，依赖AdminService;
- Euraka 一个服务注册与发现的中间件，ConfigService和AdminService都注册在这，apollo默认架构是这个组件与ConfigService部署在一起，也可以独立部署出去。
- MetaServer 这个相当于，Euraka的一个反向代理
- NginxLB 负载均衡器，如果是分布式部署的话，ConfigService与AdminService同过这个负载地址拉拉取对应的服务发现的反向代理MetaServer地址；