注意事項

在使用SkyWalking之前，還需要考慮以下5個注意事項。

SkyWalking的數據收集機制

中間件在收集日誌的時候，不可能是同步的。為什麼呢？如果每次記錄日誌都要發一個請求到中間件，等中間件返回結果以後，才算日誌記錄完成，進入下一個動作，那麼這個請求的響應時間肯定變慢。而且這種情況下，業務系統和日誌系統是耦合的，業務系統要保證絕對高可用，而日誌系統只是用來為研發人員調研問題提供方便的，對可用性的要求沒有那麼高。也不可能讓高可用的系統依賴中可用的系統。

所以這個日誌收集的過程必須是異步的，和業務流程解耦。

SkyWalking的數據收集機制是這樣的：服務中有一個本地緩存，把收集的所有日誌數據先存放在這個緩存中，然後後台線程通過異步的方式將緩存中的日誌發送給SkyWalking服務端。這種機制使得在日誌埋點的地方無須等待服務端接收數據，也就不影響系統性能。

如果SkyWalking服務端宕機了，會出現什麼情況

如果服務端宕機了，理論上日誌緩存中的數據會出現沒人消費的情況，這樣會不會導致數據越積越多，最終超出內存呢？

在SkyWalking中會設置緩存的大小，如果這部分數據超出了緩存大小，Trace不會保存，也就不會超出內存了。

流量較大時，如何控制日誌的數據量

流量大時，不可能收集每個請求的日誌，否則數據量會過大。那SkyWalking如何控制採樣比例呢？

SkyWalking會在每個伺服器上配置採樣比例，比如設置為100，代表1%的請求數據會被收集，代碼如下所示。

這樣就可以通過sampleRate來控制採樣比例了。一般而言，流量越大，採樣比例越小。

不過，這裡有兩點需要特別注意。

1）一旦啟用forceSampleErrorSegment，出現錯誤時就會收集所有的數據，此時sampleRate對出錯的請求不再適用。

2）所有相關聯服務的sampleRate最好保持一致，如果A調用B，然後A、B的採樣比例不一樣，就會出現一個Trace串不起來的情況。

日誌的保存時間

一般來說，日誌不需要永久保存，通常是保存3個月的數據，關於這一點大家結合公司的實際情況進行配置即可。

按照以前的設計方案，需要自己設計一個工具將數據進行定時清理，不過此時可以直接使用SkyWalking進行配置，代碼如下所示。

集群配置：如何確保高可用

先來看看SkyWalking官方文檔給出的SkyWalking架構，如圖9-7所示。

在此架構中，需要關注SkyWalking的收集服務（Receiver）和聚合服務（Aggregator），它們支持集群模式。同時，在集群服務里，多個服務節點又需要一些協調服務來協調服務間的關係，它們支持Kubernetes、ZooKeeper、Consul、etcd、Nacos（開源的協調服務基本都支持）。

前面多次提及ZooKeeper，此時大家應該猜得到項目組最終的選型。

小結

在方案中使用SkyWalking後，對於問題排查幫助非常大。比如再碰到類似登錄失敗的問題時，根據關鍵字查到TraceID以後，基於TraceID調出所有的請求日誌，到底發生了什麼就會一目了然。

這個全鏈路日誌系統上線以後，團隊優化了很多慢請求，因為每個調用環節和耗時都列出來了，很容易就能找到瓶頸點並加以解決。基於這個系統，團隊完成了多個可以匯報的亮點工作。

但是SkyWalking也存在不足，比如一開始使用的版本存在很多兼容性問題。不過現在它改善不少，只要使用最新版，基本上問題不大。

這次的架構經歷不涉及太多的架構設計，主要是技術選型和一些注意事項。希望通過上面的講解，幫助大家快速理解全鏈路日誌，並針對技術選型問題快速做出決策。

本文給大家講解的內容是基於常見組件的微服務場景實戰，全鏈路日誌的注意事項

1. 下篇文章給大家講解的內容是基於常見組件的微服務場景實戰，熔斷，業務場景：如何預防一個服務故障影響整個系統
2. 覺得文章不錯的朋友可以轉發此文關注小編；
3. 感謝大家的支持！