共计 3246 个字符，预计需要花费 9 分钟才能阅读完成。
Apollo（阿波罗）是携程框架部门研发的分布式配置核心，可能集中化治理利用不同环境、不同集群的配置，配置批改后可能实时推送到利用端，并且具备标准的权限、流程治理等个性，实用于微服务配置管理场景。
性能：
- 对立治理不同环境、不同集群的配置，以命名空间 namespace 为最小粒度进行配置，一个服务引入了这个命名空间，即应用了该命名空间的配置。
- 配置批改实时失效
- 版本公布治理
- 灰度公布
- 权限治理、公布审核、操作审计
- 客户端配置信息监控
应用：
-
服务端的配置：
- 新建 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 的，须要写代码
- https://github.com/ctripcorp/apollo-use-cases
Namespace 的类型：
- 公有：namespace 从属于 appId，只有配置了该 appId 才可拜访
- 私有：只有连上了 apollo 就能应用，属于所有利用，全局惟一
- 关联：属性是公有的，能够了解为在继承私有属性的根底上，可对私有属性进行批改
其余的性能：
- 密钥治理，爱护配置不被其余利用获取
- 权限调配：以 namespace 为粒度调配批改，公布，查看的权限
- 增加集群
- 配置笼罩，后面的会笼罩前面的，尽可能不要笼罩，保障配置的唯一性
架构：
从逻辑上来说比拟清晰，将配置的编辑 / 公布与客户端获取配置离开，用两个服务实现
Portal 通过调用 admin service 接口批改配置
Client 通过 config service 接口获取配置
为了保障高可用，增加了一层 eureka，client 和 portal 通过 eureka 调用接口服务。
为了使不同语言的 client 可通过 http 接口即可获取 admin service 和 config service 的信息，eureka 上搭建 Meta service，用来封装服务发现的细节，不必关怀背地的注册核心和服务发现组件（用于不同语言的服务注册到 eureka 上）。
残缺架构如下：
次要模块：
- Config Service：配置的读取、推送等，服务对象是 Apollo 客户端
- Admin Service：配置的批改、公布等，服务对象是 Apollo Portal（治理界面）
- Config Service 和 Admin Service 都是多实例、无状态部署，所以须要将本人注册到 Eureka 中并放弃心跳
-
Meta Server：在 Eureka 之上搭建，用于封装 Eureka 的服务发现接口：
- Client 通过域名拜访 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 收到音讯并告诉客户端批改配置。
有两个值得去摸索的点：
- Admin service 公布事件的形式：能够用中间件 redis，activemq 实现。这里为了缩小内部组件的依赖，通过数据库实现。
具体的做法是 Admin 公布一条配置后，这个配置必定属于某个 namespace，在 ReleaseMessage 表插入一条记录 AppId+Cluster+Namespace，config service 有一个线程每秒扫描 ReleaseMessage 表，如果有新的音讯记录，就告诉客户端更新配置。所以配置如果有更新，个别一秒内就可告诉到客户端。
- Config service 告诉客户端的形式：客户端发动获取配置的申请，config service 用 defferResult 将申请挂起，如果 60 秒内没有感兴趣的 namespace 配置发生变化，返回 304，否则立刻返回变动后的配置。应用 defferResult 能够进步申请的并发量
客户端设计：
- 客户端和服务端放弃了一个长连贯，从而能第一工夫取得配置更新的推送。（通过 Http Long Polling 实现）
-
客户端还会定时从 Apollo 配置核心服务端拉取利用的最新配置。
- 这是一个 fallback 机制，为了避免推送机制生效导致配置不更新
- 客户端定时拉取会上报本地版本，所以个别状况下，对于定时拉取的操作，服务端都会返回 304 – Not Modified
- 定时频率默认为每 5 分钟拉取一次，客户端也能够通过在运行时指定 System Property: apollo.refreshInterval 来笼罩，单位为分钟。
- 客户端从 Apollo 配置核心服务端获取到利用的最新配置后，会保留在内存中
-
客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用，或网络不通的时候，仍然能从本地复原配置
- 应用程序能够从 Apollo 客户端获取最新的配置、订阅配置更新告诉
- 测试环境下多环境部署 SIT，QA，UAT，用一套画面治理不同的环境：
与 spring 的集成原理
Spring 的 ApplicationContext 会蕴含一个 Environment，在服务启动的时候把参数注入即可。