3千字Apollo配置中心的总结，让配置“智能”起来( 三 ) _Apollo配置

文章插图

文章插图

第二步，创建配置。

文章插图

第三步，发布。

文章插图

4.8 测试启动项目apollo-demo，然后请求路径http://localhost:8888/apollo/getConfig，可以看到：

文章插图

控制台可以看到推送配置信息的日志：

文章插图

五、架构设计讲完了安装和SpringBoot整合的demo后，我们是时候探究一下原理，为什么要有三个服务，又是如何做到配置信息发布后，客户端实时获取到最新的配置的。继续往下看。
首先看一张官网的架构设计图。
5.1 基础模型作者在官网上有个基础模型的架构图，忽略掉很多细节后实际上非常简单：

文章插图

用户在配置中心对配置进行修改并发布。
配置中心通知Apollo客户端有配置更新。
Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用。

5.2 架构模块如果我们把Apollo配置中心服务端展开的话，架构图如下：

文章插图

看到这里，整个架构看起来就比较清晰了。接下来从上往下简单介绍一下：
Portal服务：提供Web界面供用户管理配置，通过MetaServer获取AdminService服务列表（IP+Port），通过IP+Port访问AdminService服务。
Client：实际上就是我们创建的SpringBoot项目，引入ApolloClient的maven依赖，为应用提供配置获取、实时更新等功能。
Meta Server：从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client 。主要是为了封装服务发现的细节，对Portal和Client而言，永远通过一个Http接口获取Admin Service和Config Service的服务信息，而不需要关心背后实际的服务注册和发现组件。Meta Server只是一个逻辑角色，在部署时和Config Service是在一个JVM进程中的，所以IP、端口和Config Service一致。
Eureka：注册中心。Config Service和Admin Service会向Eureka注册服务。为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中的。
Config Service：提供配置获取接口。提供配置更新推送接口(基于Http long polling) 。服务对象为Apollo客户端(Client) 。
Admin Service：提供配置管理接口。提供配置发布、修改等接口。服务对象为Portal 。
5.3 配置发布后的实时推送设计上面讲完各个角色的用途，那这些角色是怎么配合一起工作的呢，我们来看一张图：

文章插图

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

用户在Portal操作配置发布。
Portal调用Admin Service的接口操作发布。
Admin Service发布配置后，发送ReleaseMessage给各个Config Service 。
Config Service收到ReleaseMessage后，通知对应的客户端(Client) 。

关键点在于AdminService发送ReleaseMessage给ConfigService，这一步是如何异步发送的呢，一般异步发送我们很容易想到消息队列，但是实际上我们在安装部署时并没有使用到消息队列。
答案在于：

Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace 。
然后Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器，监听器得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。