[Feature Request] 根据不同时间段对于同一个 config 获取到不同的配置

[jiming]

Dear @nobodyiam

比如有个配置 loadLevel，

default 配置是 normal

但是在双十一的时候就会根据时间调整成相应的值

start_time	stop_time	value
2017.11.10 23:0:0	2017.11.12 0:0:0	preheavy
2017.11.11 0:0:0	2017.11.12 0:0:0	heavy
2017.11.12 0:0:0	2017.11.12 1:0:0	afterheavy

等过了双十一后一小时 2017.11.12 1:0:0， 则 loadLevel 又恢复成 normal

实现方面，我觉得可以给配置项加个子表，跟主表之间是 1:0-* 关系。

这个需要客户端和服务端都支持。

有了这功能就不用改代码或者大半夜的起来调整参数了

我觉得这功能可能会是个亮点啊。

[jiming]

• 还可以给子选项加上 priority, enabled, condition 选项，进行更细粒度的筛选排查
• 只有没有匹配的子选项时，采用 default 值
• 除了起始结束时间之外，还可以考虑添加其他的过滤条件
• 可以在 java client 添加个方法 config.getProperty(someKey, someDefaultValue， Function); 让用户自己写代码根据 condition 字段来过滤符合条件的子选项

这样配置管理系统的功能就可以超级强悍了

[nobodyiam]

感谢建议，这个其实简化一下就是配置的定时生效功能，用来解决在特定时间使特定配置生效的情况。

或许是否可以再简化一些，比如是配置在某个时刻自动发布之类的？

[jiming]

@nobodyiam 您好：

我没太明白某个时刻自动发布的含义？是指让用户自己通过 cron 之类的机制自动修改配置吗？

[nobodyiam]

自动发布如果要做，那应该是在Portal界面上，比如发布的时候可以设置一个生效时间，以区别于立即生效

[jiming]

其实我的这个值就是希望在不同的时间段(或者其他的 condition 下 )返回不同的值，所以，如果能在配置管理后台进行调整，那么我的代码就会非常简单。

String loadLevel = config.getProperty("loadLevel"); // 根据当前时间范围，返回相应的配置值
switch (loadLevel) {
case "normal":
...
break;
case "preheavy":
...
break;
case "heavy":
...
break;
case "afterheavy":
...
break;
}

这个配置可以放到应用里，也可以放到 apollo 里。不过我觉得如果 apollo 如果可以实现的话，那就更好了。因为这个功能还是有比较有通用性的。

[easonjim]

我觉得可以这样实现
1、项目实现一个定时服务
2、通过调用API方法，然后到点自动提交配置到Apollo
3、Apollo接收到配置后会分发到接入的Client

[jiming]

@easonjim

你的方案是可行的。不过如果是有多个配置都是这样的场景的话，那我们还得开发一个小模块来维护这些配置。

所以，我是希望 apollo 能够原生支持这个功能，因为它也算是配置的一部分（可以认为是配置生效规则）。这样我们在 apollo 后台直接配置了就可以用了。

[lepdou]

@jiming
感觉比较简单的方式是：

1. 用户可以在portal上配置一个配置项的时候，选择生效时间段的规则，就比如你提到的例子
2. client在向server获取配置的时候，把规则也返回给client
3. client每次getConfig的时候，运算一下规则就可以了。对于没有规则的配置项就不用计算

这样的好处是，服务端很轻，维护的状态少。

类似于灰度的实现原理：
给每个配置项带上生效的IP列表，client自己判断是不是在这个列表里面，如果是就用灰度的配置，否则就用default的值。

不过目前apollo的灰度实现是在服务端做的，扩展性就没有在客户端实现灰度来得好。比如，多灰度版本。

另外你提到的“还可以给子选项加上 priority, enabled, condition 选项，进行更细粒度的筛选排查”
我个人觉得，配置尽可能简单一些，目前像priority, enabled这种，应该是没有场景的。

[jiming]

@lepdou

1. 用户可以在portal上配置一个配置项的时候，选择生效时间段的规则，就比如你提到的例子
   这个我是希望不同的时间，它能够给我返回不同的值

2、3 是的，我是希望 apollo 只负责配置规则，但是规则的解析由 client 来解析，这样可以实现超强的可扩展性

另外你提到的“还可以给子选项加上 priority, enabled, condition 选项，进行更细粒度的筛选排查”
我个人觉得，配置尽可能简单一些，目前像priority, enabled这种，应该是没有场景的。

这两个选项都是为非 default 值（子表）用的，主要还是为了运营、管理方便，比如多个子选项都合法，那么我就选那个优先级最高的。enable 主要是用来

default 值是存在主表里面的，就是现在的保存 config item 的表。其余的可选值都需要存在一个子表（需要新加）里面。

在我的想法里，配置管理系统提供的功能越多，那么使用它的应用程序需要做的开发量就越少。作为一个通用的，其实我是希望配置管理系统，提供更多的通用配置逻辑，这样，实现很多逻辑的时候，应用开发需要实现的代码量就更少，而且还可以实现热更新（配置管理系统支持）。