1.namespace（命名空间）
其中存放的是应用的配置信息，以key-value的形式，
存放在Apollo的客户端，可供多个应用共享一份配置，
同一个应用可以有一个或多个命名空间。多个命名空间就是将配置信息分组，比如分为数据库连接配置、应用自身配置文件等，分组的好处是便于配置的更换。
客户端读取的方法之一是：
@Configuration @EnableApolloConfig //默认namespace的名称是 application public class ConfigUtils { @ApolloConfig static Config config;
可以有如下几种格式：properties、xml、yml、yaml、json
分为三种类型：私有类型（仅供某应用使用）、公有类型（供所有应用使用）、关联类型（相当于是继承的公有类型，与公有类型拥有相同的key,但是不同的value）
2.环境
将应用放置于不同的环境，可以享用不同的namespace，即同一应用可以在不同的应用场景使用不同的配置
3.ConfigService-获取配置
可以从ConfigDB中读取到配置，推送给Apollo客户端，
4.AdminService-管理配置
创建修改发布配置信息，展示在Portal中
**5.**Meta Server
是封装Eurake的服务注册接口
客户端通过app.properties中的META SERVER获取ConfigService中的IP+PORT服务列表，然后再去访问服务，
服务端通过访问Meta Server获取Admin Service服务列表（IP+Port），然后再去访问服务
Meta Server相当于Eurake的客户端，封装了Eurake中获取Config Service、Admin Service服务信息的过程，即封装了两个服务注册与发现的过程。
目前Eurake与Config Service在同一个JVM中，所以IP和PORT与Config Service一致
6.Apollo的客户端与服务端
两者之间是一个长连接，保证了实时更新
客户端会定时从服务端拉取配置信息，并且会保存在本地的缓存中，避免网络不可用
客户端有更新时，会通知给应用程序
长连接：客户端向服务端发起请求，如果一段时间内服务端配置信息有更新，就会把具体的有变化的namespace返回给客户端，如果没有更新，就返回304错误信息，客户端会发起重连的请求，一直不断ing…
配置发布流程：
此图中AdminService作为消息的生产者，ConfigService作为消息的消费者，发送的消息内容是releaseMessage，每发送一条会向数据库表中添加一条数据。如图：
ConfigService通过扫描表来获取信息。
ConfigService通知给客户端的方法类似于上文的长连接，获取到namespace的新配置。
8.公共组件
是指发布给其他应用使用的客户端代码，比如某一应用的配置信息提供给其他应用使用，
此应用也可以覆盖公共组件的某些配置。
9.多个AppID使用同一配置的方法
可以在一个AppID的namespace下新建公共组件配置，然后其他应用读取该namespace即可。若要是某个APPID覆盖公共组件，只需要在该AppID下关联该namespace，并写入需要覆盖的即可。
