By

前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、Apollo 简介

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

二、Apollo 架构

image-20240328100336574

1、主要模块

模块 说明
Apollo Client： ⬤ 为应用获取配置，支持实时更新
⬤ 通过 MetaServer 获取 ConfigService 的服务列表
⬤ 使用客户端软负载 SLB 方式调用 ConfigService
Apollo Config Service
包含了三个组件: config ,meta server , euraka		 ⬤ 提供配置获取接口
⬤ 提供配置推送接口
⬤ 服务对象是 Apollo Client
Apollo Portal ⬤ Apollo 管理界面，为开发者提供配置修改功能；
⬤ 通过 MetaServer获取 AdminService的服务列表
⬤ 使用客户端软负载 SLB 方式调用 AdminService
Apollo Admin Service ⬤ 提供配置管理接口
⬤ 提供配置修改发布接口
⬤ 服务于管理界面 Apollo Portal

2、辅助模块

模块 说明
Eureka ⬤ 提供服务注册和发现
⬤ Config Service 和 Admin Service会向 Eureka 注册服务，并保持心跳
⬤ 为了简单起见，目前 Eureka 在部署时和 Config Service 是在一个 JVM 进程中的（通过 Spring Cloud Netflix）
``Meta Server | ⬤ Portal 通过域名访问 MetaServer 获取 AdminService 的地址列表<br>⬤ Client 通过域名访问 MetaServer 获取 ConfigService 的地址列表<br>⬤ Meta Server 从 Eureka 获取 Config Service 和 Admin Service的服务信息，相当于是一个 Eureka Client<br>⬤ 增设一个 Meta Server的角色主要是为了封装服务发现的细节，对 Portal 和 Client 而言，永远通过一个 Http接口获取 Admin Service 和 Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件<br>⬤ Meta Server只是一个逻辑角色，在部署时和 Config Service 是在一个JVM 进程中的，所以 IP、端口和 Config Service`一致  

3、精简架构流程

1、Portal 会调用 AdminService 进行配置管理和发布

2、ConfigService 和 Client 保持长连接，ConfigService 服务于 Client 进行配置获取，ConfigService 和 Client通过一种推拉结合的方式，实现配置实时更新 的同时，保证配置更新不丢失。

3、ConfigService 和 AdminService 共享 ConfigDB，ConfigDB 中存放项目在某个环境的配置信息，而且这三者在每个配置环境（DEV / FAT / UAT / PRO)中都要部署一份。

4、Protal 有个独立的 PortalDB，存放用户权限、项目和配置的元数据信息。Portal 只需部署一份，它可以管理多套环境。

三、实现原理

1、服务端推送流程

1、用户在 Portal 操作配置发布

2、Portal 调用 Admin Service的接口操作发布

3、Admin Service 发布配置后，发送 ReleaseMessage给各个Config Service

4、Config Service 收到 ReleaseMessage 后，通知对应的客户端

image-20240328103451506

1、用户操作配置发布后，Admin Service 会往 ReleaseMessage表插入一条消息记录，然后 Config Service定时轮询这张表来消费消息。

2、ApolloPortol 会调 Admin 服务发出消息，这时，Admin Service作 为Producer发出消息，各个 ConfigService 作为Consumer消费消息，为了减少对外部的依赖，Apollo 发送消息的功能是 通过数据库自己实现的一个简单的消息队列。

⬤ Admin 向 ReleaseMessage 表插入一条消息记录：该消息的内容就是配置发布的 AppId + Cluster + Namespace。

⬤ Config Service 定时扫描消息，定时任务逻辑：批量处理，每次扫描 500 条，每条消息分别触发所有消息监听器（ReleaseMessageListener）定时任务线程池配置：每 100 毫秒执行一次，core 线程数只有 1，但是总线程数为 Integer.MAX_INT。

⬤ Config Service通知客户端

2、客户端实现原理

客户端主要任务是从 Config Service 获取配置信息，并在本地维护一个配置文件缓存。

image-20240328104221035

1）客户端 long-polling

客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过 Http Long Polling 实现）

2）客户端定时 Pull

客户端还会定时从 Apollo 配置中心服务端拉取应用的最新配置。（这是一个 fallback 机制，为了防止推送机制失效导致配置不更新）

1、客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回 304 - Not Modified

2、定时频率默认为每 5 分钟拉取一次，客户端也可以通过在运行时指定 System Property: apollo.refreshInterval 来覆盖，单位为分钟。

3）客户端本地对配置的维护

1、客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

2、客户端会把从服务端获取到的配置在本地文件系统缓存一份，在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置

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

ContactAuthor