调整后的格式如下，重点部分已加粗处理，便于快速识别重要信息：

---

Apollo的总体架构

Apollo的使用架构

Apollo的不同维度的配置分类

按照生效顺序进行分类：

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

2. Environment

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

3. Cluster（集群）

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

Spring Boot 使用 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 的配置。

代码：**
java 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
    }
  });
  

  调整后的格式如下，重点部分已经加粗并适当添加了段落和代码块，以便于阅读：

---

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
    }
  });