Log 問題域
- 如何不帶來額外的效率損失
- 如何在程序運行出錯時記錄盡可能多的信息
- 如何方便查找特定條件的錯誤
- 如何橫切的添加通用信息
如何不帶來額外的效率損失
在之前接觸的一個大型產品中見過散布著如下代碼:
if (Log.Level > DEBUG) {
logger.write(some_method_to_build_the_log_string());
}
問為什么不在logger.write()里面判斷日志級別, 這樣外面寫起來就很清爽
logger.write(some_method_to_build_the_log_string());
答曰效率問題, 后面一種寫法會導致無論日志最終有沒有被寫入, some_method_to_build_the_log_string()都會先行被調用求值, 而這可能很耗時...
一個解決辦法是額外的中間層: 能夠延時求值的東東, 比如函數指針, 函數對象, 總而言之能夠保存當前上下文而在將來某個時刻能夠回調的東西, 諸如 C# 里的 Func<string>
這樣logger.write()的簽名就從 void write(string info) 變成 void write(Func<string> getInfo);
帶來的一個問題是啥時真正寫入, 一般可以是用戶事務結束的時候. 其實當并發用戶量大時, 表面上延時求值可以不阻礙當前請求的處理速度, 但當求值發生時, 可能會阻礙其它請求的處理. 所以Func<string>代替string效率上的優勢并不明顯, 更多的是代碼上的簡潔
(Func<string>的另一個好處是把IO操作推遲了, 當時沒有IO操作，所有IO操作都被推到完成用戶請求之后再進行，尤其是如果因為其它原因需要把Log存到數據庫的時候. 當然不用Func<string>, 直接用string也可以實現推遲IO操作, 只需要把string都緩存起來, 找個時機再寫出來即可)
然而Func<string>更大的意義是解決第二個問題:
如何在程序運行出錯時記錄盡可能多的信息
通常最終寫到日志里的信息, 都是根據配置的級別決定的, 比如配置了日志級別是INFO, 那么無論出不出錯, DEBUG級別的信息都不會被寫到日志里. 然而現實情況是, 一旦出錯, 我們可能需要DEBUG信息來定位問題. 于是我們不得不把日志級別設置成DEBUG,然后重新運行應用,企圖復現. 但運行環境的差異使得復現像撞大運, 可遇不可得. 于是在案發第一現場就記錄所有線索變得極具效率
對日志即時求值和寫入是很難實現這個目的的, 而延時求值, 回調, 這層額外的間接則將其變得輕而易舉.
我們要做的就是保存所有寫日志的回調, 直到寫入的那一刻, 根據某種規則, 從中挑選部分回調真正去執行; 規則可以是正常情況下根據日志級別設置, 出錯的時候則全部寫入, 等等
(這里的目的就是避免日志過于簡略或者繁瑣, 鼓勵大家多寫日志而不必擔心運行時效率)
如何方便查找特定條件的錯誤
查找是數據庫的強項, 把日志結構化, 存到數據庫里即可. 這會帶來事務的問題: 寫日志是否和用戶正常的業務放在一個事務里?
如何橫切的添加通用信息
如果把log建模為一個對象, 可以應用builder模式, pipeline等, 讓log對象依次通過一堆builder組成的pipeline, 每個builder負責給log增磚添瓦, 最后出來的就是一個包含了各種彼此獨立的信息的對象