Apollo（阿波罗）配置中心

浅思浅影

已于 2024-03-20 17:01:05 修改

阅读量850

点赞数 3

分类专栏：分布式文章标签：分布式 Apollo 配置中心微服务

于 2024-03-20 11:22:42 首次发布

本文链接：https://blog.csdn.net/jingzhi111/article/details/136869471

版权

分布式专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Apollo（阿波罗）配置中心：

采用分布式架构，它能够集中管理不同环境、不同集群的配置，配置修改后能够实时推送到应用端，有可视化界面和规范的权限，支持版本管理、灰度发布、监控等功能。

主要模块及功能：

AdminService：服务于管理界面。提供配置管理、配置修改发布

ConfigService：服务于客户端。配置获取、配置推送

Client：应用客户端，获取应用配置，支持实时更新。通过MetaServer获取ConfigService的服务列表，使用客户端软负载SLB方式调用ConfigService

Portal：配置管理界面。通过MetaServer获取AdminService的服务列表，使用客户端软负载SLB方式调用AdminService

Eureka：服务注册、发现。Config/AdminService注册实例并定期报心跳，和ConfigService组在一起部署

MetaServer：

NginxLB：

配置更新流程：

Portal(发布) ——> AdminService(保存) ——> ConfigDB(ReleaseMessage) <—— (读取)ConfigService(通知) <—— > (拉)Client

1、用户首先在 Portal 管理界面操作配置发布

2、Portal 调用 Admin Service 的接口操作发布

3、Admin Service 在配置发布后会往 ReleaseMessage 表插入一条消息记录（AppId+Cluster+Namespace）

4、Config Service 有一个线程会每秒扫描一次 ReleaseMessage 表，看是否有新的消息记录

5、客户端会发起一个HTTP请求到 Config Service 的notifications/v2接口，建立60s的长连接，当做监听器

6、Config Service 如果发现有新的消息记录，就会通知 AppId+Cluster+Namespace给所有的消息监听器，监听器接口返回变化的配置的 Namespace 给客户端。

监听器如果在 60 秒内没有得到客户端关心的配置发布，会返回 HTTP 状态码 304给客户端，客户端再次重试

7、客户端再立即请求 Config Service 获取该 Namespace 的最新配置。

8、此外，Apollo 提供了容错机制，防止长连接的推送机制失效导致配置无法更新，客户端会定时主动向 Apollo 拉取配置，该定时频率默认为 5 分钟

ConfigService/AdminService/ConfigDB 三者在每个环境 (DEV/FAT/UAT/PRO) 中都要部署一份。

一套 Portal 就可以集中管理多套环境 (DEV/FAT/UAT/PRO) 中的配置。

Eureka 服务注册中心：ConfigService注册后 Client 就能找到它； ConfigService注册了，Portal 就能找到它。两个Service定期发送保活心跳。

（一）Apollo 和 Spring Cloud Config 区别

区别点	Apollo	Spring Cloud Config
配置界面	有界面管理不同环境、不同集群配置	没有，需要通过 git 操作
生效时间	实时	重启生效，或手动refresh 生效；Config 需要通过 Git webhook，加上额外的消息队列才能支持实时生效
版本管理	界面上有发布历史和回滚按钮	没有，需要通过git操作
灰度发布	支持灰度给部分实例	不支持
权限审核	支持修改、发布权限分离	需要通过 git 仓库设置，不支持权限分离
监控	可以看到当前哪些客户端在使用哪些配置	不支持
配置获取性能	快，通过数据库访问+缓存支持	较慢，需要从 git clone repository，然后从文件系统读取
客户端支持	原生支持 Java 和 .Net 应用；提供 API 支持其它语言应用	支持 Spring 应用，提供 annotation 获取配置