讨论下采用集群名称拉取配置时的策略问题？

[klboke]

讨论问题：

当指定了 idc = test 后，apollo 会尝试获取 test 的发布配置，如果没找到就尝试获取 dataCenter 的配置，还没找到就直接获取 default 的配置返回了。这里有一个默认的 fallback 机制，这个 fallback 是否加上一个可控制的开关要更好点？？启用或关闭。启用则按照当前的 fallback 策略加载，关闭则直接返回未找到配置。

相关页面ui：

这里的提示不是很准确，当我尝试使用一个未创建并不存在的集群名称时，也会 fallback 到 默认的集群配置给我。在这个场景，当我不小心配置出错的情况下，是不是显示的抛出问题比 fallback 有可能隐藏了问题更好点？？？

关键代码：

  public Release loadConfig(String clientAppId, String clientIp, String configAppId, String configClusterName,
      String configNamespace, String dataCenter, ApolloNotificationMessages clientMessages) {
    // load from specified cluster fist
    if (!Objects.equals(ConfigConsts.CLUSTER_NAME_DEFAULT, configClusterName)) {
      Release clusterRelease = findRelease(clientAppId, clientIp, configAppId, configClusterName, configNamespace,
          clientMessages);

      if (Objects.nonNull(clusterRelease)) {
        return clusterRelease;
      }
    }

    // try to load via data center
    if (!Strings.isNullOrEmpty(dataCenter) && !Objects.equals(dataCenter, configClusterName)) {
      Release dataCenterRelease = findRelease(clientAppId, clientIp, configAppId, dataCenter, configNamespace,
          clientMessages);
      if (Objects.nonNull(dataCenterRelease)) {
        return dataCenterRelease;
      }
    }

    // fallback to default release
    return findRelease(clientAppId, clientIp, configAppId, ConfigConsts.CLUSTER_NAME_DEFAULT, configNamespace,
        clientMessages);
  }

[lepdou]

这个开关感觉可以有。

不过应该得考虑一下开关的粒度，namespace 的粒度，app粒度，还是全局粒度合适？还是说也搞成优先级，namespace >app>globel

[nobodyiam]

目前的逻辑确实如 @klboke 所描述的，详见配置获取规则说明。

开关的话我觉得可以如 @lepdou 所说的，有几个不同粒度，namespace > app > global

这里还有另一个要考虑的点是这个开关是否只对 private namespace 生效？对于 public namespace 的维护者而言，不太可能按照每个应用的集群去维护一份配置信息

[klboke]

开关的力度：namespace > app > global

这个点不是很明白。其实目前的实现，fallback 机制只存在于 cluster ，如果我指向了不存在 namespace 、 appid 并不会 fallback 到默认的返回。这里的期望也是可以控制遇到未发布配置或者指向了不存在的 cluster 时，fallback 或者不 fallback。一般更倾向不 fallback，显示的告诉使用者这个 cluster 并没找到配置

如果 cluster 作为隔离配置的粒度的话，是不是不区分 private namespace 或 public namespace 更好点，可能我们对 public namespace 的使用场景不一样。我举个栗子，我在香港集群的公共注册中心，和北京集群的公共注册中心要分隔开，因为北京的服务不会连接到香港那边去，所以在 apollo 上只维护一个 public namespace 可能做不到

[lepdou]

fallback 到 default 配置还是有很多场景的。

因为绝大部分业务场景，一个环境所有的 cluster 的配置应该公用一份 default（相当于环境粒度） 就够了，只有在某个 cluster 需要推送特殊值时，才需要在这个 cluster 下的namespace 覆盖配置项，然后推送 namespace。如果默认做成不 fallback，那么一旦用户建了多个 cluster，就需要同时维护所有 cluster 的配置，成本非常大。

另外像阿里大促的场景下，每次大促都需要新建好几个 cluster，如果没有 fallback 机制，那么需要为新建的 cluster 都要维护配置，成本极高。

蚂蚁的配置中心，一开始就是没有这种fallback机制，后来我就改成了两层的 fallback 机制，极大的降低了运维成本。

[klboke]

