Apollo学习笔记——入门

核心概念

application(应用)

实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置，每个应用都需要有一个唯一的身份标识——appId。

environment(环境)

配置对应的环境，比如开发环境、测试环境、生产环境等，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而获取相应的配置。同一份代码部署在不同的环境就应该能够获取到不同环境的配置。一般通过server.properties中的env属性指定。

cluster(集群)

一个应用下不同实例的分组，对不同的cluster，同一个配置可以有不一样的值。

namespace(命令空间)

一个应用下不同配置的分组，可以把namespace类比为文件，不同类型的配置存放在不同的文件中，比如数据库文件、RPC配置文件等。应用可以直接读取到公共组件的配置namespace，也可以通过集成公共组件的配置namespace对组件配置做调整。

整体架构

Config Service

给客户端Client提供配置的获取、推送等功能；

Admin service

给管理界面Portal提供配置的修改、发布等功能。相当于Portal的后台管理系统。

Meta Server

用于封装Eureka的服务发现接口。

Meta Server从Eureka获取Config Service和Admin Service的服务信息，然后Client和Portal通过http接口获取服务信息。

• Client通过域名访问Meta Server获取Config Service服务列表，而后直接通过IP+Port访问服务，同时在Client侧会做负载均衡、错误重试。
• Portal通过域名访问Meta Server获取Admin Service服务列表。

Eureka

提供服务注册和服务发现

• Config Service和Admin Service会向Eureka注册服务，并保持心跳；
• Eureka和Config Service时在一个JVM进程中的。

Portal

• 提供Web界面供用户管理配置

Client

• Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能；

配置发布的大致过程

1、用户在Portal操作配置发布；
2、Portal调用Admin Service的接口操作发布；
3、Admin Service发布配置后，发送ReleaseMessage给各个Config Service；
4、Config Service收到ReleaseMessage后，通知对应的客户端。

发送ReleaseMessage的实现方式

Admin Service 在配置发布之后，需要通知所有的Config Service有配置发布。这个过程是一个典型的消息使用场景，为了尽可能减少外部依赖，没有采用外部消息中间件，而是通过数据库实现了一个简单的消息队列。

1、Admin Service在配置发布之后会往ReleaseMessage表中插入一条消息记录，内容就是配置发布的AppId+Cluster+Namespace。
2、Config Service每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。
3、如果发现有新的记录，那么就会通知到所有的消息监听器。
4、消息监听器得到发布的ReleaseMessage后，会通知对应客户端。

Config Service通知客户端的实现方式

1. 客户端会发起一个Http请求到Config Service的消息监听器；
2. 消息监听器不会立即返回结果，而是通过长连接把请求挂起；
3. 如果60秒内没有改客户端关心的配置发布，那么会返回304给客户端；
4. 如果有该客户端关心的配置发布，消息监听器会调用方法传入有配置变化的namespace信息，同时该请求立即返回，客户端从所返回的结果中获取到namespace后，立即请求Config Service获取该namespace最新配置。