相较嫡系的SpringCloudConfig，为什么选择使用Apollo作为微服务的配置中心？

最新推荐文章于 2024-05-14 20:45:48 发布

初晨的笔记

最新推荐文章于 2024-05-14 20:45:48 发布

阅读量6.1k

点赞数 4

分类专栏： apollo 文章标签： apollo Springboot config SpringCloudConfig

本文链接：https://blog.csdn.net/weixin_39879073/article/details/89224839

版权

3 篇文章 0 订阅

订阅专栏

SpringCloudConfig VS Apollo.jpg

如上图对比

SpringCloudConfig优势是对SpringBoot原生支持，且是SpringCloud组件。缺点是无界面管理，且需要git，SpringCloudBus、Mq支持其动态更新。
Apollo优势是技术栈单一，仅需要Mysql就可以支持动态更新配置，便于维护。缺点是不是SpringCloud体系，虽然开源，版本更新也活跃，但是对SpringCloud的支持没有SpringCloudConfig的好。

Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。

Apollo支持4个维度管理Key-Value格式的配置：

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进程中

客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
- 这是一个fallback机制，为了防止推送机制失效导致配置不更新
- 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
- 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。
客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
客户端会把从服务端获取到的配置在本地文件系统缓存一份
在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

客户端发起一个Http请求到服务端
服务端会保持住这个连接60秒
- 如果在60秒内有客户端关心的配置变化，被保持住的客户端请求会立即返回，并告知客户端有配置变化的namespace信息，客户端会据此拉取对应namespace的最新配置
- 如果在60秒内没有客户端关心的配置变化，那么会返回Http状态码304给客户端
客户端在收到服务端请求后会立即重新发起连接，回到第一步

考虑到会有数万客户端向服务端发起长连，在服务端我们使用了async servlet(Spring DeferredResult)来服务Http Long Polling请求。

关注