深圳福田网站建设公司哪家好,大连甘井子区二手房,小程序开发问题,做网站阿里云记录值怎么填文章目录1. 简介2. 基本功能3. Apollo关键功能实现原理3.1 框架整体原理3.1.1 Apollo角色3.1.2 框架执行原理3.1.3 整体组成3.2 细节实现3.2.1 Eureka和不同角色机器的关系3.2.2 Meta Server的作用3.2.3 ReleaseMessage消息实现原理3.2.4 Client的通信方式1. 简介
apollo是携程…
文章目录1. 简介2. 基本功能3. Apollo关键功能实现原理3.1 框架整体原理3.1.1 Apollo角色3.1.2 框架执行原理3.1.3 整体组成3.2 细节实现3.2.1 Eureka和不同角色机器的关系3.2.2 Meta Server的作用3.2.3 ReleaseMessage消息实现原理3.2.4 Client的通信方式1. 简介
apollo是携程框架研发部开源的一款分布式配置管理中心可以集中管理应用不同环境、不同集群的配置配置修改后能够实时推送到应用端具备权限校验等特性。
框架是基于springboot和springcloud开发。
2. 基本功能
统一管理不同环境、不同集群的配置支持在同一界面管理不同环境、集群和命名空间的配置界面功能丰富支持配置发版、配置回滚、灰度发布等功能配置修改实时生效热发布权限管理和审计应用配置有完善的权限管理机制按配置分为编辑和发布两个环节支持查看配置改动历史。
Apollo实现高可用依赖于Eureka至于为什么使用Eureka官方给出的理由为
项目本身就使用了Spring Cloud和Spring Boot同时Spring Cloud还有一套非常完善的开源代码来整合Eureka使用起来非常方便Eureka还支持在我们应用自身的容器中启动也就是说我们的应用启动完之后既充当了Eureka的角色同时也是服务的提供者。这样就极大的提高了服务的可用性为了提高配置中心的可用性和降低部署复杂度我们需要尽可能地减少外部依赖。
3. Apollo关键功能实现原理
3.1 框架整体原理
3.1.1 Apollo角色
Apollo框架分为五种角色
Client运行在开发者业务等系统的SDK负责从Meta Server拉取Config Service服务的地址并拉取监听配置数据Portal配置发布者操作的配置页面负责从Meta Server拉取Admin Service服务的地址并发布配置修改请求Meta ServerEureka集群的消费者负责从Eureka集群拉取Admin和Config Service并缓存在本地为Client和Portal提供统一封装后的HTTP接口Admin ServiceEureka集群的服务提供者会将自身注册在Eureka集群中同时接收Portal管理端的修改数据请求Config ServiceEureka集群的服务提供者会将自身注册在Eureka集群中同时接收Client的拉取监听数据请求PortalDB存储一些环境变量及配置环境等信息的数据库注意该库不存储配置信息不管是单机还是多机只需要一个portalDBConfigDB存储Apollo的配置信息。
3.1.2 框架执行原理 框架整体执行原理
启动Eureka集群以便Apollo机器完成注册发现启动Admin Service将自身注册到Eureka集群中并保持心跳启动Config Service将自身注册到Eureka集群中并保持心跳启动Meta Server从Eureka集群中发现拉去Admin Service和Config Service的机器信息Client端的SDK启动通过SLB或nginx的负载均衡请求Meta Server拉取Config Service的机器信息Client向Config Service拉取数据并使用长轮询监听配置改动配置管理员在Portal上修改文件数据Portal向Admin Service发起配置修改请求Admin Service接收到修改请求后发送ReleaseMessage给Config ServiceConfig Service接收到ReleaseMessage后通过长轮询回调给ClientClient接收到新的配置修改信息刷新本地缓存。
3.1.3 整体组成
Apollo个人倾向于将其分为三个部分
PortalAdmin Service管理端部分Apollo的配置提供者主要负责修改管理配置发生配置修改后发布配置改动事件Meta ServerEurekaConfig Service核心部分这部分会完成集群内部的服务发现注册并向外提供对应的API接口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 ServiceApollo中其它的组件或角色都和Eureka没有关系。
对Eureka来说Config Service和Admin Service是服务提供者会主动将自己的信息注册到Eureka中而Meta Server则作为服务消费者从Eureka上拉取所有服务提供者的信息。
由于Apollo自己在框架内集成了Eureka所以在部署Apollo时无需额外再创建一个Eureka集群如果想要Apollo接入现存的Eureka集群可使用如下方法
使用1.5.0之后的版本配置apollo.eureka.server.enabledfalse把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使用了数据库表来模拟消息队列其实现为
Admin Service往ReleaseMessage表中写入一条改动配置记录所有的Config Service每秒定时轮询ReleaseMessage表这就是为什么Apollo说是秒级的热发布性能当发现配置表有新的记录写入时则说明配置发生了改动此时会通过长轮询返回给Client。
3.2.4 Client的通信方式
Client请求Meta Server使用普通的HTTP方式调用来拉取Config Service服务的ipport。
cLIENT向Config Service发起http long polling超时时间为60s没获取到配置则返回304有数据则异步通知客户端请求客户端接收到数据返回更新本地缓存。除了http长轮询客户端默认会每隔5min向configService拉取一次数据一般而言是304。可通过System Property: apollo.refreshInterval覆盖。拉取下来的数据会在本地生成文件以防止远程服务异常无法启动。
负载均衡和错误重试都是在client端完成的负载均衡方式
优先访问通知配置变更的configService以便更快的正常访问若访问加载速度过快被限流则sleep 5s访问失败会计算重试时间间隔单位s。
