商业软件的开发,大部分都需要有一些为其它模块提供服务的底层模块。这些底层模块由于实现的是一些通用功能,需要同时为几个高层模块提供功能,因此通常被设计成一种基于消息队列的框架。任何需要访问这些通用功能的高层模块,都可以通过发送消息并接受返回值来得到需要的服务。
这种构架的设计,一般是围绕消息队列来展开的:首先有一个消息队列,并对外暴露发送消息的API;然后实现一个负责维护并调度该消息队列的线程,该线程负责维护消息队列,并分发消息;最后是一系列处理特定消息的功能模块。消息由暴露给外层模块的API发送到消息队列,由调度线程接受消息,并分发给消息处理模块,然后由处理模块对不同消息进行处理,将处理结果返回给高层模块,这就是一个完善的基于消息队列的公用模块。为了实现这种模块的可扩展性,消息处理模块一般采取一种基于注册的设计,允许用户注册特定消息的消息处理函数。
这种构架从结构上看,是非常完善的,模块功能也比较好划分,因此应用广泛。但是根据个人经验,大部分这种模块的实现,在细节上都会有一些细微的瑕疵,给后期代码的维护和扩展带来麻烦,一下是个人遇到过的3中情况。
1. 消息的定义没有做到“原子化”。单一的功能被认为拆分成好几个消息。比如在一个为其它模块提供数据库访问服务的模块,将打开记录集,获取记录集,关闭记录集分成了3个消息,由于这3个消息在逻辑上有着顺序关系,而消息处理并不能很好的保证这种顺序关系,从而导致获取记录集时,记录集已经被关闭等等类似情况的出现(由于记录集可能很大,需要分多次获取,这种设计有时候也是不可避免)。
要处理这种情况,唯一的办法是保证想办法保证消息处理的顺序性,比如使