嗯，场景确实是存在的，只是大部分场景下，可能并不像 阿里这种体量的能轻易创建一个 cluster 。所以，我考虑的点以及我们遇到的问题是，开发配置 idc 时，写错了(没有创建这个 idc)，但是因为 fallback 机制，拉到了 default 的配置，程序也跑起来了，没人发现有问题，其实 default 和 指定 idc 配置内容完全不一样。那么，在这个场景下，是否可以增加一个让用户可选的开关，控制 cluster fallback 机制的开启关闭

[Anilople]

是否可以像Javascript那样，添加一个strict模式？

在client端通过配置来控制

打开全局开关后

apollo.strict.global.enabled = true

会关闭所有fallback，严格按照 appId + cluster + namespace 获取配置

如果想细分，例如只关闭cluster的fallback

可以写成

apollo.strict.cluster.enabled = true

还可以关闭读取本地文件缓存

apollo.strict.local-cache.enabled = true

[nobodyiam]

客户端指定倒是一个不错的思路，@klboke 看看是否能解决你实际遇到的问题？

[klboke]

嗯，是一个不错的思路，这个问题是不是可以反过来看，默认不提供 fallback 要更好点（现有的 fallback 不仅针对新建的未发布的 namespace 的 cluster，对不存在的 cluster 也会 fallback）？如果新建的集群需要 default 的配置的话，就指定 fallback 的策略来拉配置，也解决了 @lepdou 说的大规模 cluster 新建的场景问题

[nobodyiam]

这个问题是不是可以反过来看，默认不提供 fallback 要更好点

这个问题放在设计初始倒是可以值得讨论的，不过现在在用户大规模使用的情况下，我们是无法修改默认行为的

[klboke]

确实是的，不过，如果默认不是关闭 fallback，客户端增加控制的开关就意义不是很大了。如果使用者有意识指定不 fallback ，那么他的获取 apollo 的配置大概率也不会有问题，增加这个参数也会增加使用者的使用成本和理解成本。更倾向使用 ServerConfig 来管理维护这个开关，由运维 apollo 的人来管控

[lepdou]

想了一下 fallback 导致出问题的概率应该极低，主要几个点：

1. cluster 参数一般不是由开发人员代码里指定的，要么是运维人员作为机器的属性写到机器上，要么是作为应用粒度的一个全局配置。也就是说变更的次数极少
2. cluster 值是代码里的一个静态配置值，发布周期是经过测试环境，预发环境，最后才到生产环境。在经过多个环境的测试之后，同时又是静态的配置，所以出错的概率就更低了

基于以上论点，把这个开关放到 client 端其实意义不是很大，本质原因是 cluster 配置是全局的静态配置，并不是在代码里到处零散的。在静态配置之上再加一层静态开关，感觉有些多余。

结论：
所以综上所述，我觉得应该以功能性目的为主，维持当前的 fallback 机制。如果默认不 fallback 会增加多集群的配置管理复杂度。

可以从用户提的 issue 统计一下，遇到cluster误配错导致的问题多少，如果不多的话，应该说明问题不大~

[klboke]

想了一下 fallback 导致出问题的概率应该极低

fallback 导致出问题的概率确实挺低的。我简单描述下这边触发的场景（不存在的 cluster 也会 fallback 是看代码后知道的）：项目从 apollo 拉取配置时，因为相关集群的配置忘记发布了，导致 fallback 到 default 了，应用一切正常上线，然后因为配置没对应上导致运行很久后才发现。

本质原因是 cluster 配置是全局的静态配置，并不是在代码里到处零散的

cluster 设计之初可能确实如上两点所述，但是在实际应用中，也会用 cluster 来区分环境，prod、test 、 prod-a 、prod-b 这种环境区分，既然区分了环境，有些配置也会不一样。这种用法可能还比较多，可以在社区里发起一个问卷看看，应该是个有意思的事情

我觉得应该以功能性目的为主，维持当前的 fallback 机制

如果真的改动，通过配置驱动的话，也会默认保持当前的 fallback 机制，只是给使用者多一个可控的开关。

[nobodyiam]

默认行为我认为还是要保持当前 fallback 逻辑的，服务端增加是否允许 fallback 的配置项听上去也合理，开关的配置方式和优先级可以讨论下，比如是否是：namespace > app > global，以及对 private namespace 和 public namespace 是否是不同的配置规则