相较嫡系的SpringCloudConfig，为什么选择使用Ap
2019-04-12 本文已影响0人
初晨的笔记
目录
1、SpringCloudConfig和Apollo的对比
2、apollo的介绍
3、apollo架构设计原理
4、客户端通过apollo拉取配置的原理
1、SpringCloudConfig和Apollo的对比
SpringCloudConfig VS Apollo.jpg
如上图对比
- SpringCloudConfig优势是对SpringBoot原生支持，且是SpringCloud组件。缺点是无界面管理，且需要git，SpringCloudBus、Mq支持其动态更新。
- Apollo优势是技术栈单一，仅需要Mysql就可以支持动态更新配置，便于维护。缺点是不是SpringCloud体系，虽然开源，版本更新也活跃，但是对SpringCloud的支持没有SpringCloudConfig的好。
2、apollo的介绍
Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
Apollo支持4个维度管理Key-Value格式的配置：
- application (应用)
- environment (环境)
- cluster (集群)
- namespace (命名空间)
同时，Apollo基于开源模式开发，开源地址
3、apollo架构设计原理
overall-architecture.jpg
上图简要描述了Apollo的总体设计，我们可以从下往上看：
- Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
- Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
- Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
- Client通过域名访问Meta Server获取ConfigService服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在
Client侧会做load balance、错误重试 - Portal通过域名访问Meta Server获取AdminService服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在
Portal侧会做load balance、错误重试 - 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
4、客户端通过apollo拉取配置的原理
client-architecture.jpg
上图简要描述了Apollo客户端的实现原理：
- 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
- 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
- 这是一个fallback机制，为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
- 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
- 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
- 客户端会把从服务端获取到的配置在本地文件系统缓存一份
- 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
- 应用程序从Apollo客户端获取最新的配置、订阅配置更新通知
配置更新推送实现
- 前面提到了Apollo客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
- 长连接实际上我们是通过Http Long Polling实现的，具体而言：
- 客户端发起一个Http请求到服务端
- 服务端会保持住这个连接60秒
- 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
- 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
- 客户端在收到服务端请求后会立即重新发起连接，回到第一步
- 考虑到会有数万客户端向服务端发起长连，在服务端我们使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。
