Apollo工作原理
Apollo架构模块的概览
上图简要描述了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获取Config 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进程中
分步执行流程
- 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提供配置新增、修改、发布等功能
核心概念
- application (应用)
这个很好理解,就是实际使用配置的应用,Apollo客户端在运行时需要知道当前应用是谁,从而可以去获取
对应的配置
关键字:appId - environment (环境)
配置对应的环境,Apollo客户端在运行时需要知道当前应用处于哪个环境,从而可以去获取应用的配置
关键字:env - cluster (集群)
一个应用下不同实例的分组,比如典型的可以按照数据中心分,把上海机房的应用实例分为一个集群,把北
京机房的应用实例分为另一个集群。
关键字:cluster - namespace (命名空间)
一个应用下不同配置的分组,可以简单地把namespace类比为文件,不同类型的配置存放在不同的文件中,
如数据库配置文件,RPC配置文件,应用自身的配置文件等
关键字:namespaces
它们的关系如下图所示: