目录
- 环境搭建
- 源码解析
- 基于apollo的思考
- 参考文章
环境搭建
- 先执行apollo项目下的scripts初始化数据库
- 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
- 在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=******
- apollo-client端可以通过client端下各个test启动
- 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类图.png1.6 create步骤深入.png
观察者模式这时可以实现通知
观察者模式实现通知.pngapollo config端
概述
- 读取直接从release表读,当然有item表各个key value独立的配置,这样能更好看是否重复key。一个命名空间下所有配置是用Json格式记的,这样好获取。appid + clustername + 命名空间能确定一个配置项集合,这都冗余在release表。clustername作用是不同idc不同配置
- 环境可以通过不同数据库地址,比如dev环境有dev数据库,prod环境有prod环境数据库
总览
总览.png基于apollo的思考
- 高可用
- 集群
- 客户端内存缓存+文件缓存
- 高可靠
- 客户端长轮询 + 定时轮询 长轮询是定时轮询的补充
- 配置修改近实时生效
- 高性能
- 客户端缓存
- 集群
- 配置修改近实时生效
- 长轮询的形式避免http请求建立销毁
- 服务端用的local cache做缓存,避免一直读取数据库
- 本身apollo 各个appid配置数据量不大
- 高并发
- 请求量多,读多写少
- 安全性
- 1.7之后client端调用config service有增加签名key保证安全性
- portal调用admin端用spring security授权之类的
- client端请求服务端负载
- 通过eurka服务注册发现知道config service服务集群ip地址,简单的客户端轮询调用。
- vo dto po总结
- Model更侧重UI界面提交“复杂”业务请求。vo,侧重 UI 界面返回复杂业务响应
- dto可以在controller和service传输,也可以用在前端到controller传输
- PO 对象,可以考虑不暴露给 Controller 层,只在 Service 和 Repository 之间传递和返回
- 服务内调用用的标准request response。但是如果管理后台调用的话,dto传输,vo返回,h5前端也走规范
-
参考文章Portal源码解析,其中包含vo+dto+po用法总结的图
总结.png
网友评论