Apollo的总体架构

Apollo的总体架构

Apollo的使用架构

Apollo的使用架构

Apollo的不同维度的配置分类

下面按照生效顺序

  1. Application
    在springboot的application.property定义appid这个key的value，标识该类型的应用。

  2. Environment

    • DEV（开发环境）
    • FAT（功能测试）
    • UAT（验收测试）
    • PRO（生产环境）

  3. Cluster(集群)

  4. Namespace(命名空间)
    其实就是某个应用的不同配置文件

Springboot使用apollo时的配置

# apollo配置，需要先创建一个应用，然后再创建这个应用相关的配置信息
# 指定apollo上面对应的应用id,程序会根据这个id去找到apollo上面对应的应用的配置
app.id: middleend-product
apollo:
  #指定对应的集群
  cluster: local
  #apollo的配置中心地址
  meta:  http://dev-config.aeonbuy.com
  bootstrap:
    #在应用启动阶段是否向Spring容器注入被托管的properties文件配置信息
    enabled: true
    #指定要加载的命名空间
    namespaces: application,common-ms,common-excel,common-exception,auth
    eagerLoad:
    #将Apollo配置加载提到初始化日志系统之前
      enabled: true

上面的配置中就差 Environment没有了，Environment的配置方式如下：
在这里插入图片描述

常用API

Config config = ConfigService.getAppConfig();

当应用使用上面的语句获取配置时，我们称之为获取应用自身的配置，也就是应用自身的application namespace的配置

  1. 首先查找运行时cluster的配置（通过apollo.cluster指定）
  2. 如果没有找到，则查找数据中心cluster的配置
  3. 如果还是没有找到，则返回默认cluster的配置

查找顺序
数据中心是机器上的配置（server.properties中的idc属性）指定的
所以如果应用部署在A数据中心，但是用户没有在Apollo创建cluster，那么获取的配置就是默认cluster（default）的。

如果应用部署在A数据中心，同时在运行时指定了SomeCluster，但是没有在Apollo创建cluster，那么获取的配置就是A数据中心cluster的配置，如果A数据中心cluster没有配置的话，那么获取的配置就是默认cluster（default）的。
Apollo客户端会把从服务端获取到的配置在本地文件系统缓存一份，当去服务器读取配置失败时，会使用本地缓存的。

Mac/Linux: /opt/data/{appId}/config-cache

Windows: C:\opt\data{appId}\config-cache

Config pubConfig = ConfigService.getConfig("xxxxxx");

获取指定 namespace的配置

NameSpace的详解

  1. 什么是Namespace?
    Namespace是配置项的集合，类似于一个配置文件的概念。

  2. 什么是“application”的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);
3. Namespace的格式有哪些？
配置文件有多种格式，例如：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。

  1. Namespace的获取权限分类
    Namespace的获取权限分为两种：

private （私有的）
public （公共的）
这里的获取权限是相对于Apollo客户端来说的。

4.1 private权限
private权限的Namespace，只能被所属的应用获取到。一个应用尝试获取其它应用private的Namespace，Apollo会报“404”异常。

4.2 public权限
public权限的Namespace，能被任何应用获取。

  1. Namespace的类型
    Namespace类型有三种：

私有类型
公共类型
关联类型（继承类型）
5.1 私有类型
私有类型的Namespace具有private权限。例如上文提到的“application” Namespace就是私有类型。

5.2 公共类型
5.2.1 含义
公共类型的Namespace具有public权限。公共类型的Namespace相当于游离于应用之外的配置，且通过Namespace的名称去标识公共Namespace，
所以公共的Namespace的名称必须全局唯一。

5.2.2 使用场景
部门级别共享的配置
小组级别共享的配置
几个项目之间共享的配置
中间件客户端的配置
5.3 关联类型
5.3.1 含义
关联类型又可称为继承类型，关联类型具有private权限。关联类型的Namespace继承于公共类型的Namespace，用于覆盖公共Namespace的某些配置。
例如公共的Namespace有两个配置项

k1 = v1
k2 = v2
然后应用A有一个关联类型的Namespace关联了此公共Namespace，且覆盖了配置项k1，新值为v3。那么在应用A实际运行时，获取到的公共Namespace的配置为：

k1 = v3
k2 = v2
5.3.2 使用场景
举一个实际使用的场景。假设RPC框架的配置（如：timeout）有以下要求：

提供一份全公司默认的配置且可动态调整
RPC客户端项目可以自定义某些配置项且可动态调整
如果把以上两点要求去掉“动态调整”，那么做法很简单。在rpc-client.jar包里有一份配置文件，每次修改配置文件然后重新发一个版本的jar包即可。同理，客户端项目修改配置也是如此。
如果只支持客户端项目可动态调整配置。客户端项目可以在Apollo “application” Namespace上配置一些配置项。在初始化service的时候，从Apollo上读取配置即可。这样做的坏处就是，每个项目都要自定义一些key，不统一。
那么如何完美支持以上需求呢？答案就是结合使用Apollo的公共类型的Namespace和关联类型的Namespace。RPC团队在Apollo上维护一个叫“rpc-client”的公共Namespace，
在“rpc-client” Namespace上配置默认的参数值。rpc-client.jar里的代码读取“rpc-client”Namespace的配置即可。
如果需要调整默认的配置，只需要修改公共类型“rpc-client” Namespace的配置。
如果客户端项目想要自定义或动态修改某些配置项，只需要在Apollo 自己项目下关联“rpc-client”，
就能创建关联类型“rpc-client”的Namespace。然后在关联类型“rpc-client”的Namespace下修改配置项即可。
这里有一点需要指出的，那就是rpc-client.jar是在应用容器里运行的，所以rpc-client获取到的“rpc-client”
Namespace的配置是应用的关联类型的Namespace加上公共类型的Namespace。
5.4 例子
如下图所示，有三个应用：应用A、应用B、应用C。

应用A有两个私有类型的Namespace：application和NS-Private，以及一个关联类型的Namespace：NS-Public。
应用B有一个私有类型的Namespace：application，以及一个公共类型的Namespace：NS-Public。
应用C只有一个私有类型的Namespace：application
Namespace例子

5.4.1 应用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
5.4.2 应用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
5.4.3 应用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
5.4.4 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
}
})

Logo
西安城市开发者社区

欢迎加入西安开发者社区！我们致力于为西安地区的开发者提供学习、合作和成长的机会。参与我们的活动，与专家分享最新技术趋势，解决挑战，探索创新。加入我们，共同打造技术社区！

更多推荐

cover

如何完美解决 Redis 错误：Couldn‘t set client name. NOAUTH Authentication required

avatar 西安城市开发者社区
cover

如何完美解决 Nginx出现 404 Not Found nginx/1.23.4 解决方案

avatar 西安城市开发者社区
cover

启动ChatGPT 的快捷键，探索全新 ChatGPT MacOS 应用程序！

avatar 西安城市开发者社区