怎么做配置下发

目录

 

配置下发

少量用户

大量用户

复杂场景

开拓思维

---

配置下发

我们做开发，无论是做中间件还是业务都会面临一个问题，我们的客户端或者APP发版本后，需要运行中动态加载一些配置，比如负载均衡、服务发现等，这些配置需要从服务端来获取，并且在配置变更后，客户端可以及时或非及时的得到最新的配置。

把问题抽象化，即我们客户端如何获取最新的配置，也就是配置下发的问题。

 

少量用户

最开始，配置下发可能会比较简单，无论是采用TCP长连接或者是HTTP短连接等等，我们客户端定时的与服务端进行通信，每次从服务端拉取最新的配置，客户端进行本地更新即可。

这是最基本也是最简单的模式，但是问题也很明显，如果配置文件较大，并且更新较少的时候，每次服务端发送给客户端的配置大部分都是无用流量。

我们可以在客户端请求配置文件时，携带文件的MD5，服务端在只有MD5不相同时，即文件发生变化时，再把配置文件下发给客户端；没有变化时，只需要告知客户端无变化状态即可。

这样，我们就节省了大量无效的流量。

 

大量用户

我们的客户端规模越来越大，当有一天已经到了十万、百万级的时候，我们再看这种方案是否还可行。

虽然，在配置没有变化时，我们服务端返回的ack信息都是一个简单的状态，但是当配置文件发生变化时，如果配置文件很大，很快网络带宽资源就会成为瓶颈。

如果可以知道配置都有哪些发生变化，每次只返回给客户端发生变化的配置，这就极大程度上节约了网络带宽资源。

现在的问题点就在于如何知道哪些配置发生了变化。

最容易想到的，就是服务端在配置文件发生变化时，记录下变化的配置，在客户端拉取配置时，只需要返回变化的配置文件即可。

并且正常情况下，客户端都会在很短的时间内获取最新的配置，如果有异常客户端，在一段时间内还没有更新到最新的配置，我们可以对这少部分的异常客户端进行全配置更新。

如此，我们只需要在服务端为配置文件标记一个顺序递增的版本号，在有配置发生变化时，记录发生变化的配置，并对版本号加一。

• 当客户端来请求配置文件时，携带本地配置文件的版本号，当版本号相同时，说明无变化，依旧返回无变化状态即可；
• 当客户端配置文件版本号比服务端小1时，服务端才返回变化的内容；
• 其余情况都认为客户端更新配置异常，返回全量数据即可。
• 客户端收到配置后更新本地版本号。

 

复杂场景

以上，我们基于一般正常的情况来设计的方案，如果客户端场景很复杂，经常有长时间不启动或者不联网的客户端，他的配置文件就会落后很多版本。或者如果配置文件更新比较频繁，频繁程度超过了客户端请求配置的间隔。

那么我们上面的方案又退化回了服务端每次返回全量配置了。既然我们无法相信不确定的客户端，我们就需要在服务端来做一些手脚了。

我们记录每次配置的变化，在客户端来请求配置时，根据两者版本号的差异，获取之间配置文件的所有变化，汇总后发送给客户端，那么就解决了这个问题。

当每次配置发生变化时，服务端依旧记录变化的配置，并对版本号加一。并且将版本号与配置文件变化映射成一组关系保存起来，在内存或者保存到文件、数据库、redis都可以。当客户端来请求配置文件时，依旧携带本地版本号，利用本地版本号与服务端最新的版本号做比对。

• 版本号相同时，说明配置未发生变化，返回无变化状态。
• 当客户端版本号大于服务端版本号时，说明客户端配置异常，返回全量数据。
• 当客户端版本号小于服务端版本号时，根据两者的版本号差异，获取之间的所有变化，汇总后返回给客户端。
• 客户端收到数据后更新本地版本号。

当然，我们同样可以设置一个阈值，即服务端只会保存最近的M个版本的配置变化，用来防止服务端保存数据无限膨胀。并且变化较多时，汇总的差异可能已经与全量数据几乎相同。

当客户端与服务端的版本差异大于M时，依旧返回全量数据即可。

 

开拓思维

我们联想一下，服务端的这种配置管理与GIT的版本管理非常相似，所以有时候我们最怕的不是技术不够，而是思维不够开阔。

那么我们再进一步开拓一下思维，这种记录配置文件变化，是不是又与Redis的AOF很相似。如果，我们可以设计一种统一的记录配置变化的元语，那么我们是不是也可以实现Redis中AOF的的重写？

如果我们可以实现AOF的重写，是不是就省去了大量的合并版本差异的重复操作。

那么我们可以对配置进行k\v化，应该说所有的配置都可以拆分为一系列的k\v组合。我们再定义一组操作元语，就用我们经常自嘲的CRUD来定义，我们取其中的CUD：

C：新增

U：更新

D：删除

这三种操作就几乎囊括了配置的所有变化。那么我们的配置变化就可以记录为：

C：K：V

U：K：OLD：NEW

D：K

那么我们服务端，就可以定期的对配置变化进行重写合并。例如：

• 对同一个K的U操作，可以只保留最后一次
• 对同一个K的D操作前的所有CUD，可以只保留最后的D操作
• 对同一个K的先C后U操作，可以合并为C操作，V为最后一次U的NEW值

等等，这里只是举个简单的例子。这样，一方面减少了服务端对配置变化的存储数量，一方面也减少了每次客户端请求配置时，服务端大量的重复合并差异的冗余操作。

是不是还能再继续扩展下思维？我想应该是可以的，而我就暂时说到这里。

比如我们返回给客户端的不一定是变化的配置，也可以是这些操作的元语，是不是又可以减少一部分的数据包大小。

生硬的结束~困了

个人原创公众号，期待关注：