隨著程序功能的日益復雜，程序的配置日益增多：各種功能的開關、降級開關，灰度開關，參數的配置、服務器的地址、數據庫配置等等，除此之外，對后臺程序配置的要求也越來越高：配置修改后實時生效，灰度發布，分環境、分用戶，分集群管理配置，完善的權限、審核機制等等，在這樣的大環境下，傳統的通過配置文件、數據庫等方式已經越來越無法滿足開發人員對配置管理的需求，業界有如下兩種方案： * 基于 zk 和 etcd，支持界面和 api ，用數據庫來保存版本歷史，預案，走審核流程，最后下發到 zk 或 etcd 這種有推送能力的存儲里（服務注冊本身也是用 zk 或 etcd，選型就一塊了）。客戶端都直接和 zk 或 etcd 打交道。至于灰度發布，各家不同，有一種實現是同時發布一個需要灰度的 IP 列表，客戶端監聽到配置節點變化時，對比一下自己是否屬于該列表。PHP 這種無狀態的語言和其他 zk/etcd 不支持的語言，只好自己在客戶端的機器上起一個 Agent 來監聽變化，再寫到配置文件或共享內存，如 360 的 Qconf。 * 基于運維自動化的配置文件的推送，審核流程，配置數據管理和方案一類似，下發時生成配置文件，基于運維自動化工具如Puppet，Ansible 推送到每個客戶端，而應用則定時重新讀取這個外部的配置文件，灰度發布在下發配置時指定IP列表。 創業公司前期不需要這種復雜，直接上 zk，弄一個界面管理 zk 的內容，記錄一下所有人的操作日志，程序直連 zk，或者或者用Qconf 等基于 zk 優化后的方案。