如何做好一个配置中心

我们知道，在程序中不应该把代码或流程写死，而应该把一些流程提取成开关、变量等。这样，就可以在不改变代码的情况下，在程序运行时执行不同的功能。这些开关、变量的集合一般放在一个或者多个文件里，称之为配置文件。一般来说，大部分程序都会存在这个文件，既然有文件，就需要管理。尤其是现在微服务化的趋势下，服务拆分，服务数量变多，配置文件的数量也跟着增加，就需要一个中心化的服务来管控这些配置文件，我们称之为配置中心，它一般会提供以下能力：

• 配置的集中化管理，统一标准。
• 配置的安全存储，不丢失。
• 下发配置到服务，并支持自动更新。
• 敏感配置的加密，权限管控。
• 高可用，配置中心作为系统的关键节点，必须保证可用性。
• 接入成本低，一般来说，刚开始以业务为主，对配置文件的管理需求没那么着急，等业务稳定才会考虑建立配置中心。那么，如何快速接入，快速切换，就很重要了。

那么，如何才能做好一个配置中心？下面列出几种可行的方案，并对比了其中的区别和优缺点。

Git 配置中心

配置信息存到 Git，比如：Spring 的 ConfigServer。这种方式利用了 Git 的存储特性和保存历史提交的特性，开发量小，接入简单，架构图如下：

在写入端，管理员通过 git push推送配置到仓库，并且能通过 git 提供的历史提交、权限管理等功能，对配置进行集中化管理，企业的 git 仓库一般也都会备份，所以数据不容易丢失。

在获取端，git 的弊端就比较明显了，你不能直接在程序中访问 git 获取配置，只能用个服务做中转，它根据程序的元信息去 git 仓库取配置，也不支持自动更新（虽然可以利用 git webhook，但是中转服务如何通知到程序，还是个问题。）而且加密解密也只能做到中转服