源起混乱的日志代码

在已经解释过为什么要新造一个日志框架。

但我想靠文字不能有深切的体会。

下面是我在读别人代码时经常看到的代码：

logger.info("#{}#{}#{}#{}#{}", new String[]{             orderInfo.getOrderNo() /*订单号*/,              orderInfo.getTradeCode() /*交易代码*/,              orderInfo.getReqSys() /*请求方系统*/,              orderInfo.getLocale() /*区域代码*/,              "req done" /*日志内容*/})

没有粗暴的用字符串相加，说明开发人员已经有一点水平了，但是……

这段代码意味着多糟糕的事情呢！？
写上面这段代码的可能是某个加班熬夜到神志模糊的程序员，更糟的是他借差迷糊劲把其中的两行写反了！
不对照着日志规范细扣，基本没有人能发现问题。

为了让WEB层的Controller与业务层的Service都能这样打印，Service层接口硬生生插入一个orderInfo，变成这样。

public void service(SomeThing toServed, OrderInfo orderInfo)

业务代码里面充斥着这样的代码，写的人不知疲倦，看的我心烦意乱了。

于是乎，我下定决心！要有一个日志框架，好好教人打日志。

logger.info("req done" /*日志内容*/)

必须像上面这样写日志代码，其它的内容全部实现自动填充！

设计原则

好！现在就来开始动手设计理想中的框架。但是在动手之前，还需要想清楚两件事。

第一，要走的更远，需要站在巨人的肩膀上。我无意实现一个跟log4j与logback之类雷同的框架。要利用上log4j或logback的特性，最好能兼容它们俩。

第二，一个好用的框架要做到称手。要对普通开发人员透明，减少使用者的学习成本。

考虑到以上两点，并结合我们应用常见的开发场景，我最终选定这个框架基于spring-boot实现。因为spring-boot提供了众多实用的机制可供选择。享受spring-boot带来便利的同时，也为spring-boot做一些贡献，互利互惠。

基本概念

在我们系统中，一个应用经常能过HTTP或MQ与外部应用沟通，我把沟通的内容称为消息。

消息中携带了许多关键信息，如前面提到的OrderNo、TradeCode等，需要被记录打印，我将其称为关键字。

我将系统常用日志分为三类，分别是系统运行日志、消息日志、告警日志，它们各自输出到不同的文件中。它们会被采集分析，分别服务于运维人员、分析系统、监控系统。由于对接系统不同，因此它们有各自的日志格式定义。

总体设计

日志框架示意图

如图展示，里层绿色为应用层，指业务开发人员编写的业务代码；外层蓝色部分为框架层，包含日志框架的各个功能模块。

简单地说，日志框架有以下要点：

在请求进入业务层之前进行拦截，获得消息（Message）。

根据关键字（Keyword），使用解析器（MessageResolver）提取消息（Message）中的值。关键字（Keyword）及其值保存于之中。

打印日志时，将中的值按格式自动填充到指定位置。

提供一个@MessageToLog注解，在函数上使用，将函数的返回值视作消息（Message），打印到消息日志中。

对系统运行日志，消息日志，告警日志三种不同的日志类型，有各自的追加器（Appender），分别写入到不同的文件中。

实现

具体代码实现，且听下回分解。

日志框架系列讲解文章