成志明最近在忙什么？听说他又有新的项目了！

最近真是忙得脚不沾地，不过做自己喜欢的事情，累也值了！

不少老朋友私信问我最近是不是又“神隐”了，好久没更新博客或者发点实践记录。哈哈，我没跑，就是最近一头扎进了新项目里，根本没时间抬头看一眼。

这回的实践内容，简单来说，就是整合一套轻量级的分布式配置中心。之前我们公司那套配置管理系统，虽然能用，但是实在是太臃肿了，部署麻烦，维护也费劲，每次更新配置都跟做大手术一样，特别是小团队或者新项目，根本用不起来。

起步：从“痛点”挖掘需求

我这人做项目，都是从解决实际问题开始的。我们目前的痛点主要集中在几个地方：

配置分散，各种应用各自为政，查找起来费劲。
修改配置后需要手动重启服务，影响业务连续性。
权限控制混乱，谁都能改，一不小心就出岔子。

我一开始的目标就很明确：要一个能实时推送、部署简单、权限清晰、而且资源占用小的配置中心。

技术选型与摸索

一开始我考虑过直接用成熟的方案，像Apollo、Nacos这些。但是正如我前面说的，它们对我们这种小而美的项目来说，太重了。光是部署依赖和上手成本，就够喝一壶的。

我决定自己动手，丰衣足食。

我选择了Go语言来写核心服务，主要看中它的并发性能和部署的便捷性。数据库方面，因为配置数据量不会特别大，而且需要高可用性，所以我选择了PostgreSQL，主要是对事务和数据一致性比较放心。核心的实时推送机制，我决定用WebSockets来实现，因为它简单高效，能满足实时性要求。

架构设计：化繁为简

整个架构被我拆分成了三个主要部分：

管理界面（Frontend）： 用Vue写的，负责配置的CRUD操作，以及权限管理。
配置服务（Backend）： Go语言编写，核心逻辑都在这里，负责配置存储、版本管理和WebSocket连接维护。
客户端SDK： 主要是提供给应用调用的库，轻量到只有一个文件，负责和服务端建立连接，获取配置，并在配置变更时接收推送。

光是配置服务这一块，我就折腾了好久。最大的难点在于如何保证推送的原子性和一致性。 想象一下，上千个服务同时订阅一个配置项，我更新配置后，必须在极短的时间内通知到每一个订阅者，并且确保他们收到的都是最新版本，不能出现有的服务拿到旧配置，有的拿到新配置的情况。

我的解决办法是：在配置服务内部，维护一个内存缓存，每次配置更新时，先更新数据库，再清空缓存，然后通过一个专门的调度器批量向所有活跃的WebSocket连接推送“配置更新”的指令，客户端收到指令后，再通过HTTP拉取最新配置。这样既减轻了推送端的压力，也保证了客户端最终配置的一致性。

编码与测试：从零到一

编码阶段就是不断地填坑。Go的goroutine用起来很爽，但稍微不注意，内存泄漏或者死锁就找上门来了。特别是WebSocket连接的管理，我用了一个来维护所有连接，确保并发安全。

测试阶段是最熬人的。我模拟了多环境部署，搞了上百个应用实例去同时连接配置中心，进行了压力测试和混沌测试。一开始发现，在高并发推送时，有大概0.5%的概率会出现连接断开却没有重连的情况。我仔细排查了Go的WebSocket库和我的重连逻辑，最终发现是客户端的指数退避重试策略做得不够健壮，稍微调整了下参数，稳定性立马就上来了。