今天就拉下来代码首先看了配置，发现代码中有apollo自己以前没见过就有了以下的基本了解。

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

Apollo的主要作用有：

统一管理不同环境、不同集群的配置，以命名空间namespace为最小粒度进行配置，一个服务引入了这个命名空间，即使用了该命名空间的配置。
配置修改实时生效
版本发布管理
灰度发布
权限管理、发布审核、操作审计
客户端配置信息监控
首先，来理一下apollo的简单架构：

从逻辑上来说比较清晰，apollo将配置的编辑/发布与客户端获取配置分开，用两个服务（admin service 和 config service）实现
Portal（门户网站）通过调用admin service接口修改配置
Client（Apollo客户端）通过config service接口获取配置
为了保证高可用，添加了一层eureka，client和portal通过eureka调用接口服务。
为了使不同语言的client可通过http接口即可获取admin service和config service的信息，eureka上搭建Meta service，用来封装服务发现的细节，不用关心背后的注册中心和服务发现组件（用于不同语言的服务注册到eureka上）。

Apollo的主要模块为：

Config Service：配置的读取、推送等，服务对象是Apollo客户端
Admin Service：配置的修改、发布等，服务对象是Apollo Portal（管理界面）
Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
Meta Server：在Eureka之上搭建，用于封装Eureka的服务发现接口：

Client（Apollo客户端）通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client会做load balance（负载均衡）、错误重试
Portal（门户网站）通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal会做load balance（负载均衡）、错误重试
为了简化部署，实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

处理流程是：Admin service发布了配置修改的事件，所有config service收到消息并通知Apollo客户端修改配置：

具体是这样的：

Admin service发布事件的方式：可以用中间件redis，activemq实现。这里为了减少外部组件的依赖，通过数据库实现。

Admin service发布一条配置后，这个配置肯定属于某个namespace，在ReleaseMessage表插入一条记录AppId+Cluster+Namespace，config service有一个线程每秒扫描ReleaseMessage表，如果有新的消息记录，就通知Apollo客户端更新配置。所以配置如果有更新，一般一秒内就可通知到Apollo客户端。

Config service通知Apollo客户端的方式：Apollo客户端发起获取配置的请求，config service用defferResult将请求挂起，如果60秒内没有感兴趣的namespace配置发生变化，返回304，否则立即返回变化后的配置。使用defferResult可以提高请求的并发量

Apollo客户端设计：

Apollo客户端和Apollo服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
Apollo客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

这是一个fallback（备用机制）机制，为了防止推送机制失效导致配置不更新
Apollo客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
Apollo客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份，在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置

应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知。

Apollo使用：

服务端的配置：

新建appId，appId可以理解为是一套应用。在appId新建namespace添加配置内容。Namespace可以理解为是配置的集合，原先一个yml文件存放配置，现在可以通过某个环境 ，某个appId下的namespace引入。
客户端的使用：

引入maven包并在启动类加入@EnableApollo即可，通过meta.server，appId和namespace找到所需的配置。可以理解为在apollo的配置就在配置文件里。通过@Value，@ConfigurationProperties引入的变量不受影响，对代码的入侵比较小。

监听配置的变化，不同的namespace
在项目的使用：

把配置信息放入apollo。直接的做法是每个服务使用一个namespace，但是经过梳理发现，有些配置是多个服务共同使用的。
服务的配置进行分类：

通用：Log，eureka，feign调用相关的
某些服务公用：database（openapi monitor） redis（card openapi double） kafka activemq ElasticSearch
各自的服务拥有单独的namespace
经过分类后，如果要修改数据库地址，redis地址，或者新增一个中间件的地址，只用新增namespace，在配置文件引入/修改该namespace即可。
如果想更改某个服务的配置，在相应的namespace下修改，并重启docker服务。可以看到发布历史，有哪些实例在使用。
项目是用docker部署的，原先一部分配置在服务里，一部分配置在docker-compose里，改造后尽可能所有的配置都放在apollo里，apollo的配置放在docker-compose.yml里，docker-compose.yml可以引入公共的配置文件env_file，真正的apollo配置存放文件，包括apollo.meta，app.id，apollo.cacheDir，不用再通过profile.active区分。一些无法通过apollo配置的放在服务的配置或docker的配置中。理论上能当在服务的配置文件里的都能放在apollo里。
每个服务只需一个配置文件，甚至不用配置文件。为了本地开发的方便，在本地放置了sit环境的配置。
通过apollo.meta区分不同的环境，apollo.meta变量通过docker-compose文件的公共配置env_file引入

需要注意的：

配置的备份
假设两个人对同一个服务进行开发，需要修改配置
Application里的配置会实时生效，自定义的namespace不会。
开关，限流额度，路径
对于日志级别，database等需要更新bean的，需要写代码

Namespace的类型：

私有：namespace从属于appId，只有配置了该appId才可访问
公有：只要连上了apollo就能使用，属于所有应用，全局唯一
关联：属性是私有的，可以理解为在继承公有属性的基础上，可对公有属性进行修改
其他的功能：

密钥管理，保护配置不被其他应用获取
权限分配：以namespace为粒度分配修改，发布，查看的权限
添加集群
配置覆盖，前面的会覆盖后面的，尽可能不要覆盖，保证配置的唯一性