配置文件相关笔记

配置文件位置

这里主要讲的是，配置文件不要跟源码放在一个目录。好比我新建了一个django project，而后用了里面的settings来做为我代码的配置。你项目目录多是这样的

mysite/
├── apps
│   ├── account
│   │   ├── control.py
│   │   ├── __init__.py
│   │   ├── urls.py
│   │   └── views.py
├── settings.py

这里settings.py跟源码放在同一个目录。这样会很出这个问题，若是你每次更新线上环境的时候，都是把源码打成一个包（例如deb包)，而后安装的时候，替换这个目录。这样你每次线上的配置都会给你覆盖掉。
例如我线上配置了每次登录系统的用户是50，你这个新包里的配置是一个默认值，那这样就不一致了。

因此，代码仍是代码，配置仍是配置，不要混在一块儿，虽然很简单，可是颇有必要考虑。

这里应该在project源码外面新建一个目录conf，来存放配置文件。

project/
├── conf
│   └── settings.py
├── mysite
│   └── apps
│       └── account
│           ├── control.py
│           ├── __init__.py
│           ├── urls.py
│           └── views.py

这样每次每次更新都不会覆盖配置文件，而且原来的配置文件能够做为配置模板，不负责配置实例。

配置本地化

对于前面的问题，你不打算新建一个目录存放配置的话，或许能够经过支持配置本地化来解决，也就是支持服务有本身的配置，不会由于配置文件更新而被覆盖，好比你在代码层面支持local_settings.py每次读取配置的时候，会先从local_settings.py里读取，而后再从settings.py里读取。

服务支持获取最新配置

若是你的配置文件常常修改，而且每次服务都须要用到最新配置，那么可能须要服务在代码层面支持检测配置文件是否被更新，更新了则使用最新配置。

若是你用服务线程按期去检测配置文件，而后更新本身内存里的值，这也能够，首先生产环境须要支持配置自动部署更新，好比我经过集群里一个节点推送到其余节点，实现所有更新。或者使用一些开源服务，由该基础配置服务提供统一接口，其余服务经过该接口读取配置，这样实现起来可能会更简单。总之，各取所需。