配置中心存放文件还是 Key-Value键值对？

容器的配置文件存放在配置中心（consul）时，会有几种不同的存放方法。最典型的就是将文件直接存放在 配置中心，容器启动时，到配置中心下载后，即可使用。 也可以将配置提取成 键值对，配合渲染程序将模板渲染成 目标配置文件。

文件模式 (FILE)

文件模式是将一整个文件，存放在consul的一个key中。

文件模式的优点

1. 简单：容易得到用户的理解，方便推广。
2. 灵活：可以在consul页面上，直接编辑配置文件本身，那么就可以为参数编写注释， 也可以禁用某个参数。

文件模式的缺点

1. 对比 staging 和 生产环境配置文件的差异，难度很高，这增加了运维难度。
2. 保持 staging 和 生产配置的一致性，完全依赖人工，这增加了生产环境由于配置不一致而出错的风险。
3. 运维人员需要知道所有配置文件的路径，配置方法，对运维要求较高，并增加了运维出错的风险。(通常一个git项目平均有2个配置文件， 一个产品有20个git项目，一个运维需要维护10个左右的项目，运维需要记得大概400个不同的配置文件, 经验丰富的运维可能需要记住1000 个左右的配置文件)

键值对模式 (KV)

键值对模式是将配置文件中的参数提取成多个键值对，存在在consul中。 这就依赖于文件模板和渲染程序。

• 文件模板： 采用jinja2 格式，这是一种可编程模板引擎。
• 渲染程序： 根据规则渲染所有模板文件到目标路径下。

键值对模式的优点：

1. 非常容易对比 staging和生产环境的差异。
2. 可以保证staging和生产环境配置文件的一致性。
3. 配置文件格式与最终配置文件解耦。 运维无需关注配置文件格式和路径。
4. 可以在模板中编程，以便同一份模板适应多种不同的环境。
5. 可以迅速将任意配置文件参数化。（系统默认配置文件，很可能我们只想该其中一个参数，那么我们可以将其参数化）
6. 模板维护在源代码中， 配置维护在consul中，实现了配置定义和配置工作的分离，同时分离，并明确了开发和运维的职责。

除了以上运维优点之外， 键值对模式，有如下几个增强的优点

1. 支持继承。
2. 支持注入默认的全局变量。

键值对模式的缺点：

1. 编写模板文件需要投入人力成本。配置文件越大，需要时间越多。
2. 所有的配置文件的 键（key） 都平铺在同一个空间下，因此
   • 配置文件很多时，编辑不方便
   • 多个不同的容器使用参数时， 不能使用同名参数
   • 没有命名空间的分隔，不清楚参数作用在哪个容器中。
3. 没有办法编写注释
4. 没有办法 禁用一个key，同时保留这个key （你可以删除一个key来禁用）

平台的倾向性

用户在了解 多种模式之间的优缺点之后， 结合自己的业务形态和运维人员的现状，会有自己合理的选择。 作为技术方案提供方，我们为用户提供更简单和更规范的使用方法，但平台本身不代替用户做出决策，也不特定倾向于支持某一种特定方案。

我们需要的功能

1. kv 的版本历史功能
2. 版本历史中记录了由哪个用户做了此次修改，修改时间是多少
3. 基于历史的回滚功能
4. key 的 disable/enable 功能
5. key 的 注释功能