一个内部简单系统-持久配置中心的经验

 

 

    公司内部有一个配置中心，采用推送的方式来推送配置到客户端，对于Runtime的数据和持久的数据，都采用同样的方式处理。整个系统是一个集群。持久的数据也都是存在每个节点上，节点之间的数据会复制。

    我总觉得，持久的数据的特性和非持久(Runtime)的会有所不同，一般Runtime的数据的特点是需要非常快的更新到客户端，让客户端感知到数据的变化。而持久的数据，需要的是客户端启动时的可靠获取，以及配置数据持久保存的安全性等。

    后来主导，起了一个新的产品，专门用于管理持久配置数据的，提供了Get的高可用性，采用数据库并且主备的方式，保证数据本身的安全。

    产品出来后，发现了几个问题，

        第一个，内部有了两个配置中心，一个是管理持久数据的，一个是Runtime数据的，但是，对于内部的开发人员来说，复杂了

第二个，原来都是使用一个客户端，现在迁移的时候，有一定的迁移成本，而不是完全透明的

第三个，对于运维的同事和线下的配置管理员来说，多了一套系统

第四个，其实之前没有仔细分析清楚，就是对于持久的配置数据，一般是不会改动的，但是真的改动的时候，也是需要能够立即通知到客户端的。而这个地方，确实新的持久配置中心没有解决好的。

    在开始这个产品之前，觉得是尽量把持久的配置中心做到很简单，做到可以应对意外情况（比如意外的时候，可以读取本地配置；配置是文本的，可以方便的人工介入），可以，还是有不少的地方没有想清楚。这个真是教训啊。

    对于一个看似简单的产品，

         1 还是需要想清楚真实的使用场景

2 考虑对现有的影响，包括但不限于使用这个产品的人；运维人员；配管人员；测试人员等等。

3 类似概念的产品，最好只有一个。对于Runtime的配置，持久的配置，其实都是配置，虽然特性上可能会有很大的差别，但是对于使用者，还是隐藏一些使用上的细节比较好。