apollo 配置中心分析

一、apollo工作原理

二、各模块职责

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

• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
• Admin Service提供配置的修改、发布等功能,服务对象是Apollo Portal (管理界面)
• Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个VM进程中的
• Config Service和Admin Service都是多实例、无状态部罢，所以需要将自己注册到Eureka中并保持心跳在Eureka之上架了一层Meta SerYer用于封装Eureka的服务发现接口
• Client通过域名访问Meta Server获取Config Serice服务列表(IP+Port)，而后直接通过IP+Por访问服务，同时在Client侧会做load balance.错误重试
• Portal通过域名访问Meta Server获取Admin Service服务列表(IP+Port ),而后直接通过P+Port访问服务，同时在Portal侧会做load balance.错误重试

为了简化部署，我们实际上会把Config Service. Eureka和IMeta ServerE个逻辑角色部署在同一个YM进程中

三、分步执行流程

1. Apoll启动后，Config/Admin Service会自动注册到Eureka服务注册中心，井定期发送保活心跳。
2. Apollo Client和IPortal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载均衡器)进行负载均衡后分配到某一个Meta Server

四、核心概念

1.application (应用)

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

关键字: appld

2.environment (环境)

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

关键字: env

3.cluster (集群)

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

关键字: cluster

4.namespace (命名空间)

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

关键字: namespaces

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-fqHbUpfJ-1587646707921)(C:\Users\kaikai136\Desktop\是.png)]

五、项目使用

5.1基础设置

部门创建： 管理员登录->管理工具->系统参数

输入key查询已存在的部门：organizations

[{"orgId":"TEST1","orgName":"样例部门1"},{"orgId":"TEST2","orgName":"样例部门2"},{"orgId":"dev","orgName":"研发部"}]

5.2创建项目

1. 创建用户并给项目授权
2. 用管理员创建项目并分配授权即可

• 部门:选择应用所在的部门

• 应用Appld :用来标识应用身份的唯一 -id，格式为string，需要和项目配置文件applications properties中配置的app.id对应

• 应用名称:应用名，仅用于界面展示

• 应用负责人:选择的人默认会成为该项目的管理员，具备项目权限管理、集群创建、Namespace创建等权限

5.3删除项目

管理员->删除应用

六、配置管理

1.添加Namespace

Namespace作为配置的分类，可当成一个配置文件。

以添加rocketmq配置为例，添加"spring rocketmq" Namespace配置rocketmq相关信息。

2.添加项目私有Namespace : spring-rocketmg

进入项目首页，点击左下脚的“添加Namespace"，共包括两项:关联公共Namespace和创建Namesp这里选择“创建Namespace"

新建Namespace (点击 了解更多Namespace相关知识)

返回到项

Tips:私有Namespace的配置只能被所属的应用获取到

通过创疆_个利有的Name sDaCE可以实现分组管理配置

七、配置发布流程

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

上图简要描述了配置发布的主要过程

• #### 1.用户在Portal操作配置发布

• #### 2.Portal调用Admin Service的接口操作发布I

• #### 3.Admin Service发布配置后，发送ReleaseMessage给各个

• #### 4.Config Service4. Config Service收到ReleaseMessage后。通知对应的客户端

1. 发送ReleaceMeccaσp

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

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

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

具体实现方式如下:

• Admin Service在配置发布后会往ReleaseMessage表插入-条消息记录 ，消息内容就是配置发布的

Appld+ Cluster+Namespace

SELECT * FROM ApolloConfigDB.ReleaseMessage

• Config Service有一个线程 会每秒扫描一次ReleaseMessage表, 看看是否有新的消息
• NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，通知对应客户端

2. Config Service通知客户端

1. 客户端会发起HTTP请求到Config Service的notifications/v2接口
2. NotificationControllerV2不会立即返回结果，而是把请求挂起。考虑到会有数万客户端向服务端发起长连，因此在服务端使用了asyng servlet(Spring DeferredResul)来服务Htp Long Polling请求。
3. 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端。
4. 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置。

3. 客户端读取设计

除了之前介绍的客户端和服务端保持一个 长连接，从而能第一时间获得配置 更新的推送外，客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

• 这是一个备用机制，为了防止推送机制失效导致配置不更新

• 客户端定时拉取会上报本地版本，所以一般情况下,对于定时拉取的操作，服务端都会返回304 - NotModified

• 定时频率默认为每5分钟拉取一-次 ，客户端也可以通过在运行时指定System Property:apollo. refreshInterval来覆盖，单位为分钟

八、灰度发布

1.定义

灰度发布是指在黑与白之间，能够平滑过渡的一 种发布方式。在其上可以进行A/B testing ，即让部分用户继续用产品特性A，-部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

2.Apollo实现的功能

1.对于一些对程序有比较大影响的配置，可以先在一 个或者多个实例生效，观察- 段时间没问题后再全量发布配置。

2.对于一些需要调优的配置参数，可以通过灰度发布功能来实现A/B测试。可以在不同的机器上应用不同的配置，不断调整、测评一段时间后找出较优的配置再全量发布配置。