配置文件相关笔记

配置文件位置

这里主要讲的是，配置文件不要跟源码放在一个目录。比如我新建了一个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里读取。

服务支持获取最新配置

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

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