服务配置和热更新
程序配置服务和热更新 前言 在开发过程中，因为不同环境中有不同的配置，所以往往一个项目要同时保存着不同环境的配置文件（dev，test，staging，prd）等。如果没有一个方便简洁的管理这些配置文件方式，排查问题也会变的麻烦。接下来介绍几种我所经历的几种配置文件管理方案 git 分支管理 顾名思义就是利用 git 的分支来管理不同环境的配置，比如dev分支就是对应存放这dev的配置文件。 优点 分支管理更符合开发的代码习惯，只关心本分支的代码和配置 缺点 不符合git-flow流程，如果test配置有改动，那么就要直接编辑test分支代码，而不是从dev分支合并过去。排查配置相关问题不友善 一份配置文件就一个分支，维护代价太大，有些舍本琢末了。 热更新方案无 所有配置文件都放在项目下 这种方式就是把所有的配置文件集中放在项目下的某个目录，用环境变量的方式去加载指定的配置文件 1 2 3 4 5 6 7 8 9 10 11 12 13 14 package main func main(){ switch env{ case:"dev": load("dev.config") case:"test": load("test.config") ... default: load("local.config") } } 优点 配置统一集中管理，修改方便 缺点 配置文件过多容易使项目结构变的“难看”，判断依赖过多，不优雅。 无法做到热更新，配置更改需要重新发布代码 热更新方案无 配置中心 将配置文件都放到三方的服务中保管，比如nacos、Apollo等配置中心 nacos：https://nacos.io/zh-cn/docs/what-is-nacos.html Apollo：https://www.apolloconfig.com/#/zh/README 优点 集中化管理配置，配置文件“不落地” 有相关 sdk 调用，支持热更新等高级功能 缺点 要维护一个高可用的 三方服务 增加了维护成本 热更新方案 需要另外编码去开发 ...