容器的配置文件存放在配置中心（consul）时，会有几种不同的存放方法。最典型的就是将文件直接存放在 配置中心，容器启动时，到配置中心下载后，即可使用。 也可以将配置提取成 键值对，配合渲染程序将模板渲染成 目标配置文件。
文件模式 (FILE)
文件模式是将一整个文件，存放在consul的一个key中。
文件模式的优点
- 简单：容易得到用户的理解，方便推广。
- 灵活：可以在consul页面上，直接编辑配置文件本身，那么就可以为参数编写注释， 也可以禁用某个参数。
文件模式的缺点
- 对比 staging 和 生产环境配置文件的差异，难度很高，这增加了运维难度。
- 保持 staging 和 生产配置的一致性，完全依赖人工，这增加了生产环境由于配置不一致而出错的风险。
- 运维人员需要知道所有配置文件的路径，配置方法，对运维要求较高，并增加了运维出错的风险。(通常一个git项目平均有2个配置文件， 一个产品有20个git项目，一个运维需要维护10个左右的项目，运维需要记得大概400个不同的配置文件, 经验丰富的运维可能需要记住1000 个左右的配置文件)
键值对模式 (KV)
键值对模式是将配置文件中的参数提取成多个键值对，存在在consul中。 这就依赖于文件模板和渲染程序。
- 文件模板： 采用jinja2 格式，这是一种可编程模板引擎。
- 渲染程序： 根据规则渲染所有模板文件到目标路径下。
键值对模式的优点：
- 非常容易对比 staging和生产环境的差异。
- 可以保证staging和生产环境配置文件的一致性。
- 配置文件格式与最终配置文件解耦。 运维无需关注配置文件格式和路径。
- 可以在模板中编程，以便同一份模板适应多种不同的环境。
- 可以迅速将任意配置文件参数化。（系统默认配置文件，很可能我们只想该其中一个参数，那么我们可以将其参数化）
- 模板维护在源代码中， 配置维护在consul中，实现了配置定义和配置工作的分离，同时分离，并明确了开发和运维的职责。
除了以上运维优点之外， 键值对模式，有如下几个增强的优点
- 支持继承。
- 支持注入默认的全局变量。
键值对模式的缺点：
- 编写模板文件需要投入人力成本。配置文件越大，需要时间越多。
- 所有的配置文件的 键（key） 都平铺在同一个空间下，因此
- 配置文件很多时，编辑不方便
- 多个不同的容器使用参数时， 不能使用同名参数
- 没有命名空间的分隔，不清楚参数作用在哪个容器中。
- 没有办法编写注释
- 没有办法 禁用一个key，同时保留这个key （你可以删除一个key来禁用）
平台的倾向性
用户在了解 多种模式之间的优缺点之后， 结合自己的业务形态和运维人员的现状，会有自己合理的选择。 作为技术方案提供方，我们为用户提供更简单和更规范的使用方法，但平台本身不代替用户做出决策，也不特定倾向于支持某一种特定方案。
我们需要的功能
- kv 的版本历史功能
- 版本历史中记录了由哪个用户做了此次修改，修改时间是多少
- 基于历史的回滚功能
- key 的 disable/enable 功能
- key 的 注释功能
