【開發經驗】日志架構分類和選擇

文章目錄

• 1、起源
• 2、日志架構選擇
• 3、SLF4j使用問題
• 4、相容性問題
• 附錄

• 門面模式

        在很多開發者都會有一個習慣，在程式的重要步驟列印關鍵的資訊。通過這種方式可以在看出程式的執行狀态，在程式遇到問題時，可以進行快速定位。在沒有日志架構出現之前，開發者是通過​

​System.out​

​等方式進行日志資訊的列印。這種方式有一些很明顯的弊端：

1. 效率低下，如果列印的日志較多會影響程式速度
2. 不靈活，日志的格式，日志檔案儲存的位置不好修改。
3. 也許想在測試環境列印較多的日志，在生産環境會去掉部分日志。

        就如上的一些列問題，慢慢的出現了日志架構。日志架構的功能很簡單，無非是列印日志。于是作者變想到了門面模式。在開發的時候，開發者選用門面進行調用方法，即可進行列印。通過引用不同的jar包進行不同的實作。

日志門面（抽象層）	實作類
JCL（Jakarta Commons Logging）、 SLF4j（Simple Logging Facade for Java）、 jboss-logging	Log4j、 JUL（java.util.logging）、Log4j2 、Logback

        展示了常有的日志門面和日志實作，由于​

​JCL​

​ 現在已經不在更新。​

​jboss-logging​

​ 一般不在業務開發中使用此架構。是以一般​

​SpringBoot​

​業務開發中會優先去使用​

​SLF4j​

​門面。

        ​

​SLF4j、Log4j、Logback​

​是出自同一個人之手，​

​Logback​

​是​

​Log4j​

​的更新版本。是以，一般在​

​SpringBoot​

​開發中，一般會使用​

​SLF4j+Logback​

​進行日志列印。

注：​

​Log4j2​

​和​

​Log4j​

​隻是名字類似一樣，其實并沒有特别大的聯系。

        在SpringBoot開發中，需要調用​

​SLF4j​

​的門面方法進行日志列印，否則這種門面模式就毫無意義。

        就上圖來說，​

​application​

​為我們的應用程式，在此可以認為是SpringBoot工程。從左到右依次解釋：

1. 當引用​

   ​SLF4j​

   ​的包時，雖然是可以進行日志的列印，但是最終會列印到一個空的位置，​

   ​/dev/null​

   ​是linux的一個空的檔案夾，這個會在稍後解釋，總之就是不儲存。
2. 如果想使用​

   ​logback​

   ​為項目的日志架構時，可以應用​

   ​logback​

   ​的jar即可。​

   ​SLF4j​

   ​logback​

   ​就是一個配套使用的。

3. ​log4j​

   ​，這就有點尴尬了，因為​

   ​log4j​

   ​出生比較早，在​

   ​log4j​

   ​編碼的時候，就沒有想過要适配​

   ​SLF4j​

   ​。是以，如果想使用​

   ​SLF4j+log4j​

   ​時，需要加一個适配層，引入​

   ​slf4j-log412.jar​

   ​進行适配。
4. 後面三個用的不多，不在過多闡述。

        也許我們的項目中使用​

​logback​

​日志架構，但是并不能要求其它的代碼也用這個架構。就好比 Spring（commons-logging）、Hibernate（jboss-logging）還有MyBatis等等。這種千奇百怪的日志架構，肯定都要被我們項目中使用的日志架構适配。

如何讓系統中所有的日志都統一到slf4j？

1、将系統中其他日志架構先排除出去；如果使用commons-logging.jar則替換為jcl-over-slf4j.jar以此類推。

2、用中間包來替換原有的日志架構；

3、我們導入slf4j其他的實作

問題：如果使用commons-logging.jar則替換為jcl-over-slf4j.jar，編譯的時候不會報錯嗎？

        像​

​jcl-over-slf4j.jar​

​是一個适配的​

​jar​

​，通過這個​

​jar​

​有​

​commons-logging.jar​

​的所有類和方法，但是修改了其實作。如下圖，​

​jcl​

​的包名和類名與​

​commons-logging​

​的一樣，這樣就不會編譯報錯了。

通過這種偷梁換柱的方式，将核心jar的代碼進行替換，達到替換其原有日志架構的實作。