我的生活经验使我深信，没有缺点的人往往优点也很少。
- 林肯
错综复杂的配置参数
通常习惯把程序的配置参数独立到一个 setting 的文件。在个人项目及小规模项目中，足矣。
但是接入了正规的研发流程之后，单单一个 setting 文件已经不能够解决问题。
本地开发环境 -> 联调环境 -> 提测环境 -> 预发布环境 -> 生产环境
当每个环境都有独立的数据库，依赖 web 接口时，配置文件就复杂了。
如果继续使用单个 setting 文件
配置文件就变得异常恶心
if env == "dev":
db = "1.1.1.2"
...
elif env == "dev_test":
db = "1.1.1.3"
...
elif env == "test":
db = "1.1.1.4"
...
elif env == "staging":
db = "1.1.1.5"
...
elif env == "production":
db = "1.1.1.6"
...
采用配置文件按环境分离的方式
setting # 配置文件 - 存储通用的配置
settings # 配置目录 - 存储环境独立的配置
|- dev # 本地开发环境配置
|- dev_test # 开发人员用于联调的环境配置
|- test # 测试人员用于专门测试的环境配置
|- staging # 预发布环境的配置
|_ production # 生产环境配置
使用环境变量存储生产环境的多机集群配置，及互备配置
如果生产环境是多机集群，且多机互备呢? 这是上面方案所不能解决的问题。
例如，生产环境中，A、B、C、D 四台机器中的 A、B 互备，C、D 互备。 那么总不能专门为这四台机器再增加四个独立的配置文件吧，如果以后扩容到 100 台机器呢？
一种简单有效的方式就是把机器独立的配置写到环境变量中。
只对当前 shell 启动的进程生效的话，只需要
export MY_VAR=1
永久保存环境变量, 需要将 export 配置保存到配置文件中
- ~/.profile 适用于终端及 GUI 进程
- ~/.bashrc, ~/.bash_profile, ~/.bash_login 适用于终端
使用环境变量可能遇到的坑
- 如果有其他人的服务，或者自己另一个正在运行的服务，读取了与当前服务相同的环境变量，那么除非他也重启服务以更新环境变量，否则会一直使用旧的环境变量
- 如果要 sudo -u otheruser 来执行一个服务时，需要加上 -E 参数才能读到已配置的环境变量，参考: How do sudo environment variables work in linux?
成百上千台机器呢?
虽然至今还没接触过这么大的业务规模，但是设想一下手动更新部署一台机器的配置有多么繁琐就知道, 一定是需要一个配置管理中心的服务。
使用数据库管理所有机器的配置信息，配置变更及扩容都可实现自动化。
微信关注我哦 👍
我是来自山东烟台的一名开发者，有感兴趣的话题，或者软件开发需求，欢迎加微信 zhongwei 聊聊， 查看更多联系方式