携程Apollo配置中心架构深度剖析_架构_杨波



 写点什么

一、介绍

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

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

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

二、架构和模块

下图是 Apollo 的作者宋顺给出的架构图：

Apollo 架构图 by 宋顺

如果没有足够的分布式微服务架构的基础，对携程的一些框架产品 (比如 Software Load Balancer(SLB)) 不了解的话，那么这个架构图第一眼看是不太好理解的 (其实我第一次看到这个架构也没有看明白)。在这里我们先放一下，等我后面把这个架构再重新剖析一把以后，大家再回过头来看这个架构就容易理解了。

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

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

1. ConfigService

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

2. AdminService

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

3. Client

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

4. Portal

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

三个辅助服务发现模块

1. Eureka

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

2. MetaServer

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

3. NginxLB

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

三、架构剖析

Apollo 架构 V1

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

Apollo V1 架构 by 杨波

要点：

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

Apollo 架构 V2

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

Apollo V2 架构 by 杨波

要点：

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

Apollo 架构 V3

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

Apollo V3 架构 by 杨波

Apollo 架构 V4

在携程，应用场景不仅有 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 之后的架构如下图所示：