Apollo架构简聊

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实现的长连接，准确的叫长轮询，所以下面的步骤是一个不断轮询的过程：

1. 客户端会发起一个Http请求到Config Service的notifications/v2接口
2. NotificationControllerV2不会立即返回结果，而是通过Spring DeferredResult把请求挂起
3. 如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码304给客户端，接着发起下一次轮询
4. 如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立即返回。
5. 客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config Service获取该namespace的最新配置

Client To Proxy 的交互

• 用户修改配置，ConfigService通知client

• client定时调用ConfigService，作为配置更新推送的后补方案，放置推送失效。定时频率每分钟5次

• 应用程度读取配置，首先从内存读取

• client 会把从服务端获取到的配置在本地文件系统缓存一份，当apollo服务不可用时，client读取本地配置缓存文件