為什麼阿裡巴巴禁止工程師直接使用日志系統(Log4j、Logback)中的 API

作為Java程式員，我想很多人都知道日志對于一個程式的重要性，尤其是Web應用。很多時候，日志可能是我們了解應用程式如何執行的唯一方式。

是以，日志在Java Web應用中至關重要，但是，很多人卻以為日志輸出隻是一件簡單的事情，是以會經常忽略和日志相關的問題。

在接下來的幾篇文章中，我會來介紹介紹這個容易被大家忽視，但同時也容易導緻故障的知識點。

Java語言之是以強大，就是因為他很成熟的生态體系。包括日志這一功能，就有很多成熟的開源架構可以被直接使用。

首先，我們先來看一下目前有哪些架構被廣泛的使用。

常用日志架構

j.u.l

j.u.l是java.util.logging包的簡稱，是JDK在1.4版本中引入的Java原生日志架構。Java Logging API提供了七個日志級别用來控制輸出。這七個級别分别是：SEVERE、WARNING、INFO、CONFIG、FINE、FINER、FINEST。

Log4j

Log4j是Apache的一個開源項目，通過使用Log4j，我們可以控制日志資訊輸送的目的地是控制台、檔案、GUI元件，甚至是套接口伺服器、NT的事件記錄器、UNIX Syslog守護程序等；我們也可以控制每一條日志的輸出格式；

通過定義每一條日志資訊的級别，我們能夠更加細緻地控制日志的生成過程。Log4也有七種日志級别：OFF、FATAL、ERROR、WARN、INFO、DEBUG和TRACE。

最令人感興趣的就是，這些可以通過一個配置檔案來靈活地進行配置，而不需要修改應用的代碼。

LogBack

LogBack也是一個很成熟的日志架構，其實LogBack和Log4j出自一個人之手，這個人就是Ceki Gülcü。

logback目前分成三個子產品：logback-core,logback- classic和logback-access。

logback-core是其它兩個子產品的基礎子產品。

logback-classic是Log4j的一個改良版本。此外logback-classic完整實作SLF4J API使你可以很友善地更換成其它日記系統如Log4j或j.u.l。

logback-access通路子產品與Servlet容器內建提供通過Http來通路日記的功能。

Log4j2

前面介紹過Log4j，這裡要單獨介紹一下Log4j2，之是以要單獨拿出來說，而沒有和Log4j放在一起介紹，是因為作者認為，Log4j2已經不僅僅是Log4j的一個更新版本了，而是從頭到尾被重寫的，這可以認為這其實就是完全不同的兩個架構。

關于Log4j2解決了Log4j的哪些問題，Log4j2相比較于Log4j、j.u.l和logback有哪些優勢，我們在後續的文章中介紹。

禁止直接使用Log架構API？

前面介紹了四種日志架構，也就是說，我們想要在應用中列印日志的時候，可以使用以上四種類庫中的任意一種。比如想要使用Log4j，那麼隻要依賴Log4j的jar包，配置好配置檔案并且在代碼中使用其API列印日志就可以了。

不知道有多少人看過《阿裡巴巴Java開發手冊》，其中有一條規範做了『強制』要求：

說好了以上四種常用的日志架構是給Java應用提供的友善進行記錄日志的，那為什麼又不讓在應用中直接使用其API呢？這裡面推崇使用的SLF4J是什麼呢？所謂的門面模式又是什麼東西呢？

什麼是日志門面

日志門面，是門面模式的一個典型的應用。

門面模式（Facade Pattern），也稱之為外觀模式，其核心為：外部與一個子系統的通信必須通過一個統一的外觀對象進行，使得子系統更易于使用。

就像前面介紹的幾種日志架構一樣，每一種日志架構都有自己單獨的API，要使用對應的架構就要使用其對應的API，這就大大的增加應用程式代碼對于日志架構的耦合性。

為了解決這個問題，就是在日志架構和應用程式之間架設一個溝通的橋梁，對于應用程式來說，無論底層的日志架構如何變，都不需要有任何感覺。隻要門面服務做的足夠好，随意換另外一個日志架構，應用程式不需要修改任意一行代碼，就可以直接上線。

