日志系统的设计（上）

 

考虑日志系统的设计有一阵子了，因为不是当前必做的任务，也就有了更多的时间去思考它。其间在baidu上中文搜索了一下，发现关于日志系统的中文资料极少，google的英文文档倒是搜出了不少，有些无奈。

首先，明确设计日志系统的目的，不仅仅是帮助开发人员找臭虫，很多软件本身也需要记录一些相关信息。所以，我考虑的日志系统需要达到以下几个目的。

一、             能够在软件本身发生致命错误时不受其影响，正确记录其信息，这是优先级最高的debug需要。

二、             日志系统必须是一个独立的模块，方便重用，这是设计的本身目的。

三、             日志系统不能成为错误的根源，即它本身不能成为影响软件稳定性的因素。显然这个目标不能百分百达到，只能尽量避免。

四、             当然，日志系统必须尽可能少的占用资源，不能影响到软件本身的性能。

五、             最后就是日志系统本身的功能需求了，也即它的内容，包括记录分级，时间和具体格式。

 

参考了一些开源项目的日志系统，基本明确了日志系统本身的功能需求。

首先，要能通过配置文件自由设定记录的级别，一般分四种：Error、Warning、Success、Information。在这方面的思路是，软件本身无差别的向日志系统输出开发者定义的信息，而是否记录，则由日志系统根据其配置决定，也即日志系统要有过滤功能。

其次，记录包含时间和代码出处，方便开发者定位错误。这点很容易理解，也是最基本的功能。我们可以用_FILE_和_LINE_来定位源代码的位置，使用起来也很方便。但是有一点需要注意，日志系统的最初目的，并不仅仅针对开发者，同样适用于发布给使用者的版本。所以，我们想把定位错误封装起来，不要让使用者接触到。显然，使用__FILE__和__LINE__并不是最佳方案。我们必须在软件本身设置错误宏编码，从而通过开发者私有的编码表迅速定位，达到封装的目的。

这样，当客户反馈发布版出问题时，我们只要告诉他们，把日志配置成Information，然后回寄日志给我们就可以了，如此简单。

 

具体到结构设计时，第一个和第三个目的成了最大的问题。目的本身存在着逻辑问题，如何确保作为软件一部分的日志系统能够正确记录到硬盘而不产生错误呢，甚至影响到软件本身的稳定？这陷入了一个死循环，类似于先有鸡还是先有蛋的问题。显然，这个问题缺少最完美的方案。所以，我只能尽量剥离日志系统，将其分离成一个独立的记录进程！

如此一来，架构很明显了，日志系统作为一个独立的进程，而软件将其记录信息传递到日志系统，即使软件崩溃了，只要来得及将其错误信息发送出去，日志系统将不受影响地记录下来。两个并联的系统远比串联系统可靠的多！而且，这也直接达到了第四个目的要求。

进程间通信有很多方法，共享内存、邮槽、文件、管道等等，而管道无疑是以前最常用的方法，不过我似乎记得在哪本书上看到，尽量用socket来代替管道，好吧，就用socket吧，至少，这样的话，跨平台就相当容易，非常方便扩展。

最终的架构呼之欲出，我们先设计一台日志服务器，它只管接受信息、过滤并忠实地记录。再设计一个作为“客户端”的库，只需要一个接口，所有软件只要简单调用库的记录接口就可以了，无需关心任何细节！

这样做的最大好处，就是一次完成，反复使用！尤其是针对分布式服务器的日志，我们可以单独设立一台服务器跑我们的日志系统，而将所有其他的服务器日志集中定位到那台日志服务器，完美的解决方案！

至于具体细节设计，且待下篇。