核心组件

ConfigService

 

• 提供配置获取接口

• 提供配置推送接口

• 服务于Apollo客户端

AdminService

• 提供配置管理接口

• 提供配置修改发布接口

• 服务于管理界面Portal

Client

 

• 为应用获取配置，支持实时更新

• 通过MetaServer获取ConfigService的服务列表

• 使用客户端软负载SLB方式调用ConfigService

Portal

 

• 配置管理界面

• 通过MetaServer获取AdminService的服务列表

• 使用客户端软负载SLB方式调用AdminService

Eureka

 

• 用于服务发现和注册

• Config/AdminService注册实例并定期报心跳

• 和ConfigService住在一起部署

MetaServer

 

• Portal通过域名访问MetaServer获取AdminService的地址列表

• Client通过域名访问MetaServer获取ConfigService的地址列表

• 相当于一个Eureka Proxy

• 逻辑角色，和ConfigService住在一起部署

NginxLB

 

• 和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表

• 和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表

• 和域名系统配合，协助用户访问Portal进行配置管理

技术架构

Apollo的技术架构是完全的微服务部署架构，但是和apollo的创始人沟通之后,发现其实apollo技术架构一直在不断的升级，下面就把Apollo的架构版本演变之路通过图形展示出来，这样可以更加容易理解Apollo的技术架构

1.0版本

ConfigService是一个独立的微服务，服务于Client进行配置获取。 Client和ConfigService保持长连接，通过一种推拉结合(push & pull)的模式，在实现配置实时更新的同时，保证配置更新不丢失。 AdminService是一个独立的微服务，服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。 ConfigService和AdminService共享ConfigDB，ConfigDB中存放项目在某个环境中的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份。 Protal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境。

 

2.0版本

Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保活心跳。 Eureka采用集群方式部署，使用分布式一致性协议保证每个实例的状态最终一致。

 

3.0版本

基于Eureka实现服务注册发现+客户端Ribbon配合实现软路由

 

4.0版本

引入了MetaServer这个角色，它其实是一个Eureka的Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来，方便Client/Protal通过简单的HTTPClient就可以查询到Config/AdminService的地址列表

 

5.0版本

Apollo当前完整的技术架构

客户端推送更新架构

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

 

服务端机制

服务端会保持住这个连接60秒 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端 客户端在收到服务端请求后会立即重新发起连接，回到第一步

核心原理

服务端Spring DeferredResult来服务Http Long Polling请求