前言

公司里面使用的配置中心是携程开源的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、错误重试

执行流程

Apollo启动后，Config/Admin Service会自动注册到Eureka服务注册中心，并定期发送保活心跳；
Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载均衡器)进行负载均衡后分配到某一个Meta Server；
Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client；
Meta Server获取Config Service和Admin Service（IP+Port）失败后会进行重试；
获取到正确的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":"微服务部门"}]

创建项目

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

删除项目

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

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

配置管理

发布配置

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

修改配置

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

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

删除配置

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

设置私有Namespace

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

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

设置公共Namespace

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

添加配置

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

关联公共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

配置发布原理分析

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

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

源码分析

发送ReleaseMessage

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

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

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

具体实现如下：

Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，消息内容就是配置发布的AppId+Cluster+Namespace：
消息发送类：DatabaseMessageSende
Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
消息扫描类：ReleaseMessageScanner
Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器
有一个类叫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分钟。

Apollo功能及原理详解

前言