深度 | 從Go高效能日誌庫zap看如何實現高效能Go元件

對於 zap 這還不夠。標準庫中的 json.Marshaler 提供的是基於型別反射的拼接方式，代價是高昂的:

func (e *encodeState) marshal(v interface{}, opts encOpts) (err error) {
...
  e.reflectValue(reflect.ValueOf(v), opts) //reflect 根據 type 進行 marshal
...
}

反射的整體效能並不夠高，因此透過 Go 的反射可能導致額外的效能開銷。 zap 選擇了自己實現 json Encoder。 透過明確的型別呼叫，直接拼接字串，最小化效能開銷。

zap 的 json Encoder 設計的高效且較為易用，完全可以替換在程式碼中。 另一方面，這也是 Go 長期以來缺乏泛型的一個痛點 。對於一些效能要求高的操作，如果標準庫偏向於易用性。那麼我們完全可以繞開標準庫，透過自己的實現，規避掉額外效能開銷。 同樣，上文提到的 field 也是這個原因。 透過一個完整的自建型別系統，zap 提供了從組合日誌到編碼日誌的整體邏輯，整個過程中都是可以。

ps. 據說 Go 在2.0 中就會加入泛型啦, 很期待

避免競態

zap 的高效還體現在對於併發的控制上。 zap 選擇了 寫時複製機制。 zap 把每條日誌都抽象成了 entry。 對於 entry 還分為2種不同型別:

• Entry : 包含原始的資訊 但是不包含 field

• CheckedEntry: 經過級別檢查後的生成 CheckedEntry，包含了 Entry 和 Core。

CheckedEntry 的引入解決了組織日誌，編碼日誌的竟態問題。只有經過判斷的物件才會進入後續的邏輯，所有的操作 寫時觸發複製 ，沒有必要的操作不執行預分配。將操作與物件組織在一起，不進行資源的競爭，避免多餘的竟態條件。

對於及高效能的追求者來說，預先分配的 field 儘管有 pool 加持仍然是多餘的，因此 zap 提供了更高效能的介面，可以避免掉 field 的分配:

if ent := log.Check(zap.DebugLevel, "foo"); ent != nil {
  ent.Write(zap.String("foo", "bar"))
}

透過這一步判斷，如果該級別日誌不需要列印，那麼連 field 都不必生成。 避免一切不必要的開銷，zap 確實做到了而且做得很好。

多樣的功能與簡單的設計理念

level handler:

level handler 是 zap 提供的一種 level 的處理方式，透過 http 請求動態改變日誌元件級別。

對於日誌元件的動態修改，seelog 最早就有提供類似功能，基於 xml 檔案修改捕獲新的級別。 但是 xml 檔案顯然不夠 golang。

zap 的解決方案是 http 請求。http 是大家廣泛應用的協議，zap 定義了 level handler 實現了 http.Handler 介面

Go 自身的 http 服務實現起來非常的簡潔:

http.HandleFunc("/handle/level", zapLevelHandler)
if err := http.ListenAndServe(addr, nil); err != nil {
    panic(err)
}

簡單幾行程式碼就能實現 http 請求控制日誌級別的能力。 透過 GET獲取當前級別，PUT 設定新的級別。

zap 的 surgar log 和易用 config 介面封裝

我們的庫往往希望提供事無巨細的控制能力。但是對於簡單的使用者就不夠友好，繁雜的配置往往容易使人第一次使用即失去耐心。同時，一個全新的 log 介面設計也容易讓長期使用 format 方式列印日誌的人產生疑問。在工作中發現較多的使用者有這樣的需求: 你的這個庫怎麼用?

顯然只有 godoc 還不夠。

zap 的 Config 非常的繁瑣也非常強大，可以控制列印 log 的所有細節，因此對於我們開發者是友好的，有利於二次封裝。但是對於初學者則是噩夢。因此 zap 提供了一整套的易用配置，大部分的姿勢都可以透過一句程式碼生成需要的配置。

func NewDevelopmentEncoderConfig() zapcore.EncoderConfig
func NewProductionEncoderConfig() zapcore.EncoderConfig
type SamplingConfig

同樣，對於不想付出代價學習使用 field 寫格式化 log 的使用者，zap 提供了 sugar log。 sugarlog 字面含義就是加糖。 給 zap 加點糖，sugar log 提供了 formatter 介面，可以透過 format的方式來列印日誌。sugar 的實現封裝了 zap log，這樣既滿足了使用 printf 格式串的相容性需求，同時也提供了更多的選擇，對於不那麼追求極致效能的場景提供了易用的方式。

sugar := log.Sugar()
sugar.Debugf("hello, world %s", "foo")

zap logger 提供的 utils

zap 還在 logger 這層提供了豐富的工具包，這讓整個 zap 庫更加的易用:

• grpc logger：封裝 zap logger 可以直接提供給 grpc 使用，對於大多數的 Go 分散式程式，grpc 都是預設的 rpc 方案，grpc 提供了 SetLogger 的介面。 zap 提供了對這個介面的封裝。

• hook：作為 zap。Core 的實現，zap 提供了 hook。 使用方實現 hook 然後註冊到 logger，zap在合適的時機將日誌進行後續的處理，例如寫 kafka，統計日誌錯誤率 等等。

• std Logger: zap 提供了將標準庫提供的 logger 物件重定向到 zap logger 中的能力，也提供了封裝 zap 作為標準庫 logger 輸出的能力。 整體上十分易用。

• sublog: 透過建立 系結了 field 的子logger，實現了更加易用的功能。

zap 的好幫手: RollingWriter

zap 本身提供的是設定 writer 的介面，為此我實現了一套 io.Writer，透過rolling writer 實現了 log rotate 的功能。

rollingWriter 是一個 Go ioWriter 用於按照需求自動滾動檔案。 目的在於內建的實現 logrotate 的功能而且更加高效和易用。

具體可以見

https://github.com/arthurkiller/rollingWrite

總結

zap 在整體設計上有非常多精細的考量，不僅僅是在高效能上面的出色表現，更多的意義是其設計和工程實踐上。此處總結下 zap 的程式碼之道:

• 合理的程式碼組織結構，結構清晰的抽象關係

• 寫實複製，避免加鎖

• 物件記憶體池，避免頻繁建立銷毀物件

• 避免使用 fmt json/encode 使用字元編碼方式對日誌資訊編碼，適用byte slice 的形式對日誌內容進行拼接編碼操作

其實 zap 帶給我們的遠不止這些，在這裡建議有興趣的朋友一定要抽時間看一下 zap 的原始碼，確實有很多細節需要我們細細體味。

相關閱讀：

• 用Go構建Teamwork專案的9條教訓

• 一個專家眼中的Go與Java垃圾回收演演算法大對比

• 是的，為了更好的支援微服務，我們從PHP遷移到了Go

高可用架構

改變網際網路的構建方式

長按二維碼 關註「高可用架構」公眾號

李子昂

贊賞

長按二維碼向我轉賬

受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。

微信掃一掃
使用小程式
即將開啟""小程式
取消
開啟