今天被一位同事的问题惊到了。是关于中大型系统的各个终端配置文件的问题，系统使用oracle数据库保存参数配置，然后系统发布到各个节点，各个节点生成xml配置文件覆盖旧文件，节点软件需要重拉进程读取新的配置文件。他的问题就来了，为什么软件不直接连数据库，不就可以实时修改生效了吗？
配置文件的作用是什么？ 将一些可能变动的参数放到配置文件中，可以使得程序更加灵活，更有甚者将一些业务逻辑操作从代码中挪到配置文件中，根据条件选择来决定软件运行方向。笔者在日常的开发过程中，将数据库连接字符串，日志路径、设备接口、地址信息、功能特性开关、上下限数值、格式信息等线上环境相关的易变值加入配置文件，正确而高效地使用软件，扩展性较好。
作为在windows写过几个应用程序的小白来说，第一感觉就是这可能不是个正常的工程师问的问题，或这个问题可能一点都没有经过脑子。写过软件的都知道，数据IO的成本是很高的，配置文件里面的参数不需要经常变动的，那么软件在第一次加载后直接内存里面循环使用不是更加高效吗！软件一旦拉起，除了软件本身的问题外，难道还要考虑数据库的宕机问题，不然全系统软件就DOWN了。那么节点多了，数据库是不是要调优呢。那么数据库只用来作为系统配置保存和配置文件统一修改平台不是更好吗。
当然，节点有些开关状态和共享变量可能需要实时连接到数据库，然后其他节点再读取。但是数据库如果只是作为配置文件存储、修改和发布平台的的话，那么这样设计是不是合适呢？那么本是离线数据库就需要应对在线负荷的要求，各个节点都要来和数据库同步，瓶颈就来了，我修改参数就要战战兢兢。要是同步不到呢，那么软件不就down了，当然你可以在设计程序时考虑到这一点，做个条件选择。是不是麻烦了点呢？
节点有些开关状态和共享变量怎么完成节点共享呢。中大型系统得一个监控控制节点吧，可以将节点的开关状态和共享变量发给监控控制节点，再有监控控制节点分发读取的信息。监控控制节点宕机了怎么办，下面的节点还是按照原来的开关状态和共享变量在运行，不影响整个系统。
这就设计到一个问题，配置参数主动连接索取和被动分发获取。
主动连接索取，是节点自己通过IP或者VIP连接到服务器或者其他节点完成数据读取，然后应用。这样架构是一大推，互联网上基本都是这样的应用吧。
被动分发获取，是服务器或者其他节点主动对外广播或者组播信息，节点接收然后应用。这个适用于局域网高可用架构，消除某个节点的单点瓶颈，保证节点持续可靠运行。可维护性方面，配置参数是离线的，危险程度也低。但是，目前笔者只在局域网看到过这样的架构，系统的稳健性比较好。
网友评论