Apolle 基础篇

Apolle官方git地址：https://github.com/ctripcorp/apollo

基础知识

功能点

• 统一管理不同环境、不同集群的配置
• 配置修改实时生效（热发布）
• 版本发布管理
• 灰度发布
• 权限管理、发布审核、操作审计
• 客户端配置信息监控（这里是指被哪些实例使用）
• 提供Java和.Net原生客户端
• 提供开放平台API
• 部署简单

基本概念

application (应用)：

• 这个很好理解，就是实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置
• 每个应用都需要有唯一的身份标识 -- appId，我们认为应用身份是跟着代码走的，所以需要在代码中配置，具体信息请参见Java客户端使用指南。

environment (环境)

• 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
• 我们认为环境和代码无关，同一份代码部署在不同的环境就应该能够获取到不同环境的配置
• 所以环境默认是通过读取机器上的配置（server.properties中的env属性）指定的，不过为了开发方便，我们也支持运行时通过System Property等指定，具体信息请参见Java客户端使用指南。

cluster (集群)

• 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
• 对不同的cluster，同一个配置可以有不一样的值，如zookeeper地址。
• 集群默认是通过读取机器上的配置（server.properties中的idc属性）指定的，不过也支持运行时通过System Property指定，具体信息请参见Java客户端使用指南。

namespace (命名空间)

• 一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
• 应用可以直接读取到公共组件的配置namespace，如DAL，RPC等
• 应用也可以通过继承公共组件的配置namespace来对公共组件的配置做调整，如DAL的初始数据库连接数

总体设计

上图简要描述了Apollo的总体设计，我们可以从下往上看：

• Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
• Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
• 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客户端的实现原理：

• 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。
• 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。

1. 这是一个fallback机制，为了防止推送机制失效导致配置不更新
2. 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
3. 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: apollo.refreshInterval来覆盖，单位为分钟。

• 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
• 客户端会把从服务端获取到的配置在本地文件系统缓存一份
• 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
• 应用程序从Apollo客户端获取最新的配置、订阅配置更新通知

 

Apollo安装不是使用请查看Apollo 安装部署篇 及Apolle 客户端使用