美文网首页一些收藏
分布式配置中心Apollo

分布式配置中心Apollo

作者: 后来丶_a24d | 来源:发表于2021-01-24 18:15 被阅读0次

目录

  • 环境搭建
  • 源码解析
  • 基于apollo的思考
  • 参考文章

环境搭建

  1. 先执行apollo项目下的scripts初始化数据库
  2. apollo-assembly配置,数据库密码注意替换
vm参数: -Dapollo_profile=github -Dspring.datasource.url=jdbc:mysql://localhost:3306/ApolloConfigDB?characterEncoding=utf8 -Dspring.datasource.username=root -Dspring.datasource.password=******

program参数: --configservice --adminservice
  1. 在apollo-portal里面配置, 数据库密码注意替换
vm: -Dapollo_profile=github,auth -Ddev_meta=http://localhost:8080/ -Dserver.port=8070 -Dspring.datasource.url=jdbc:mysql://localhost:3306/ApolloPortalDB?characterEncoding=utf8 -Dspring.datasource.username=root -Dspring.datasource.password=******
  1. apollo-client端可以通过client端下各个test启动
  2. portal: http://localhost:8070/. eurka: http://localhost:8080/.

源码解析

总体

  • 作者给的架构图


    架构图.png
  • meta服务端主要是屏蔽服务注册发现(细节可看服务注册发现)的,为多种语言准备,与config serivce可以部署在一起
  • client端从config读取配置通过服务注册发现信息,简单客户端轮询调用config service
  • portal端是管理后台,会调用admin端将数据存放到数据库
  • config admin servive共用一个数据库

apollo客户端

概述
  • apollo的客户端会通过定时轮询的方式去获取最新更改的数据,定时轮询启动时,还同时会有长轮询,长轮询是定时轮询实时性的补充,为了保证设计简洁和统一,则由长轮询不返回结果而是让定时轮询马上轮询(此时就有可能有线程竞争),定时轮询get接口所以能保证幂等。如果长轮询返回结果双写,比如两次连续更新,这时间隔短的返回结果,然后push,也会有竞争。
  • 长轮询是使用springmvc DeferredResult, 设置watchkey, 有更新会通知到中间区域,这里是内存,然后长轮询能够接收到通知,细节可看apollo使用springmvc DeferredResult
  • 因为定时和长轮询存在,有可能长轮询马上发起获取数据,所以有轻量竞争,涉及到的变量用automic, automic用volatile修饰变量,提供cas compantandset保证原子性。sync()时因为涉及多个变量改动这里用同步方法。sync也可能涉及长轮询定时轮询同时操作所以也要同步。
客户端获取配置
客户端获取配置.png
客户端获取配置1.6 create步骤深入
uml类图.png
1.6 create步骤深入.png
观察者模式这时可以实现通知
观察者模式实现通知.png

apollo config端

概述
  • 读取直接从release表读,当然有item表各个key value独立的配置,这样能更好看是否重复key。一个命名空间下所有配置是用Json格式记的,这样好获取。appid + clustername + 命名空间能确定一个配置项集合,这都冗余在release表。clustername作用是不同idc不同配置
  • 环境可以通过不同数据库地址,比如dev环境有dev数据库,prod环境有prod环境数据库
总览
总览.png

基于apollo的思考

  • 高可用
  1. 集群
  2. 客户端内存缓存+文件缓存
  • 高可靠
  1. 客户端长轮询 + 定时轮询 长轮询是定时轮询的补充
  2. 配置修改近实时生效
  • 高性能
  1. 客户端缓存
  2. 集群
  3. 配置修改近实时生效
  4. 长轮询的形式避免http请求建立销毁
  5. 服务端用的local cache做缓存,避免一直读取数据库
  6. 本身apollo 各个appid配置数据量不大
  • 高并发
  1. 请求量多,读多写少
  • 安全性
  1. 1.7之后client端调用config service有增加签名key保证安全性
  2. portal调用admin端用spring security授权之类的
  • client端请求服务端负载
  1. 通过eurka服务注册发现知道config service服务集群ip地址,简单的客户端轮询调用。
  • vo dto po总结
  1. Model更侧重UI界面提交“复杂”业务请求。vo,侧重 UI 界面返回复杂业务响应
  2. dto可以在controller和service传输,也可以用在前端到controller传输
  3. PO 对象,可以考虑不暴露给 Controller 层,只在 Service 和 Repository 之间传递和返回
  4. 服务内调用用的标准request response。但是如果管理后台调用的话,dto传输,vo返回,h5前端也走规范
  5. 参考文章Portal源码解析,其中包含vo+dto+po用法总结的图


    总结.png

参考文章

相关文章

网友评论

    本文标题:分布式配置中心Apollo

    本文链接:https://www.haomeiwen.com/subject/uhapaktx.html