在軟體開發領域有這樣一句話：計算機科學領域的任何問題都可以通過增加一個間接的中間層來解決。而門面模式就是對于這句話的典型實踐。

為什麼需要日志門面

前面提到過一個重要的原因，就是為了在應用中屏蔽掉底層日志架構的具體實作。這樣的話，即使有一天要更換代碼的日志架構，隻需要修改jar包，最多再改改日志輸出相關的配置檔案就可以了。這就是解除了應用和日志架構之間的耦合。

有人或許會問了，如果我換了日志架構了，應用是不需要改了，那日志門面不還是需要改的嗎？

要回答這個問題，我們先來舉一個例子，再把門面模式揉碎了重新解釋一遍。

同理，對于一個設計的全面、完善的日志門面來說，他也應該是天然就相容了多種日志架構的。是以，底層架構的更換，日志門面幾乎不需要改動。

以上，就是日志門面的一個比較重要的好處——解耦。

常用日志門面

介紹過了日志門面的概念和好處之後，我們看看Java生态體系中有哪些好的日志門面的實作可供選擇。

SLF4J

Java簡易日志門面（Simple Logging Facade for Java，縮寫SLF4J），是一套包裝Logging 架構的界面程式，以外觀模式實作。可以在軟體部署的時候決定要使用的 Logging 架構，目前主要支援的有Java Logging API、Log4j及logback等架構。以MIT 授權方式釋出。

SLF4J 的作者就是 Log4j和Logback 的作者 Ceki Gülcü，他宣稱 SLF4J 比 Log4j 更有效率，而且比 Apache Commons Logging (JCL) 簡單、穩定。

其實，SLF4J其實隻是一個門面服務而已，他并不是真正的日志架構，真正的日志的輸出相關的實作還是要依賴Log4j、logback等日志架構的。

由于SLF4J比較常用，這裡多用一些篇幅，再來簡單分析一下SLF4J，主要和Log4J做一下對比。相比較于Log4J的API，SLF4J有以下幾點優勢：

·Log4j 提供 TRACE, DEBUG, INFO, WARN, ERROR 及 FATAL 六種紀錄等級，但是 SLF4J 認為 ERROR 與 FATAL 并沒有實質上的差别，是以拿掉了 FATAL 等級，隻剩下其他五種。

·大部分人在程式裡面會去寫logger.error(exception),其實這個時候Log4j會去把這個exception tostring。真正的寫法應該是logger(message.exception);而SLF4J就不會使得程式員犯這個錯誤。

·Log4j間接的在鼓勵程式員使用string相加的寫法（這種寫法是有性能問題的），而SLF4J就不會有這個問題 ,你可以使用logger.error(“{} is+serviceid”,serviceid);

·使用SLF4J可以友善的使用其提供的各種集體的實作的jar。（類似commons-logger）

·從commons–logger和Log4j merge非常友善，SLF4J也提供了一個swing的tools來幫助大家完成這個merge。

·SLF4J 隻支援 MDC，不支援 NDC。

·提供字串内容替換的功能，會比較有效率，說明如下：

commons-logging

Apache Commons Logging是一個基于Java的日志記錄實用程式，是用于日志記錄和其他工具包的程式設計模型。它通過其他一些工具提供API，日志實作和包裝器實作。

commons-logging和SLF4J的功能是類似的，主要是用來做日志 門面的。提供更加好友的API工具。

總結

在Java生态體系中，圍繞着日志，有很多成熟的解決方案。關于日志輸出，主要有兩類工具。

一類是日志架構，主要用來進行日志的輸出的，比如輸出到哪個檔案，日志格式如何等。 另外一類是日志門面，主要一套通用的API，用來屏蔽各個日志架構之間的差異的。

是以，對于Java工程師來說，關于日志工具的使用，最佳實踐就是在應用中使用如Log4j + SLF4J 這樣的組合來進行日志輸出。

這樣做的最大好處，就是業務層的開發不需要關心底層日志架構的實作及細節，在編碼的時候也不需要考慮日後更換架構所帶來的成本。這也是門面模式所帶來的好處。

綜上，請不要在你的Java代碼中出現任何Log4j等日志架構的API的使用，而是應該直接使用SLF4J這種日志門面。