【微服务架构组件之配置中心二】Apollo

一、介绍

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

Apollo目前在国内开发者社区比较热，在Github上有超过5k颗星，在国内众多互联网公司有落地案例，可以说Apollo是目前配置中心产品领域Number1的产品，其成熟度和企业级特性要远远强于Spring Cloud体系中的Spring Cloud Config产品。

Apollo采用分布式微服务架构，它的架构有一点复杂，Apollo的作者宋顺虽然给出了一个架构图，但是如果没有一定的分布式微服务架构基础的话，则普通的开发人员甚至是架构师也很难一下子理解。为了让大家更好的理解Apollo的架构设计，我花了一点时间把Apollo的架构按我的方式重新剖析了一把。只有完全理解了Apollo的架构，大家才能在生产实践中更好的部署和使用Apollo。另外，通过学习Apollo的架构，大家可以深入理解微服务架构的一些基本原理。

二、架构和模块

 Apollo架构图by宋顺

下面是Apollo的七个模块，其中四个模块是和功能相关的核心模块，另外三个模块是辅助服务发现的模块：

四个核心模块及其主要功能

1、ConfigService

• 提供配置获取接口
• 提供配置推送接口
• 服务于Apollo客户端

2、AdminService

• 提供配置管理接口
• 提供配置修改发布接口
• 服务于管理界面Portal

3、Client

• 为应用获取配置，支持实时更新
• 通过MetaServer获取ConfigService的服务列表
• 使用客户端软负载SLB方式调用ConfigService

4、Portal

• 配置管理界面
• 通过MetaServer获取AdminService的服务列表
• 使用客户端软负载SLB方式调用AdminService

三个辅助服务发现模块

Eureka

1. 用于服务发现和注册
2. Config/AdminService注册实例并定期报心跳
3. 和ConfigService住在一起部署MetaServer

MetaServer

1. Portal通过域名访问MetaServer获取AdminService的地址列表
2. Client通过域名访问MetaServer获取ConfigService的地址列表
3. 相当于一个Eureka Proxy
4. 逻辑角色，和ConfigService住在一起部署

NginxLB

• 和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表
• 和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表
• 和域名系统配合，协助用户访问Portal进行配置管理

三、架构剖析

最终的Apollo架构全貌，如下图所示：

四、热更新实现机制

Admin Service发布配置后，发送ReleaseMessage给各个Config Service
官方文档：Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录，参见ReleaseMessageScanner。

我们的应用获取配置更新有apollo服务端主动推送（3.4点），也有客户端定时轮询。为什么要有客户端定时轮询，个人理解：服务端主动推送可能因为网络中断或者其他原因而导致配置更新通知不到应用，这时客户端定时轮询就能保证应用一定能收到配置更新。

参考文献：

携程Apollo配置中心的架构_架构师波波的博客-CSDN博客

Apollo-配置更新原理与源码解析_tobebetter9527的博客-CSDN博客_apollo实时更新配置