携程Apollo配置中心架构介绍

Posted 2022-12-21 纵横千里，捭阖四方

俗话说”麻雀虽小，五脏俱全“，有人说想看开源源码却不知道什么好，事实上，那些流行多年，广受好评的开源工程都是很值得一读的。今天我们介绍Apollo配置中心的基本情况，之所以介绍这个，主要是因为公司里用的配置中心就是这个，最近要做一次技术分享， 所以就调研了一下发现很多设计非常简介高效，值得学习，这里整理几个最重要的内容。

目录

1.介绍

1.1 介绍

1.2 架构演进

1.2.1 Apollo架构V1

1.2.2 Apollo架构V2

1.2.3 Apollo架构V3

1.2.4 Apollo架构V4

1.2.5 Apollo架构V5

1.3 主要模块

1.3.1 四个核心模块

1.3.2 三个辅助服务发现模块

1.4 核心工作流程

2. 消息推送流程

2.1 发送ReleaseMessage的实现方式

2.2 Config Service通知客户端的实现方式

2.3 客户端设计

参考文献

---

1.介绍

1.1 介绍

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

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

Apollo的整体流程如下：

1. 用户在配置中心对配置进行修改并发布

2. 配置中心通知Apollo客户端有配置更新

3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用

1.2 架构演进

1.2.1 Apollo架构V1

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

Apollo V1架构

要点：

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. Protal有一个独立的PortalDB，存放用户权限、项目和配置的元数据信息。Protal只需部署一份，它可以管理多套环境。

1.2.2 Apollo架构V2

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

要点：

1. Config/AdminService启动后都会注册到Eureka服务注册中心，并定期发送保活心跳。

2. Eureka采用集群方式部署，使用分布式一致性协议保证每个实例的状态最终一致。

1.2.3 Apollo架构V3

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

1.2.4 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之后的架构如下图所示：

1.2.5 Apollo架构V5

V4版本已经是比较完整的Apollo架构全貌，现在还剩下最后一个环节：Portal也是无状态以集群方式部署的，用户如何发现和访问Portal？答案也是简单的传统做法，用户通过域名+NginxLB间接访问Portal集群。

所以V5版本是包括用户端的最终的Apollo架构全貌，如下图所示：

1.3 主要模块

1.3.1 四个核心模块

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

1. ConfigService

   • 提供配置获取接口

   • 提供配置推送接口

   • 服务于Apollo客户端

2. AdminService

   • 提供配置管理接口

   • 提供配置修改发布接口

   • 服务于管理界面Portal

3. Client

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

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

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

4. Portal

   • 配置管理界面

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

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

   • 基于Angular做的

1.3.2 三个辅助服务发现模块

1. Eureka

   • 用于服务发现和注册

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

   • 和ConfigService住在一起部署

2. MetaServer

   • 主要用于跨语言支持

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

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

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

3. NginxLB

   • 也主要针对跨语言支持的

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

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

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

1.4 核心工作流程

官网有比较明确的说明，详细参考Apollo

核心是：Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试。

2. 消息推送流程

在配置中心中，最重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。

  上图简要描述了配置发布的大致过程：

1. 用户在Portal操作配置发布

2. Portal调用Admin Service的接口操作发布

3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service

4. Config Service收到ReleaseMessage后，通知对应的客户端

2.1 发送ReleaseMessage的实现方式

Admin Service在配置发布后，需要通知所有的Config Service有配置发布，从而Config Service可以通知对应的客户端来拉取最新的配置。

从概念上来看，这是一个典型的消息使用场景，Admin Service作为producer发出消息，各个Config Service作为consumer消费消息。通过一个消息组件（Message Queue）就能很好的实现Admin Service和Config Service的解耦。

在实现上，考虑到Apollo的实际使用场景，以及为了尽可能减少外部依赖，没有采用外部的消息中间件，而是通过数据库实现了一个简单的消息队列。

这个工作过程就是一侧负责插入数据到DB，然后几个客户端定时扫描表，如果找到自己要处理的类型，就启动执行。具体实现方式如下：

1. Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace，参见DatabaseMessageSender

2. Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录，参见ReleaseMessageScanner。

3. Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器ReleaseMessageListener，例如NotificationControllerV2，消息监听器的注册过程参见ConfigServiceAutoConfiguration

4. NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。

2.2 Config Service通知客户端的实现方式

上一节中简要描述了NotificationControllerV2是如何得知有配置发布的，那NotificationControllerV2在得知有配置发布后是如何通知到客户端的呢？

实现方式如下：

1. 客户端会发起一个Http请求到NotificationControllerV2

2. NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起。

3. 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端。

4. 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置。

2.3 客户端设计

 上图简要描述了Apollo客户端的实现原理：

1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）

2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

   • 这是一个fallback机制，为了防止推送机制失效导致配置不更新

   • 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified

   • 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。

3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中

4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份。在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置

5. 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

参考文献

Apollo