Apollo是一个分布式配置管理中心。是由携程团队开发，官方文档更为详尽，本文主要是自己看后的一些总结，需要学习的小伙伴可以移步 Apollo官方指南，因为官方写的更好。
为什么需要配置管理中心？
在分布式环境下，需要集中配置，统一管理，修改配置后需要进行配置分发，还需要关心配置的生效时间等等。这些只是功能性的，还有服务方面，如何容灾等等。
Apollo的优势
1.简单易用的配置化界面
2.可以隔离环境（开发、测试、预发、线上）、隔离集群
3.操作人权限管控
4.配置多版本，方便回退，配置历史版本查阅
5.配置修改实时生效
等等
Apollo的架构
Apollo架构
-
Load Balancer，其实是借助NGINX做的SLB，由于MetaService也是无状态的多集群，所以nginx还进行域名反向代理的作用，可参考架构V4/V5
-
MetaService 可以认为是 Eureka的客户端proxy，因为他对接client和Portal（可以认为是配置console），所以需要区分调用的是 configService还是AdminService的逻辑，以及服务软负载等
-
ConfigService对接 client，进行配置通知推送及配置拉取
-
AdminService对接Portal，进行配置维护。以及通知ConfigService 配置变更消息
-
Eureka 注册中心，与ZK类似。与springCloud无缝对接、开源、服务发现等特点
配置发布后的实时推送设计
用户在Portal发布配置后的链路如下
-
用户修改配置
-
通过MetaService 调用 AdminService 写入配置
-
AdminService写入配置后，在mysql里插入发布消息
-
ConfigService 定时读取消息表，发现变动后推送通知到client
AdminService和ConfigService
AdminService通知ConfigService没有通过消息机制，apollo为了尽可能少的外部依赖，通过数据库存储来变相实现推送通知。
-
Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录
-
Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录
-
Config Service如果发现有新的消息记录，那么就会通知到client所有的消息监听器[NotificationControllerV2]
ConfigService 如何通知Client
NotificationControllerV2得到配置发布的消息后，如何通知client呢？
client和ConfigSerivce是通过HTTP Long Polling实现的长连接，准确的叫长轮询，所以下面的步骤是一个不断轮询的过程：
- 客户端会发起一个Http请求到Config Service的notifications/v2接口
- NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
- 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端，接着发起下一次轮询
- 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。
- 客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置
Client To Proxy 的交互
-
用户修改配置，ConfigService通知client
-
client定时调用ConfigService，作为配置更新推送的后补方案，放置推送失效。定时频率每分钟5次
-
应用程度读取配置，首先从内存读取
-
client 会把从服务端获取到的配置在本地文件系统缓存一份，当apollo服务不可用时，client读取本地配置缓存文件
网友评论