微服務轉型繞不開的坑——日誌記錄這樣作就對了

在現在企業紛紛轉型微服務的過程當中，微服務架構中日誌記錄的重要性時常會被忽略。本文做者十分關注微服務日誌記錄，提出了獨到的觀點，並與你們分享關於微服務日誌記錄的各類技巧的最佳實踐。

微服務架構是一種軟件架構類型，着重於利用大量細分組件進行應用開發，其中每一個組件都負責總體業務中的一小部分。這些組件彼此獨立，支持在本身的進程之上，且可以相互通訊以實現業務目標。

爲何要關注日誌記錄？

不少企業都開始將總體型應用拆分爲微服務形式。而在拆分大型應用時，咱們須要創建鬆散耦合的模塊，從而保證其便於測試並下降變動風險。另外，這些模塊亦可獨立部署以實現橫向規模擴展。然而，這也會帶來一些初看並不嚴重，但長遠影響極其重大的問題——其中的典型表明就是日誌記錄。

日誌記錄存在於一切應用當中，不管其屬於總體仍是微服務架構。關鍵在於，當咱們將應用拆分爲微服務形式時，咱們須要投入大量時間來思考業務邊界並找尋最理想的應用邏輯拆分方式——但不多有人會對日誌記錄給予應有的重視。

固然，你們可能會問：日誌記錄的方式一直沒有變化過，爲何如今倒成了須要關注的問題？

理由在於，總體應用內的事務追蹤每每比較困難，有時候咱們只能依靠日誌記錄來理解當前情況。另外，當業務邏輯運行在多項服務中時，監控與日誌記錄的難度也會相應增長。這意味着若是咱們沒有明智地規劃出微服務記錄機制，那麼最終可能根本沒法理解應用的當前運行狀態。

正由於如此，我想與你們分享個人我的經驗以及做爲軟件開發者積累到的一點心得。近年來我一直在使用微服務方案，但願你們可以在讀完本文後意識到日誌記錄的重要性與實現難點。

心得一——設立應用實例標識符

在使用微服務時，整套體系每每會同一時間運行同一組件的多個實例。最重要的就是在日誌條目中設立實例標識符，從而區分各條目的具體來源。其ID的具體生成方式其實並不重要，只要保證唯一便可，這樣咱們才能藉此回溯到特定服務器/容器以及生成該條目的應用處。在微服務架構中，你們能夠利用服務註冊表輕鬆爲每項服務分配唯一的標識符。

心得二——堅持使用UTC時間

這項心得不只適用於微服務架構，在其它場景下也一樣值得堅持。任何使用過度布式應用程序——或者組件分散在各處——的朋友，都會意識到各組件使用不一樣時區進行計時有多麼使人頭痛。而在微服務架構中，以本地時間記錄的日誌條目會帶來更嚴重的問題。若是你們確實須要使用本地時間，請在日誌條目中以字段形式添加時區，從而簡化信息的檢索方式。但更重要的是必定要爲UTC時間設立時區，並利用它在聚合工具內進行信息排序。
下面來看示例日誌信息：

第一部分是由一項運行在新西蘭的服務所生成。第二部分則由運行在巴西的服務生成。因爲咱們使用本地日期，所以由巴西服務生成的信息會早於新西蘭信息——但其實際生成時間卻偏偏相反。

如今，讓咱們看看使用UTC時間與時區後的示例信息：

如今兩條信息已經獲得正確的時間排序，若是你們但願瞭解信息的本地生成時間，則可將其由UTC轉換爲特定時區。

心得三——生成請求標識符

在將業務邏輯拆分爲多個不一樣組件時，咱們的邏輯最終須要由一個或者多個組件構成。而在追蹤這些事務時，咱們每每很難對其加以識別。所以，你們應當爲每一個事務生成一個唯一標識符，並利用其關聯事件以及追蹤各項事務。

想象一下，若是咱們須要利用如下請求序列在某電子商務網站上購買產品：

那麼咱們對於操做的分組方法，顯然取決於事務的實際定義（畢竟其也可以進行嵌套）。最重要的是確保在事務開端，咱們爲其建立一個可以傳遞下去的標識符，並藉此在事務結束以前全程記錄日誌條目。

通常來說，我傾向於使用人工生成的ID來區分本身的事務。你們也可使用user_id或者session_id處理與用戶相關的事務。而在進行結算與支付時，你們可使用order_id來追蹤結算與付款操做。不過其前提是你們已經進行了用戶登陸，或者建立了擁有order_id的訂單——但實際狀況每每並不是如此。在使用手動ID時，你們能夠將事務ID從業務邏輯流中解耦出來。

另外須要注意的是，這些ID須要擁有足夠的信息以對系統中的各項事務進行區分。有時候事務識別符可能在日誌條目中體現爲一整套字段組合。

心得四——利用聚合工具進行日誌分組

若是你們沒有對來自所有微服務的日誌條目進行聚合，那麼以上提到的心得將毫無心義。要實現這一目標，咱們須要使用一款可以輕鬆實現條目分組與查詢的工具。我我的使用ELK堆棧，其效果至關出色。若是你們以前沒聽過ELK，這裏能夠稍微解釋幾句。ELK是三款應用的集合體，由此構成的完整解決方案可以調度日誌條目、實現條目存儲與索引，然後對信息進行聚合與可視化處理。

咱們能夠利用ELK對應用程序日誌進行多種規模伸縮與分發處理，但這裏就不講太多了。感興趣的朋友能夠查看Logz.io博客上的Logstash教程，其中提到了多項相關使用技巧。另外，咱們也可使用Logz.io等企業服務處理日誌基礎設施的設置與維護工做，從而確保本身的微服務體系採用最理想的日誌記錄實踐方案。

總結

這篇文章的目的是向你們強調在微服務架構中重視日誌記錄的必要性，同時分享一些在實際應用當中積累到的最佳實踐。但這僅僅是個開始，相信你們可以採用多種其它方式解決日誌記錄難題。

文章來源：Logz.io 做者 Lucas Saldanha