Apollo服务端设计原理剖析

本文摘自于《Spring Cloud微服务 入门 实战与进阶》一书。

1 配置发布后的实时推送设计

配置中心最重要的一个特性就是实时推送了，正因为有这个特性，我们可以依赖配置中心做很多事情。在我自己开发的Smconf这个配置中心，Smconf是依赖于Zookeeper的Watch机制来实现实时推送。

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

• 用户在Portal中进行配置的编辑和发布

• Portal会调用Admin Service提供的接口进行发布操作

• Admin Service收到请求后，发送ReleaseMessage给各个Config Service，通知Config Service配置发生变化

• Config Service收到ReleaseMessage后，通知对应的客户端，基于Http长连接实现

2 发送ReleaseMessage的实现方式

ReleaseMessage消息是通过Mysql实现了一个简单的消息队列。之所有没有采用消息中间件，是为了让Apollo在部署的时候尽量简单，尽可能减少外部依赖。

上图简要描述了发送ReleaseMessage的大致过程：

• Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录

• Config Service会启动一个线程定时扫描ReleaseMessage表，去查看是否有新的消息记录

• Config Service发现有新的消息记录，那么就会通知到所有的消息监听器

• 消息监听器得到配置发布的信息后，则会通知对应的客户端

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

通知是采用基于Http长连接实现，主要分为下面几个步骤：

• 客户端会发起一个Http请求到Config Service的notifications/v2接口

• v2接口通过Spring DeferredResult把请求挂起，不会立即返回

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

• 如果发现配置有修改，则会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回

• 客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置

4 源码解析实时推送设计

Apollo推送这块代码比较多，就不在本书中详细分析了，我把推送这块的代码稍微简化了下，给大家进行讲解，这样理解起来会更容易。当然我这边会比较简单，很多细节就不做考虑了，只是为了能够让大家明白Apollo推送的核心原理。

发送ReleaseMessage的逻辑我们就写一个简单的接口，用队列存储，测试的时候就调用这个接口模拟配置有更新，发送ReleaseMessage消息。

   
   
   

    
@RestController
    
public class NotificationControllerV2 implements ReleaseMessageListener {
       
    

    
 // 模拟配置更新，往里插入数据表示有更新
    
 public static Queue<String> queue = new LinkedBlockingDeque<>();
    

    
 @GetMapping("/addMsg")
    
 public String addMsg() {
       
    
 queue.add("xxx");
    
 return "success";
    
 }
    

    
}
   

消息发送之后，前面我们有讲过Config Service会启动一个线程定时扫描ReleaseMessage表，去查看是否有新的消息记录，然后取通知客户端，这边我们也启动一个线程去扫描：

   
   
   

    
@Component
    
public class ReleaseMessageScanner implements InitializingBean {
       
    

    
 @Autowired
    
 private NotificationControllerV2 configController;
    

    
 @Override
    
 public void afterPropertiesSet() throws Exception {
       
    
 // 定时