Apollo功能及原理详解

前言

公司里面使用的配置中心是携程开源的Apollo，之前我只使用过Nacos，遂记录一下学习过程。

Apollo工作原理

模块介绍

上图就是Apollo的总体设计，从下往上挨个分析：

• ConfigDB用于存储各种配置
• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端，多实例，需要注册到Eureka中保持心跳检测
• Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面），多实例，需要注册到Eureka中保持心跳检测
• Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中
• 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、错误重试

执行流程

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提供配置新增、修改、发布等功能。

基本概念

• application (应用)
  
  实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。关键字：appId
• environment (环境)
  
  配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置。关键字：env
• cluster (集群)
  
  一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。关键字：cluster
• namespace (命名空间)
  
  一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等。关键字：namespaces
  
  关系图如下所示：
  
  

项目管理

部门管理

apollo 默认部门有两个。要增加自己的部门，可在系统参数中修改，进入系统参数，输入key查询已存在的部门设置：organizations



修改value值来添加新部门，下面添加一个微服务部门：

[{"orgId":"TEST1","orgName":"样例部门1"},{"orgId":"TEST2","orgName":"样例部门2"},{"orgId":"micro_service","orgName":"微服务部门"}]

创建项目

1. 打开apollo主页，点击创建应用：
   
   
2. 输入相关信息，包括部门、应用AppId、应用名称和应用负责人
   
   
3. 将项目授予用户管理服务的权限，点击授权
   
   
4. 使用zhangsan账号登陆，就可以看到能管理的应用了
   
   

删除项目

如果要删除整个项目，点击右上角的管理员工具，再点击删除应用、集群。

首先查出压迫删除的项目是，然后点击删除应用：

配置管理

发布配置

• 通过表格模式添加：
  
  
• 通过文本模式批量添加：
  
  
• 最后点击右上角发布按钮发布配置。

修改配置

找到需要修改的配置项，进行修改



修改完进行提交，之后在重新发布配置。

删除配置

与上面一样，删除配置后重新发布。

设置私有Namespace

Namespace同样也可以当作一个配置文件，以rocketmq配置为例，添加“spring-rocketmq” Namespace配置rocketmq相关信息。

1. 创建命名空间
   
   
2. 添加配置项
   
   
3. 进行发布。

设置公共Namespace

在项目开发中，有一些配置可能是通用的，我们可以通过把这些通用的配置放到公共的Namespace中，这样其他项目要使用时可以直接添加需要的Namespace。

添加配置

1. 新建一个common-template项目
   
   
2. 添加公共Namespace：spring-boot-http
   
   
3. 添加配置项并发布
   
   

关联公共Namespcae

创建完公共命名空间之后，需要将项目进行关联才能使用。

打开之前创建的account-service项目，点击左侧的添加Namespace，再添加Namespace：

若是当前项目需要的配置与公共配置中提供的不一样，也可以根据需求覆盖定制配置。

读取配置

读取某个集群的配置，需要启动应用时在VM option指定具体的应用、环境和集群。

-Dapp.id=应用名称

-Denv=环境名称

-Dapollo.cluster=集群名称

-D环境_meta=meta地址

具体实例如下：

‐Dapp.id=account‐service
‐Denv=DEV
‐Dapollo.cluster=SHAJQ
‐Dapollo.meta=http://localhost:8080

配置发布原理分析

在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的：

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

源码分析

发送ReleaseMessage

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

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

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

具体实现如下：

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

   消息发送类：DatabaseMessageSende
   
   

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

   消息扫描类：ReleaseMessageScanner
   
   

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

4. 有一个类叫NotifificationControllerV2，当它得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。

   1. 客户端会发起一个Http请求到Config Service的 notifications/v2 接口NotificationControllerV2
      
      
   2. NotificationControllerV2不会立即返回结果，而是把请求挂起。考虑到会有数万客户端向服务端发起长连，因此在服务端使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。
   3. 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端。
   4. 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace 后，会立即请求Config Service获取该namespace的最新配置。
   5. 除此之外，客户端还会定时从Apollo配置中心服务端拉取应用的最新配置，防止推送机制失效导致配置不更新，提升了可用性，默认定时拉取频率是5分钟。