转载

为什么不用原生 Spring Cloud Config？

引言

近几年传统应用架构已经逐渐朝着微服务架构演进。那么随着业务的发展，微服务越来越庞大，此时服务配置的管理变得会复杂起来。为了方便服务配置文件统一管理，实时更新，配置中心应运而生。

其实，所谓配置中心，就是将配置的数据放在某种存储介质中，该介质可以是

File(例如Git、Svn)
Database(例如mysql、oracle)
nosql Database(例如Redis、Memacache、MongoDb)
其他第三方中间件(例如Zookeeper)

那么配置中心可以简单理解为是封装了对这些介质进行操作的接口，供客户端拉取使用。

由于我们采用的是Spring-Boot的架构，因此当时自然而然会考虑到Spring-Cloud中提供的配置中心 Spring-Cloud-Config ，但是当时做完调研以后，觉得并不能直接用。

因此，本文想来分享一下，原生 Spring-Cloud-Config

的配置中心的缺点，以及我们对

Spring-Cloud-Config

做了哪些改动。

正文

OK，我们当时做配置中心的选型的时候。第一选择是Spring-Cloud- Config。

Spring-Cloud-Config在存储介质的选择这块，基本上网上所有的文章都在推荐使用Git，即将配置文件放在Git中，服务端从Git中读取。其实官网上讲的最详细的配置，也是采取用Git作为存储介质。

因此，我相信大部分读者在生产上也是用Git作为存储介质，搭配Spring-Cloud-Config使用。

但是呢，博主认为以Git作为存储介质存在一些硬伤。

Git的权限控制是个坑

Git的权限管理是说控制用户能不能Push或者Delete分支，或者能不能Push代码，而不是能不能访问某个目录的文件。

对目录和文件的可读是Git的最基本要求，不可能做到针对目录级别的不可读。

因此如果直接使用，会出现这样一种情形

不同团队之间可以互看对方配置！

于是，可能会有如下情形发生

A团队同事A:"小B,这个地方不懂怎么配？"
A团队同事B:"去看看B团队的配置，直接贴过来。"
然后B团队就会发现自己的中间件里总是会多出一些莫名奇妙的数据！

当然，你可以禁止研发直接登陆Git改配置。然后呢，基于Git研发一套配置管理系统，在上面做权限控制，但是又有几个公司这么做呢？因为，这可能带来第二个问题。

粒度问题

将配置信息放在Git中，有一个致命问题: 粒度太粗了！

你每次对一条配置发生crud的操作，其带来的影响是整个文件发生变动。如果将来我们需要对某条配置做灰度发布，基于Git来做是比较麻烦的，注意了，我没说不能做，只是比较麻烦。

那么，当时我们最理想的存储介质就是数据库，将配置信息放在数据库里有 两个好处

基于数据库开发一套配置管理系统，显然比基于git来开发容易的多！
将配置放在数据库里，每条配置对应数据库的表中的一条记录。这么做粒度够细，针对某些重要的配置，做灰度发布，实现起来就容易很多。

因此，我们采用数据库作为存储介质。庆幸的是，这一点在Spring-Cloud-Config中是支持的。在该组件下，只需要设置

spring.profiles.active=jdbc

就能够激活jdbc模式。

但是我们很快发现了一个更大的问题，也正是因为这个问题，我们不得以需要进行改写Spring-Cloud-Config。

Spring-Cloud-Config的刷新机制是个坑！

因为一个配置中心应该要能够做到，配置发生改动的时候，项目能够自动感知，自动更新配置才对。在Spring-Cloud-Config中，这套机制是借助一些代码仓库（SVN、Github等）提供的Webhook机制加上Spring-Cloud-Bus来实现的。