配置中心 -- Apollo 相关知识总结学习

比眉伴天荒 2021-11-05 07:58 265阅读 0赞

**1、总体架构 **

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70][]

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

*  Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
 *  Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
 *  Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
 *  在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
 *  Client通过域名访问Meta Server获取Config 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-configservice：提供配置获取接口，提供配置更新推送接口，接口服务对象为Apollo客户端  
（2）apollo-adminservice：提供配置管理接口，提供配置修改、发布等接口，接口服务对象为Portal，以及Eureka  
（3）apollo-portal：提供Web界面供用户管理配置  
（4）apollo-client：Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能

**3、配置发布流程**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 1][]

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

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

**Admin Service 与 Config Service 异步通知流程**

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** 后，会通知对应的客户端。

示意图：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 2][]

**客户端设计**

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 3][]

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

1.  客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
2.  客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
    
     *  这是一个fallback机制，为了防止推送机制失效导致配置不更新
     *  客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
     *  定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: `apollo.refreshInterval`来覆盖，单位为分钟。
3.  客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
4.  客户端会把从服务端获取到的配置在本地文件系统缓存一份
    
     *  在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
5.  应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

**配置更新推送实现**

前面提到了Apollo客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。

长连接实际上我们是通过Http Long Polling实现的，具体而言：

*  客户端发起一个Http请求到服务端
 *  服务端会保持住这个连接60秒
    
     *  如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
     *  如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
 *  客户端在收到服务端请求后会立即重新发起连接，回到第一步

考虑到会有数万客户端向服务端发起长连，在服务端我们使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70]: /images/20211104/b4af4ada920549aebb640af3e39e25cd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 1]: /images/20211104/94752a615e984a939dee4b88c3fdb6bd.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 2]: /images/20211104/a4274bef3f114b889e3f0c527e213e61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly90aWFuanVud2VpLmJsb2cuY3Nkbi5uZXQ_size_16_color_FFFFFF_t_70 3]: /images/20211104/765094caf6a549ac8ab2dbe570989afa.png