## 一、第一张架构图  上图简要描述了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 * 提供Web界面供用户管理配置、权限角色用户管理 * 通过Meta Server获取Admin Service服务列表（IP+Port） ### Client * Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能 * 通过Meta Server获取Config Service服务列表（IP+Port） ### Config Service * 提供配置获取接口 * 提供配置更新接口（基于Http long polling） * 接口服务对象为Apollo客户端 ### Admin Service * 提供配置管理接口 * 提供配置修改、发布等接口 * 接口服务对象为Portal ### 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一致 ## 四、服务端设计 在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。  上图简要描述了配置发布的大致过程： 1. 用户在Portal操作配置发布 2. Portal调用Admin Service的接口操作发布 3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service 4. Config Service收到ReleaseMessage后，通知对应的客户端 ## 五、客户端设计  上图简要描述了Apollo客户端的实现原理： 1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现） 2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。 * 这是一个fallback机制，为了防止推送机制失效导致配置不更新 * 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified * 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property:`apollo.refreshInterval`来覆盖，单位为分钟。 3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中 4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份 * 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置 5. 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知