你好好想想，你真的需要配置中心吗？

从分析业界通用方案，到匹配自己的业务场景，最后再到亲自动手造个轮子。 而且这个轮子，我去看了代码，代码很简洁，几百行代码就实现了一个配置中心的最核心部分的逻辑。

分享给你，给你提供一个看待“配置中心”的新角度。

原文链接：https://code2life.top

配置中心会有多复杂？

配置中心是微服务系统必不可少的组件之一，乍一看好像没多少技术含量，可是，真的是这样吗？

以Java Spring技术栈为例，主流的配置中心有阿里的Nacos、携程的Apollo、以及Spring Cloud Config Server。我们拆解一下其中共通的技术点：

服务端：

• 认证和权限控制：某个服务可以拿到哪些Key？人员的增删改查权限如何控制？

• 存储层的选型：文件系统，Git仓库，数据库？

• 安全性：传输加TLS，密钥需要落盘加密，本身用来加密密钥的密钥如何安全存储？

• 高可用、数据一致性：多实例部署，甚至跨区域同步，进而又带来分布式存储一致性问题，如何解决？

• 版本控制：修改记录需要保留，随时可能回退到历史版本，另外，灰度版本的配置隔离如何实现？

• ......

客户端：

• SDK如何兼容不同的技术栈？

• 大量客户端同时启动，如何做并发控制？同时还要尽可能减少额外的请求，对服务启动时间的负面影响？

• 如何实现与本地配置的优先级控制、合并、缓存、变化实时感知？

• ......

看到这里，或许你不会觉得配置中心只是简单的KV存储了。主流的型如Alibaba Nacos，作为一个完善的配置和服务发现组件，已经解决了上述大部分问题。我也曾用Nacos，Nacos非常棒，不过我也逐渐发现了一些局限性：

• 当你有数十个环境，每个环境有数百个配置的时候，基于图形界面的版本管理会力不从心；

• Nacos服务的网络、Server、数据库，任何一层出问题，都可能影响大量产线服务；

• 额外的学习、使用、部署、维护成本，服务启动的额外性能开销；

• 发生过一次产线事故，后来分析是因为Spring Cloud Nacos在刷新配置的时候，可能导致Bean Refresh死锁；

• 不支持新版本的SpringBoot/SpringCloud，在SpringBoot 2.3.0.M1之后直接报错（这个问题存在很久了，我在Github提了一个Pull Request修复该问题，多日没有收到答复 https://github.com/nacos-group/nacos-spring-boot-project/pull/189）

挥下奥卡姆剃刀吧，或许你不需要如此复杂的方案！

一行代码实现动态配置

我萌生了一个朴素的想法：

既然配置原本就是单纯的文件，那么文件变化时，重新加载对应的Spring Bean不就行了吗？

于是，我开发了一个Spring Boot的配置热重载库，已发布到Maven中心仓库，Github开源仓库地址：

https://github.com/Code2Life/spring-boot-dynamic-config。

话不多说，先看效果。