apollo架构详解

# 一、第一张架构图

上图简要描述了Apollo的总体设计，我们可以从下往上看：

Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端（也就是Spring Cloud微服务程序）
Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（也就是配置管理中心web应用）
Config Service和Admin Service都可以是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳。（Config Service和Admin Service也是Spring Boot服务，同样需要服务注册与发现）
在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口（可以理解为Meta Server为对服务注册中心的接口封装，目前官方只支持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进程(从部署结构角度说，它们三个合起来叫做config-service)中。

注意，目前（2020年4月）apollo默认就集成了eureka（不需要单独搭建eureka集群），官方实现暂不支持zookeeper、consul。第三方实现笔者见过支持zookeeper的情况。

一个apollo portal（含ApolloPortalDB）可以管理多套环境，如：生产、仿真(演示)、开发环境
每个环境都需要独立部署一套Config Service、Admin Service和ApolloConfigDB
我们自己开发的微服务向Config Service注册，因为广义的config service中包含Config Service、Eureka和Meta Server三个逻辑角色

Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
Client通过域名访问Meta Server获取Config Service服务列表（IP+Port）
Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
增设一个Meta Server的角色主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件
Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致

在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。

上图简要描述了配置发布的大致过程：

上图简要描述了Apollo客户端的实现原理：

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

上次更新: 2022/06/13, 18:30:58