分布式配置中心Apollo

目录

• 环境搭建
• 源码解析
• 基于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

3. 在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=******

4. apollo-client端可以通过client端下各个test启动
5. 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篇
• github-apollo
• apollo微服务架构
• Portal源码解析，其中包含vo+dto+po用法总结