1. 简介

apollo是携程框架研发部开源的一款分布式配置管理中心，可以集中管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，具备权限校验等特性。

框架是基于springboot和springcloud开发。

2. 基本功能

1. 统一管理不同环境、不同集群的配置：支持在同一界面管理不同环境、集群和命名空间的配置；
2. 界面功能丰富：支持配置发版、配置回滚、灰度发布等功能；
3. 配置修改实时生效（热发布）
4. 权限管理和审计：应用配置有完善的权限管理机制，按配置分为编辑和发布两个环节，支持查看配置改动历史。

Apollo实现高可用依赖于Eureka，至于为什么使用Eureka官方给出的理由为：

1. 项目本身就使用了Spring Cloud和Spring Boot，同时Spring Cloud还有一套非常完善的开源代码来整合Eureka，使用起来非常方便；
2. Eureka还支持在我们应用自身的容器中启动，也就是说我们的应用启动完之后，既充当了Eureka的角色，同时也是服务的提供者。这样就极大的提高了服务的可用性；
3. 为了提高配置中心的可用性和降低部署复杂度，我们需要尽可能地减少外部依赖。

3. Apollo关键功能实现原理

3.1 框架整体原理

3.1.1 Apollo角色

Apollo框架分为五种角色：

1. Client：运行在开发者业务等系统的SDK，负责从Meta Server拉取Config Service服务的地址并拉取监听配置数据；
2. Portal：配置发布者操作的配置页面，负责从Meta Server拉取Admin Service服务的地址并发布配置修改请求；
3. Meta Server：Eureka集群的消费者，负责从Eureka集群拉取Admin和Config Service并缓存在本地，为Client和Portal提供统一封装后的HTTP接口；
4. Admin Service：Eureka集群的服务提供者，会将自身注册在Eureka集群中，同时接收Portal管理端的修改数据请求；
5. Config Service：Eureka集群的服务提供者，会将自身注册在Eureka集群中，同时接收Client的拉取监听数据请求；
6. PortalDB：存储一些环境变量，及配置环境等信息的数据库，注意该库不存储配置信息，不管是单机还是多机只需要一个portalDB；
7. ConfigDB：存储Apollo的配置信息。

3.1.2 框架执行原理

框架整体执行原理：

1. 启动Eureka集群，以便Apollo机器完成注册发现；
2. 启动Admin Service，将自身注册到Eureka集群中，并保持心跳；
3. 启动Config Service，将自身注册到Eureka集群中，并保持心跳；
4. 启动Meta Server，从Eureka集群中发现拉去Admin Service和Config Service的机器信息；
5. Client端的SDK启动，通过SLB或nginx的负载均衡请求Meta Server，拉取Config Service的机器信息；
6. Client向Config Service拉取数据并使用长轮询监听配置改动；
7. 配置管理员在Portal上修改文件数据，Portal向Admin Service发起配置修改请求；
8. Admin Service接收到修改请求后，发送ReleaseMessage给Config Service；
9. Config Service接收到ReleaseMessage后通过长轮询回调给Client；
10. Client接收到新的配置修改信息，刷新本地缓存。

3.1.3 整体组成

Apollo个人倾向于将其分为三个部分：

1. Portal+Admin Service管理端部分：Apollo的配置提供者，主要负责修改管理配置，发生配置修改后发布配置改动事件；
2. Meta Server+Eureka+Config Service核心部分：这部分会完成集群内部的服务发现注册，并向外提供对应的API接口；
3. Client部分：Apollo的配置消费者，向Apollo拉取服务信息并发起长轮询拉取监听数据。

从Apollo官方推荐的部署方式可以看出来他们也倾向于这样划分，多机部署架构图如下：

MetaServer、Eureka和Config Service可以简化为Config Service。如果要高可用则在此基础上多新增几台Admin Service或Config Serivce，如果要多环境则在此基础上新增不同的Linux Server1集群。

这样划分最核心的原因是：MetaServer、Eureka和Config Service这三个角色在同一个JVM进程中，也就是一定在同一台机器上。而Admin Service在一个JVM中，Portal在一个JVM中。

3.2 细节实现

3.2.1 Eureka和不同角色机器的关系

和Eureka有直接关系的是Meta Server、Config Service和Admin Service，Apollo中其它的组件或角色都和Eureka没有关系。

对Eureka来说，Config Service和Admin Service是服务提供者，会主动将自己的信息注册到Eureka中，而Meta Server则作为服务消费者从Eureka上拉取所有服务提供者的信息。

由于Apollo自己在框架内集成了Eureka，所以在部署Apollo时无需额外再创建一个Eureka集群，如果想要Apollo接入现存的Eureka集群，可使用如下方法：

1. 使用1.5.0之后的版本；
2. 配置apollo.eureka.server.enabled=false；
3. 把serverconfig表的eureka.service.url字段改成自己的eureka路径。

3.2.2 Meta Server的作用

Meta server在整个体系中为Eureka Client，负责从Eureka中发现服务，Meta Server的作用便是封装接口数据，从Eureka中拉取数据后向client和portal开放不同的接口，让client和portal只用关注自身的一个http接口，而无需关心Eureka的数据格式及如何过滤configService或adminService。

3.2.3 ReleaseMessage消息实现原理

当Admin Service收到了修改数据的请求，并完成了数据修改落库后，需要向其它的Config Service发布修改事件，这个使用场景很容易想到消息队列。Apollo使用了数据库表来模拟消息队列，其实现为：

1. Admin Service往ReleaseMessage表中写入一条改动配置记录；
2. 所有的Config Service每秒定时轮询ReleaseMessage表，这就是为什么Apollo说是秒级的热发布性能；
3. 当发现配置表有新的记录写入时，则说明配置发生了改动，此时会通过长轮询返回给Client。

3.2.4 Client的通信方式

Client请求Meta Server使用普通的HTTP方式调用来拉取Config Service服务的ip+port。

cLIENT向Config Service发起http long polling，超时时间为60s，没获取到配置则返回304，有数据则异步通知客户端请求，客户端接收到数据返回更新本地缓存。除了http长轮询，客户端默认会每隔5min向configService拉取一次数据，一般而言是304。可通过System Property: apollo.refreshInterval覆盖。拉取下来的数据会在本地生成文件，以防止远程服务异常无法启动。

负载均衡和错误重试都是在client端完成的，负载均衡方式：

1. 优先访问通知配置变更的configService，以便更快的正常访问；
2. 若访问加载速度过快被限流，则sleep 5s；
3. 访问失败会计算重试时间间隔，单位s。