配置文件相關筆記

配置文件位置

這裏主要講的是，配置文件不要跟源碼放在一個目錄。好比我新建了一個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裏讀取。

服務支持獲取最新配置

若是你的配置文件常常修改，而且每次服務都須要用到最新配置，那麼可能須要服務在代碼層面支持檢測配置文件是否被更新，更新了則使用最新配置。

若是你用服務線程按期去檢測配置文件，而後更新本身內存裏的值，這也能夠，首先生產環境須要支持配置自動部署更新，好比我經過集羣裏一個節點推送到其餘節點，實現所有更新。或者使用一些開源服務，由該基礎配置服務提供統一接口，其餘服務經過該接口讀取配置，這樣實現起來可能會更簡單。總之，各取所需。