Apollo分布式配置中心原理_apollo配置中心原理

一、执行流程

操作流程如下：

• 用户修改和发布配置是通过portal调用AdminService，把配置变更保存在数据库中。

• 客户端通过长轮询访问ConfigService实时监听配置变更。默认超时时间是90秒。如果在超时前有配置变更，就会立即返回给客户端。客户端获取变化的配置，根据进行实时更新。如果超时也没有数据变更，就放304.客户端重新发起新的请求。

• 配置服务ConfigService有一个定时任务，每秒去扫描数据库，查看是否有新变更的数据。如果有数据变更就通知客户端。

二、工作原理

1 各模块职责

上图简要描述了Apollo的总体设计，我们可以从下往上看：

Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端

Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）

Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中

Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳

在Eureka之上架了一层Meta Server用于封装Eureka的服务发现接口

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

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

为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

2 分步执行流程

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

2. Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载均衡器)进行负载均衡后分配到某一个Meta Server

3. Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client

4. Meta Server获取Config Service和Admin Service（IP+Port）失败后会进行重试

5. 获取到正确的Config Service和Admin Service的服务信息后，Apollo Client通过Config Service为应用提供配置获取、实时更新等功能；Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能

3. 核心概念

application (应用)

这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置

关键字：appId

environment (环境)

配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置

关键字：env

cluster (集群)

一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。

关键字：cluster

namespace (命名空间)

一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等

关键字：namespaces

它们的关系如下图所示：

三、发布原理

1. 服务端设计

在配置中心中一个重要的功能就是配置发布后实时推送到客户端，上图简要描述了配置发布的大致过程：

1. 用户在Portal操作配置发布
2. Portal调用Admin Service的接口操作发布
3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service
4. Config Service收到ReleaseMessage后，通知对应的客户端

3.1.1 发送ReleaseMessage的实现方式

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

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

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

实现方式如下：

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

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

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

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

示意图如下：

3.1.2 NotificationControllerV2通知客户端配置更新

实现方式如下：

1. 客户端会发起一个Http请求到Config Service的notifications/v2接口，也就是NotificationControllerV2，参见RemoteConfigLongPollService

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

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

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

Apollo源码分析：https://blog.csdn.net/zk4042602/article/details/123514663
热更新更新spring的bean属性：https://blog.csdn.net/zidongxiangxi/article/details/109516458