Apollo Config原理浅析

1. 简介

apollo是携程框架研发部开源的一款分布式配置管理中心,可以集中管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,具备权限校验等特性。

框架是基于springboot和springcloud开发。

2. 基本功能

  1. 统一管理不同环境、不同集群的配置:支持在同一界面管理不同环境、集群和命名空间的配置;
  2. 界面功能丰富:支持配置发版、配置回滚、灰度发布等功能;
  3. 配置修改实时生效(热发布)
  4. 权限管理和审计:应用配置有完善的权限管理机制,按配置分为编辑和发布两个环节,支持查看配置改动历史。

Apollo实现高可用依赖于Eureka,至于为什么使用Eureka官方给出的理由为:

  1. 项目本身就使用了Spring Cloud和Spring Boot,同时Spring Cloud还有一套非常完善的开源代码来整合Eureka,使用起来非常方便;
  2. Eureka还支持在我们应用自身的容器中启动,也就是说我们的应用启动完之后,既充当了Eureka的角色,同时也是服务的提供者。这样就极大的提高了服务的可用性;
  3. 为了提高配置中心的可用性和降低部署复杂度,我们需要尽可能地减少外部依赖。

3. Apollo关键功能实现原理

3.1 框架整体原理

3.1.1 Apollo角色

Apollo框架分为五种角色:

  1. Client:运行在开发者业务等系统的SDK,负责从Meta Server拉取Config Service服务的地址并拉取监听配置数据;
  2. Portal:配置发布者操作的配置页面,负责从Meta Server拉取Admin Service服务的地址并发布配置修改请求;
  3. Meta Server:Eureka集群的消费者,负责从Eureka集群拉取Admin和Config Service并缓存在本地,为Client和Portal提供统一封装后的HTTP接口;
  4. Admin Service:Eureka集群的服务提供者,会将自身注册在Eureka集群中,同时接收Portal管理端的修改数据请求;
  5. Config Service:Eureka集群的服务提供者,会将自身注册在Eureka集群中,同时接收Client的拉取监听数据请求;
  6. PortalDB:存储一些环境变量,及配置环境等信息的数据库,注意该库不存储配置信息,不管是单机还是多机只需要一个portalDB;
  7. ConfigDB:存储Apollo的配置信息。

3.1.2 框架执行原理

架构图片

框架整体执行原理:

  1. 启动Eureka集群,以便Apollo机器完成注册发现;
  2. 启动Admin Service,将自身注册到Eureka集群中,并保持心跳;
  3. 启动Config Service,将自身注册到Eureka集群中,并保持心跳;
  4. 启动Meta Server,从Eureka集群中发现拉去Admin Service和Config Service的机器信息;
  5. Client端的SDK启动,通过SLB或nginx的负载均衡请求Meta Server,拉取Config Service的机器信息;
  6. Client向Config Service拉取数据并使用长轮询监听配置改动;
  7. 配置管理员在Portal上修改文件数据,Portal向Admin Service发起配置修改请求;
  8. Admin Service接收到修改请求后,发送ReleaseMessage给Config Service;
  9. Config Service接收到ReleaseMessage后通过长轮询回调给Client;
  10. Client接收到新的配置修改信息,刷新本地缓存。

3.1.3 整体组成

Apollo个人倾向于将其分为三个部分:

  1. Portal+Admin Service管理端部分:Apollo的配置提供者,主要负责修改管理配置,发生配置修改后发布配置改动事件;
  2. Meta Server+Eureka+Config Service核心部分:这部分会完成集群内部的服务发现注册,并向外提供对应的API接口;
  3. Client部分:Apollo的配置消费者,向Apollo拉取服务信息并发起长轮询拉取监听数据。

从Apollo官方推荐的部署方式可以看出来他们也倾向于这样划分,多机部署架构图如下:

部署架构图

MetaServer、Eureka和Config Service可以简化为Config Service。如果要高可用则在此基础上多新增几台Admin Service或Config Serivce,如果要多环境则在此基础上新增不同的Linux Server1集群。

这样划分最核心的原因是:MetaServer、Eureka和Config Service这三个角色在同一个JVM进程中,也就是一定在同一台机器上。而Admin Service在一个JVM中,Portal在一个JVM中。

3.2 细节实现

3.2.1 Eureka和不同角色机器的关系

和Eureka有直接关系的是Meta Server、Config Service和Admin Service,Apollo中其它的组件或角色都和Eureka没有关系。

对Eureka来说,Config Service和Admin Service是服务提供者,会主动将自己的信息注册到Eureka中,而Meta Server则作为服务消费者从Eureka上拉取所有服务提供者的信息。

由于Apollo自己在框架内集成了Eureka,所以在部署Apollo时无需额外再创建一个Eureka集群,如果想要Apollo接入现存的Eureka集群,可使用如下方法:

  1. 使用1.5.0之后的版本;
  2. 配置apollo.eureka.server.enabled=false;
  3. 把serverconfig表的eureka.service.url字段改成自己的eureka路径。

3.2.2 Meta Server的作用

Meta server在整个体系中为Eureka Client,负责从Eureka中发现服务,Meta Server的作用便是封装接口数据,从Eureka中拉取数据后向client和portal开放不同的接口,让client和portal只用关注自身的一个http接口,而无需关心Eureka的数据格式及如何过滤configService或adminService。

3.2.3 ReleaseMessage消息实现原理

当Admin Service收到了修改数据的请求,并完成了数据修改落库后,需要向其它的Config Service发布修改事件,这个使用场景很容易想到消息队列。Apollo使用了数据库表来模拟消息队列,其实现为:

  1. Admin Service往ReleaseMessage表中写入一条改动配置记录;
  2. 所有的Config Service每秒定时轮询ReleaseMessage表,这就是为什么Apollo说是秒级的热发布性能;
  3. 当发现配置表有新的记录写入时,则说明配置发生了改动,此时会通过长轮询返回给Client。

3.2.4 Client的通信方式

Client请求Meta Server使用普通的HTTP方式调用来拉取Config Service服务的ip+port。

cLIENT向Config Service发起http long polling,超时时间为60s,没获取到配置则返回304,有数据则异步通知客户端请求,客户端接收到数据返回更新本地缓存。除了http长轮询,客户端默认会每隔5min向configService拉取一次数据,一般而言是304。可通过System Property: apollo.refreshInterval覆盖。拉取下来的数据会在本地生成文件,以防止远程服务异常无法启动。

负载均衡和错误重试都是在client端完成的,负载均衡方式:

  1. 优先访问通知配置变更的configService,以便更快的正常访问;
  2. 若访问加载速度过快被限流,则sleep 5s;
  3. 访问失败会计算重试时间间隔,单位s。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值