Apollo(阿波罗)是携程框架部门研发的分布式配置中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并且具备规范的权限、流程治理等特性,适用于微服务配置管理场景。
统一管理不同环境、不同集群的配置
配置修改实时生效(热发布)
版本发布管理
灰度发布
权限管理、发布审核、操作审计
客户端配置信息监控
提供Java和.Net原生客户端
提供开放平台API
部署简单
上图简要描述了Apollo的总体设计,我们可以从下往上看:
Config Service:
Admin Service:
Meta Server:
Eureka:
Portal:
Client:
App:
AppNamespace:
Cluster:
Namespace:
Item:
Release:
Audit:
权限相关E-R Diagram:
User:
UserRole:
Role:
RolePermission:
Permission
Consumer:
ConsumerToken:
ConsumerRole:
ConsumerAudit:
在配置中心中,一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。
上图简要描述了配置发布的大致过程:
Admin Service在配置发布后,需要通知所有的Config Service有配置发布,从而Config Service可以通知对应的客户端来拉取最新的配置。
从概念上来看,这是一个典型的消息使用场景,Admin Service作为producer发出消息,各个Config Service作为consumer消费消息。通过一个消息组件(Message Queue)就能很好的实现Admin Service和Config Service的解耦。
在实现上,考虑到Apollo的实际使用场景,以及为了尽可能减少外部依赖,我们没有采用外部的消息中间件,而是通过数据库实现了一个简单的消息队列。
实现方式如下:
如图所示:
上面简要描述了NotificationControllerV2是如何得知有配置发布的,那NotificationControllerV2在得知有配置发布后是如何通知到客户端的呢?
实现方式如下:
上图简要描述了Apollo客户端的实现原理:
Apollo除了支持API方式获取配置,也支持和Spring/Spring Boot集成,集成原理简述如下。
Spring从3.1版本开始增加了ConfigurableEnvironment和PropertySource:
ConfigurableEnvironment
PropertySource
在运行时的结构图形如:
需要注意的是,PropertySource之间是有优先级顺序的,如果有一个Key在多个property source中都存在,那么在前面的property source优先。
所以对上图的例子:
在理解了上述原理后,Apollo和Spring/Spring Boot集成的手段就呼之欲出了:在应用启动阶段,Apollo从远端获取配置,然后组装成PropertySource并插入到第一个即可,如下图所示:
场景 | 影响 | 降级 | 原因 |
---|---|---|---|
某台Config Service下线 | 无影响 | Config Service无状态,客户端重连其它Config Service | |
所有Config Service下线 | 客户端无法读取最新配置,Portal无影响 | 客户端重启时,可以读取本地缓存配置文件。如果是新扩容的机器,可以从其它机器上获取已缓存的配置文件,具体信息可以参考Java客户端使用指南 - 1.2.3 本地缓存路径 | |
某台Admin Service下线 | 无影响 | Admin Service无状态,Portal重连其它Admin Service | |
所有Admin Service下线 | 客户端无影响,Portal无法更新配置 | ||
某台Portal下线 | 无影响 | Portal域名通过SLB绑定多台服务器,重试后指向可用的服务器 | |
全部Portal下线 | 客户端无影响,Portal无法更新配置 | ||
某个数据中心下线 | 无影响 | 多数据中心部署,数据完全同步,Meta Server/Portal域名通过SLB自动切换到其它存活的数据中心 | |
数据库宕机 | 客户端无影响,Portal无法更新配置 | Config Service开启配置缓存后,对配置的读取不受数据库宕机影响 |
Namespace是配置项的集合,类似于一个配置文件的概念。
Apollo在创建项目的时候,都会默认创建一个“application”的Namespace。顾名思义,“application”是给应用自身使用的,熟悉Spring Boot的同学都知道,Spring Boot项目都有一个默认配置文件application.yml。在这里application.yml就等同于“application”的Namespace。对于90%的应用来说,“application”的Namespace已经满足日常配置使用场景了。
客户端获取“application” Namespace的代码如下:
Config config = ConfigService.getAppConfig();
客户端获取非“application” Namespace的代码如下:
Config config = ConfigService.getConfig(namespaceName);
配置文件有多种格式,例如:properties、xml、yml、yaml、json等。同样Namespace也具有这些格式。在Portal UI中可以看到“application”的Namespace上有一个“properties”标签,表明“application”是properties格式的。
注:非properties格式的namespace,在客户端使用时需要调用ConfigService.getConfigFile(String namespace, ConfigFileFormat configFileFormat)来获取,如果使用Http接口直接调用时,对应的namespace参数需要传入namespace的名字加上后缀名,如datasources.json。
apollo-client 1.3.0版本开始对yaml/yml做了更好的支持,使用起来和properties格式一致:Config config = ConfigService.getConfig("application.yml");,Spring的注入方式也和properties一致。
Namespace的获取权限分为两种:
private权限:
private权限的Namespace,只能被所属的应用获取到。一个应用尝试获取其它应用private的Namespace,Apollo会报“404”异常。
public权限:
public权限的Namespace,能被任何应用获取。
Namespace类型有三种:
私有类型:
私有类型的Namespace具有private权限。例如上文提到的“application” Namespace就是私有类型。
公共类型:
公共类型的Namespace具有public权限。公共类型的Namespace相当于游离于应用之外的配置,且通过Namespace的名称去标识公共Namespace,所以公共的Namespace的名称必须全局唯一。
使用场景:
关联类型:
关联类型又可称为继承类型,关联类型具有private权限。关联类型的Namespace继承于公共类型的Namespace,用于覆盖公共Namespace的某些配置。例如公共的Namespace有两个配置项
k1 = v1
k2 = v2
然后应用A有一个关联类型的Namespace关联了此公共Namespace,且覆盖了配置项k1,新值为v3。那么在应用A实际运行时,获取到的公共Namespace的配置为:
k1 = v3
k2 = v2
使用场景:
举一个实际使用的场景。假设RPC框架的配置(如:timeout)有以下要求:
例:
如下图所示,有三个应用:应用A、应用B、应用C。
应用A获取Apollo配置:
//application
Config appConfig = ConfigService.getAppConfig();
appConfig.getProperty("k1", null); // k1 = v11
appConfig.getProperty("k2", null); // k2 = v21
//NS-Private
Config privateConfig = ConfigService.getConfig("NS-Private");
privateConfig.getProperty("k1", null); // k1 = v3
privateConfig.getProperty("k3", null); // k3 = v4
//NS-Public,覆盖公共类型配置的情况,k4被覆盖
Config publicConfig = ConfigService.getConfig("NS-Public");
publicConfig.getProperty("k4", null); // k4 = v6 cover
publicConfig.getProperty("k6", null); // k6 = v6
publicConfig.getProperty("k7", null); // k7 = v7
应用B获取Apollo配置:
//application
Config appConfig = ConfigService.getAppConfig();
appConfig.getProperty("k1", null); // k1 = v12
appConfig.getProperty("k2", null); // k2 = null
appConfig.getProperty("k3", null); // k3 = v32
//NS-Private,由于没有NS-Private Namespace 所以获取到default value
Config privateConfig = ConfigService.getConfig("NS-Private");
privateConfig.getProperty("k1", "default value");
//NS-Public
Config publicConfig = ConfigService.getConfig("NS-Public");
publicConfig.getProperty("k4", null); // k4 = v5
publicConfig.getProperty("k6", null); // k6 = v6
publicConfig.getProperty("k7", null); // k7 = v7
应用C获取Apollo配置:
//application
Config appConfig = ConfigService.getAppConfig();
appConfig.getProperty("k1", null); // k1 = v12
appConfig.getProperty("k2", null); // k2 = null
appConfig.getProperty("k3", null); // k3 = v33
//NS-Private,由于没有NS-Private Namespace 所以获取到default value
Config privateConfig = ConfigService.getConfig("NS-Private");
privateConfig.getProperty("k1", "default value");
//NS-Public,公共类型的Namespace,任何项目都可以获取到
Config publicConfig = ConfigService.getConfig("NS-Public");
publicConfig.getProperty("k4", null); // k4 = v5
publicConfig.getProperty("k6", null); // k6 = v6
publicConfig.getProperty("k7", null); // k7 = v7
ChangeListener
以上代码例子中可以看到,在客户端Namespace映射成一个Config对象。Namespace配置变更的监听器是注册在Config对象上。
所以在应用A中监听application的Namespace代码如下:
Config appConfig = ConfigService.getAppConfig();
appConfig.addChangeListener(new ConfigChangeListener() {
public void onChange(ConfigChangeEvent changeEvent) {
//do something
}
})
在应用A中监听NS-Private的Namespace代码如下:
Config privateConfig = ConfigService.getConfig("NS-Private");
privateConfig.addChangeListener(new ConfigChangeListener() {
public void onChange(ConfigChangeEvent changeEvent) {
//do something
}
})
在应用A、应用B、应用C中监听NS-Public的Namespace代码如下:
Config publicConfig = ConfigService.getConfig("NS-Public");
publicConfig.addChangeListener(new ConfigChangeListener() {
public void onChange(ConfigChangeEvent changeEvent) {
//do something
}
})
Apollo 的部署支持很多种方式,有集成的安装包部署方式、可以使用docker-compose部署、可以使用docker 单独部署、可以使用官方提供的release包部署、也可以通过源码自己打包部署等。
(其实建议直接看github上的官方说明 )
本文由 寻非 创作,如果您觉得本文不错,请随意赞赏
采用 知识共享署名4.0 国际许可协议进行许可
本站文章除注明转载/出处外,均为本站原创或翻译,转载前请务必署名
原文链接:https://www.zhouning.group/archives/springcloud16配置中心之apollo上
最后更新:2020-05-29 11:28:54
Update your browser to view this website correctly. Update my browser now