一、它是什么？

Apollo是携程开源，用来管理各项配置并且支持实时更新、灰度发布等功能特性的系统，属于C/S架构，
同时也支持分环境、分集群管理配置，完善的权限、审核机制。相关资料请查看
[https://github.com/ctripcorp](https://github.com/ctripcorp)

首先，Apollo是有一个客户端和服务端，借用git上的两张图来说明下程序的运行流程：

Apollo程序运行流程

1.使用者通过Apollo提供的Web页面进行配置更新
2.配置发布后会实时更新并推送到应用程序的Apollo客户端
3.客户端也会定时去Apollo配置中心拉取配置
4.Apollo客户端接收新文件会保存在内存中，并更新本地缓存文件
5.应用程序获取配置更新的通知，并更新配置信息

image.png

1.1 Config Service

提供配置获取接口
提供配置更新推送接口（基于Http long polling）
服务端使用Spring DeferredResult实现异步化，从而大大增加长连接数量
接口服务对象为Apollo客户端

1.2 Admin Service

提供配置管理接口
提供配置修改、发布、推送等接口
接口服务对象为Portal

1.3 Meta Server

Portal、Cilent通过域名访问Meta Server获取Admin Service、Config Service服务列表（IP+Port）
Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
封装了Eureka的服务发现接口
Meta Server在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致

1.4 Eureka

基于Eureka和Spring Cloud Netflix提供服务注册和发现
Config Service和Admin Service会向Eureka注册服务，并保持心跳
为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的（通过Spring Cloud Netflix）

1.5 Portal

提供Web界面供用户管理配置
通过Meta Server获取Admin Service服务列表（IP+Port），通过IP+Port访问服务
在Portal侧做load balance、错误重试

1.6 Client

Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能
通过Meta Server获取Config Service服务列表（IP+Port），通过IP+Port访问服务
在Client侧做load balance、错误重试
资料均摘抄自github都能找到，有兴趣可以到官网查阅资料。

二、配置更新发布流程

Apollo启动后，Conifg Service和Admin Service会注册到我们的Eureka，并保持心跳连接检测
配置更新发布的大致流程如下：

1.Apollo Cilent和Portal经过负载均衡后分配到某个Meta Server
2.Meta Service从Eureka获取Admin Service和Config Service的服务列表的(IP + Port)，失败会重试
3.Portal通过Meta Service提供的IP +Port访问Admin Service，更新和发布配置并保存在Portal DB
4.Admin Service发送更新消息给各个Config Service（消息通过自实现的消息队列传递到其他服务）
5.Config Service收到更新后，通知给对应的Client
6.Client读取数据存在内存中，然后在缓存到本地
7.基于第五步Config Service可能出现推送更新失败，因此Client会定时通过去拉取配置信息

三、核心概念

核心概念有以下四个：

1.Application（应用）：关键字appId
这个比较好理解，就是使用配置的应用程序，Apollo客户端需要知道当前的应用是什么，从而获取对应的配置信息
2.环境（env）
配置信息也有对应的环境，开发和测试环境的配置肯定不一样，如使用的DB
3.集群（Cluster）
一个应用下可以有多个集群，比如上海和深圳两个机房相同应用的不同实例分为两个集群
4.namespace(命令空间)
可以把namespace简单理解成配置文件，不同类型的配置放在不同的文件中，比如DBConfig、LimitConfig、TipsConfig等等，格式为常见的properties、xml、yml、yaml、json等

首先配置一定是基于应用的，只有应用程序才会使用到这些配置文件；而应用又有环境之分，比如测试、开发、生产环境等；
同时环境又有集群的区别，例如应用程序上线后在全国各个城市部署，例如北京和深圳部署集群，虽然都是跑一样的应用服务，都是生成环境，但是北京集群要连接数据库地址肯定是连北京机房的数据库，深圳连深圳的数据库地址；
所以集群不一样，配置也不一样。配置都是key-value形式，当有很多配置信息时需要配置时，可以先归类在配置，因此NameSpace可以理解为归类的配置文件，同时配置可能会有公共的部分，因此可以建立公共的NameSpace，通过继承去使用。
总结：应用的配置文件隶属于应用程序，由于应用区分环境，所以不同环境配置文件也不同，具体的环境下面会由于部署的集群不同，配置也不同，那么组成了应用下分环境，环境下分集群，集群下分NameSpace

Apollo配置中心