俗话说”麻雀虽小,五脏俱全“,有人说想看开源源码却不知道什么好,事实上,那些流行多年,广受好评的开源工程都是很值得一读的。今天我们介绍Apollo配置中心的基本情况,之所以介绍这个,主要是因为公司里用的配置中心就是这个,最近要做一次技术分享, 所以就调研了一下发现很多设计非常简介高效,值得学习,这里整理几个最重要的内容。
目录
1.介绍
1.1 介绍
Apollo(阿波罗)是携程框架部研发并开源的一款生产级的配置中心产品,它能够集中管理应用在不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
Apollo目前在国内开发者社区比较热,在Github上有超过5k颗星,在国内众多互联网公司有落地案例,可以说Apollo是目前配置中心产品领域Number1的产品,其成熟度和企业级特性要远远强于Spring Cloud体系中的Spring Cloud Config产品。
Apollo的整体流程如下:
-
用户在配置中心对配置进行修改并发布
-
配置中心通知Apollo客户端有配置更新
-
Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
1.2 架构演进
1.2.1 Apollo架构V1
如果不考虑分布式微服务架构中的服务发现问题,Apollo的最简架构如下图所示:
Apollo V1架构
要点:
-
ConfigService是一个独立的微服务,服务于Client进行配置获取。
-
Client和ConfigService保持长连接,通过一种推拉结合(push & pull)的模式,在实现配置实时更新的同时,保证配置更新不丢失。
-
AdminService是一个独立的微服务,服务于Portal进行配置管理。Portal通过调用AdminService进行配置管理和发布。
-
ConfigService和AdminService共享ConfigDB,ConfigDB中存放项目在某个环境中的配置信息。ConfigService/AdminService/ConfigDB三者在每个环境(DEV/FAT/UAT/PRO)中都要部署一份。
-
Protal有一个独立的PortalDB,存放用户权限、项目和配置的元数据信息。Protal只需部署一份,它可以管理多套环境。
1.2.2 Apollo架构V2
为了保证高可用,ConfigService和AdminService都是无状态以集群方式部署的,这个时候就存在一个服务发现问题:Client怎么找到ConfigService?Portal怎么找到AdminService?为了解决这个问题,Apollo在其架构中引入了Eureka服务注册中心组件,实现微服务间的服务注册和发现,更新后的架构如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/4f5ad1049dc46a4d7a1ac187d9ce6ef4.jpeg)
要点:
-
Config/AdminService启动后都会注册到Eureka服务注册中心,并定期发送保活心跳。
-
Eureka采用集群方式部署,使用分布式一致性协议保证每个实例的状态最终一致。
1.2.3 Apollo架构V3
我们知道Eureka是自带服务发现的Java客户端的,如果Apollo只支持Java客户端接入,不支持其它语言客户端接入的话,那么Client和Portal只需要引入Eureka的Java客户端,就可以实现服务发现功能。发现目标服务后,通过客户端软负载(SLB,例如Ribbon)就可以路由到目标服务实例。这是一个经典的微服务架构,基于Eureka实现服务注册发现+客户端Ribbon配合实现软路由,如下图所示:
![](https://i-blog.csdnimg.cn/blog_migrate/51a76b97810e5fe12708bda126a10033.jpeg)
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的七个模块,其中四个模块是和功能相关的核心模块,另外三个模块是辅助服务发现的模块:
-
ConfigService
-
提供配置获取接口
-
提供配置推送接口
-
服务于Apollo客户端
-
-
AdminService
-
提供配置管理接口
-
提供配置修改发布接口
-
服务于管理界面Portal
-
-
Client
-
为应用获取配置,支持实时更新
-
通过MetaServer获取ConfigService的服务列表
-
使用客户端软负载SLB方式调用ConfigService
-
-
Portal
-
配置管理界面
-
通过MetaServer获取AdminService的服务列表
-
使用客户端软负载SLB方式调用AdminService
-
基于Angular做的
-
1.3.2 三个辅助服务发现模块
-
Eureka
-
用于服务发现和注册
-
Config/AdminService注册实例并定期报心跳
-
和ConfigService住在一起部署
-
-
MetaServer
-
主要用于跨语言支持
-
Portal通过域名访问MetaServer获取AdminService的地址列表
-
Client通过域名访问MetaServer获取ConfigService的地址列表
-
逻辑角色,和ConfigService住在一起部署
-
-
NginxLB
-
也主要针对跨语言支持的
-
和域名系统配合,协助Portal访问MetaServer获取AdminService地址列表
-
和域名系统配合,协助Client访问MetaServer获取ConfigService地址列表
-
和域名系统配合,协助用户访问Portal进行配置管理
-
1.4 核心工作流程
官网有比较明确的说明,详细参考Apollo
核心是:Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port),而后直接通过IP+Port访问服务,同时在Portal侧会做load balance、错误重试。
2. 消息推送流程
在配置中心中,最重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。
上图简要描述了配置发布的大致过程:
-
用户在Portal操作配置发布
-
Portal调用Admin Service的接口操作发布
-
Admin Service发布配置后,发送ReleaseMessage给各个Config Service
-
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,然后几个客户端定时扫描表,如果找到自己要处理的类型,就启动执行。具体实现方式如下:
-
Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录,消息内容就是配置发布的AppId+Cluster+Namespace,参见DatabaseMessageSender
-
Config Service有一个线程会每秒扫描一次ReleaseMessage表,看看是否有新的消息记录,参见ReleaseMessageScanner。
-
Config Service如果发现有新的消息记录,那么就会通知到所有的消息监听器ReleaseMessageListener,例如NotificationControllerV2,消息监听器的注册过程参见ConfigServiceAutoConfiguration
-
NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后,会通知对应的客户端。
2.2 Config Service通知客户端的实现方式
上一节中简要描述了NotificationControllerV2是如何得知有配置发布的,那NotificationControllerV2在得知有配置发布后是如何通知到客户端的呢?
实现方式如下:
-
客户端会发起一个Http请求到NotificationControllerV2
-
NotificationControllerV2不会立即返回结果,而是通过Spring DeferredResult把请求挂起。
-
如果在60秒内没有该客户端关心的配置发布,那么会返回Http状态码304给客户端。
-
如果有该客户端关心的配置发布,NotificationControllerV2会调用DeferredResult的setResult方法,传入有配置变化的namespace信息,同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后,会立即请求Config Service获取该namespace的最新配置。
2.3 客户端设计
上图简要描述了Apollo客户端的实现原理:
-
客户端和服务端保持了一个长连接,从而能第一时间获得配置更新的推送。(通过Http Long Polling实现)
-
客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
-
这是一个fallback机制,为了防止推送机制失效导致配置不更新
-
客户端定时拉取会上报本地版本,所以一般情况下,对于定时拉取的操作,服务端都会返回304 - Not Modified
-
定时频率默认为每5分钟拉取一次,客户端也可以通过在运行时指定System Property:
apollo.refreshInterval
来覆盖,单位为分钟。
-
-
客户端从Apollo配置中心服务端获取到应用的最新配置后,会保存在内存中
-
客户端会把从服务端获取到的配置在本地文件系统缓存一份。在遇到服务不可用,或网络不通的时候,依然能从本地恢复配置
-
应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知