教你如何利用分布式的思想处理集群的参数配置信息——spring的configurer妙用

时间：2022-03-21 06:17

引言

　　最近LZ的技术博文数量直线下降，实在是非常抱歉，之前LZ曾信誓旦旦的说一定要把《深入理解计算机系统》写完，现在看来，LZ似乎是在打自己脸了。尽管LZ内心一直没放弃，但从现状来看，需要等LZ的PM做的比较稳定，时间慢慢空闲出来的时候才有机会看了。短时间内，还是要以解决实际问题为主，而不是增加自己其它方面的实力。

　　因此，本着解决实际问题的目的，LZ就研究出一种解决当下问题的方案，可能文章的标题看起来挺牛B的，其实LZ就是简单的利用了一下分布式的思想，以及spring框架的特性，解决了当下的参数配置问题。

问题的来源

　　首先来说说LZ碰到的问题，其实这个问题并不大，但却会让你十分厌烦。相信在座的不少猿友都经历过这样的事情，好不容易将项目上线了，却出现了问题，最后找来找去却发现，原来是某一个参数写错了。比如数据库的密码，平时开发的时候用的是123456，结果线上的是NIMEIDE，再比如某webservice的地址，平时开发测试使用的是测试地址，结果上线的时候忘记改成线上地址了。当然了，像数据库密码写错这样的错误还是比较少见的，但诸如此类的问题一定不少。

　　出现这个问题的原因主要就是因为开发环境、测试环境以及线上环境的参数配置往往是不同的，比较正规一点的公司一般都有这三个环境。每次LZ去做系统上线时，都要仔细的检查一遍各个参数，一不小心搞错了，还要接受运维人员的鄙视，而且这种鄙视LZ还无法反驳，因为这确实是LZ的失误。还有一个问题就是，在集群环境下，现在的方式需要维护多个配置信息，一不小心就可能造成集群节点的行为不一致。

　　总的来说，常见的系统参数往往都难免有以下几类，比如数据库的配置信息、webservice的地址、密钥的盐值、消息队列序列名、消息服务器配置信息、缓存服务器配置信息等等。

　　对于这种问题一般有以下几种解决方式。

　　1、最低级的一种，人工检查方式，在上线之后，一个一个的去修改参数配置，直到没有问题为止。这是LZ在第一家小公司的时候采取的方式，因为当时没有专门的测试，都是开发自己调试一下没问题就上线了，所以上线以后的东西都要自己人工检查。

　　2、通过构建工具，比如ant&ivy，设置相应规则，在构建时把参数信息替换掉，比如某webservice接口的地址在测试环境是http://10.100.11.11/service，在线上环境则是http://www.cnblogs.com/service。

　　3、将配置信息全部存到数据库当中，这样的话只替换数据库信息即可。（这也是LZ今天要着重介绍的方式，已经在项目中使用）

　　4、将配置信息存放在某个公用应用当中，不过这就需要这个应用可以长期稳定的运行。（这是LZ曾经YY过的方式，最终还是觉得不可取，没有实践过）

　　5、等等一系列LZ还未知的更好的方式。

　　纵观以上几种方式，LZ个人觉得最好的方式就是第三种，也就是通过数据库获取的方式。这种方式其实用到了一点分布式的思想，就是配置信息不再是存放在本地，而是通过网络获取，就像缓存一样，存放在本地的则是一般的缓存方式，而分布式缓存，则是通过网络来获取缓存数据。对于数据库存放的数据来说，本身也是通过网络获取的，因为现在大多数的情况下，已经将应用与数据库从物理部署上分离。况且由于LZ的项目使用了集群，这样的方式也可以将配置信息统一管理，而不是每个集群节点都有一份配置信息。

　　通过这种思想，LZ想到的还有第四种方式，这与第三种方式十分相似，但是第四种需要另外搭建专门的应用，实际操作起来可行性较差，而且稳定性也不太容易保证，因此LZ最终还是把这种方式给pass掉了。

　　第二种方式是公司之前一直采用的方式，但是坏处就是每当要增加一个配置参数，就要通知配置管理的人员将规则修改，而配置管理的人员往往都比较忙，有的时候新参数已经上线了，规则还没做好。这样的话，一旦发布，如果LZ稍有遗忘，就可能造成启动失败。实际上，要说启动失败，其实还算是好的，还能及时纠正，最怕的是启动成功，但真正运行时系统的行为会产生异常，比如把线上的消息给发到测试服务器上去了。那个时候就不是运维人员的鄙视这么简单了，可能就是领导的“关爱”了。尽管到目前为止，LZ好像也没有因为这事受到过领导的“关爱”，但是每次上线都要仔细的检查一遍参数配置，实在是费眼又费神，痛苦不堪。

　　说到第二种方式，还有一种弊端，就是就算规则能够被及时更新，LZ还是得一次一次的检查配置信息。因为替换错了的话，责任还是在LZ，最关键的是，由于现在项目是集群，一检查就得四台服务器。不过四台倒还勉强能忍，如果以后搞个十台二十台的，LZ岂不是要累死？

　　因此总的来说，使用第三种方式已经势在必行。在本段的最后，总结一下第三种方式的好处。

　　1、由于配置信息存放在数据库当中，而本身开发库、测试库和线上的生产库就是分离的，因此只要保证数据库的配置信息没错，就可以保证其它的配置信息都可以正确获取。

　　2、对于已经做了集群的项目来说，可以保证配置信息只有一份。

　　总的说来，这种方式，与集群下的缓存解决方案有着异曲同工之妙，都是通过网络来实现统一管理。