首先Apollo整体架构主要就是config service（提供给客户端读取和推送的功能），Admin Service（提供给服务端配置修改，发布的功能）
然后他们是多实例部署的，会注册到注册中心Eureka。
客户端会先通过注册中心获取config service 和 admin service 服务地址。然后去访问对应的服务
:::tips 1.1 各模块职责
- 上图简要描述了Apollo的总体设计，我们可以从下往上看：
- Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
- Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
- Eureka提供服务注册和发现，为了简单起见，目前Eureka在部署时和Config Service是在一个JVM进程中
- Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
- 在Eureka之上架了一层Meta Server用于封装Eureka的服务发现接口
- Client通过域名访问Meta Server获取Confifig Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
- Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
1.2 分步执行流程
- Apollo启动后，Config/Admin Service会自动注册到Eureka服务注册中心，并定期发送保活心跳。
- Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载均衡器)进行负载均衡后分配到某一个Meta Server
- Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client
- Meta Server获取Config Service和Admin Service（IP+Port）失败后会进行重试
获取到正确的Config Service和Admin Service的服务信息后，Apollo Client通过Config Service为应用提供配置获取、实时更新等功能；Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能
:::
配置发布的原理是什么呢？
首先 config service 会有一个线程定时的扫表，判断有没有配置更新。如果有配置更新，会通知客户端配置更新。
客户端获取改变的 app cluster namespace ， 然后获取最新的配置信息。
以上是客户端和服务端保持一个长连接， 客户端自己也会有相关的设计，会定时的从阿波罗进行拉去最新的配置。
这是一个备用机制，为了防止推送机制失效导致配置不更新
客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval 来覆盖，单位为分钟