由浅入深剖析 Apollo（阿波罗）架构

目录

一、介绍

二、架构和模块

三、架构剖析

1.最简架构

 2. 高可用保障

 3.多接口扩展

四、总结

---

一、介绍

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

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

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

二、架构和模块

下图为官方的架构图：

如果没有足够的分布式微服务架构的基础，对携程的一些框架产品 (比如 Software Load Balancer (SLB) 不了解的话，那么首次看这个架构图是不太好理解的。

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

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

模块	主要功能
ConfigService	服务于Apollo客户端 提供配置获取接口 提供配置推送接口
AdminService	服务于管理界面Portal 提供配置管理接口 提供配置修改发布接口
Client	为应用获取配置，支持实时更新 通过MetaServer获取ConfigService的服务列表 使用客户端软负载SLB方式调用ConfigService
Portal	配置管理界面 通过MetaServer获取AdminService的服务列表 使用客户端软负载SLB方式调用AdminService

三个辅助服务发现模块

模块	主要功能
Eureka	用于服务发现和注册 Config/AdminService注册实例并定期报心跳 和ConfigService组在一起部署
MetaServer	相当于一个Eureka Proxy 逻辑角色，和ConfigService组在一起部署 Portal通过域名访问MetaServer获取AdminService的地址列表 Client通过域名访问MetaServer获取ConfigService的地址列表
NginxLB	和域名系统配合，协助用户访问Portal进行配置管理 和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表 和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表

三、架构剖析

1.最简架构

如果不考虑分布式微服务架构中的服务发现问题，Apollo 的最简架构如下图所示：

注意事项：

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

 2. 高可用保障

为了保证高可用，ConfigService 和 AdminService 都是无状态以集群方式部署的，这个时候就存在一个服务发现问题：Client 怎么找到 ConfigService？Portal 怎么找到 AdminService？为了解决这个问题，Apollo 在其架构中引入了 Eureka 服务注册中心组件，实现微服务间的服务注册和发现，更新后的架构如下图所示：

众所周知， Eureka 是自带服务发现的 Java 客户端的，如果 Apollo 只支持 Java 客户端接入，不支持其它语言客户端接入的话，那么 Client 和 Portal 只需要引入 Eureka 的 Java 客户端，就可以实现服务发现功能。发现目标服务后，通过客户端软负载 (SLB，例如 Ribbon) 就可以路由到目标服务实例。这是一个经典的微服务架构，基于 Eureka 实现服务注册发现 + 客户端 Ribbon 配合实现软路由，如下图所示：

注意事项： 

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

 3.多接口扩展

在携程，应用场景不仅有 Java，还有很多遗留的.Net 应用。Apollo 的作者也考虑到开源到社区以后，很多客户应用是非 Java 的。但是 Eureka(包括 Ribbon 软负载) 原生仅支持 Java 客户端，如果要为多语言开发 Eureka/Ribbon 客户端，这个工作量很大也不可控。

为此，Apollo 的作者引入了 MetaServer 这个角色，其实可以将其视为一个 Eureka 的 Proxy代理，其将 Eureka 的服务发现接口以更简单明确的 HTTP 接口的形式暴露出来，方便 Client/Protal 通过简单的 HTTPClient 就可以查询到 Config/AdminService 的地址列表。获取到服务实例地址列表之后，再以简单的客户端软负载 (Client SLB) 策略路由定位到目标实例并发起调用。

现在还有一个问题，MetaServer 本身也是无状态以集群方式部署的，那么 Client/Protal 该如何发现 MetaServer 呢？一种传统的做法是借助硬件或者软件负载均衡器，例如在携程采用的是扩展后的 NginxLB（也称 Software Load Balancer），由运维为 MetaServer 集群配置一个域名，指向 NginxLB 集群，NginxLB 再对 MetaServer 进行负载均衡和流量转发。Client/Portal 通过域名 +NginxLB 间接访问 MetaServer 集群。

引入 MetaServer 和 NginxLB 之后的架构如下图所示：

 

现在还剩下最后一个环节：Portal 也是无状态以集群方式部署的，用户如何发现和访问 Portal？答案也是简单的传统做法，用户通过域名 +NginxLB 间接访问 Portal 集群。

包括用户端的最终的 Apollo 架构全貌如下图所示：

四、总结

1. 官方的视角是从上往下的俯视视角，而本文是侧面视角。经过三部分的剖析之后，相信大家对 Apollo 的微服务架构会有更清晰的认识，
2. ConfgService/AdminService/Client/Portal 是 Apollo 的四个核心微服务模块，相互协作完成配置中心业务功能，Eureka/MetaServer/NginxLB 是辅助微服务之间进行服务发现的模块。
3. Apollo 采用微服务架构设计，架构和部署都有一些复杂，但是每个服务职责单一，易于扩展。
4. Apollo 只需要一套 Portal 就可以集中管理多套环境 (DEV/FAT/UAT/PRO) 中的配置，这个是它的架构的一大亮点。
5. 服务发现是微服务架构的基础，在 Apollo 的微服务架构中，既采用 Eureka 注册中心式的服务发现，也采用 NginxLB 集中 Proxy 式的服务发现。

---

最后附上Apollo的官方代码，代码中有许多值得学习和借鉴的地方，大家如果感兴趣的话可以参考：
https://github.com/ctripcorp/apollo