全鏈路追蹤！微服務運維人員終於解放了

一個人身體不舒服才想起沒有定期體檢
顯然已經晚了
微服務架構也是一樣
只有實時監控、定期體檢
系統中各服務的執行狀態才會健康
那麼，如何為“微服務”體檢呢？
全鏈路追蹤 就是微服務的“體檢中心”

微服務的“身體構造”
當我們進行微服務架構開發時，通常會根據業務來劃分微服務，各業務之間通過網路通訊進行呼叫。一個使用者操作，可能需要很多微服務的協同才能完成。在業務呼叫鏈路上，任何一個微服務出現問題或者網路超時，都會導致功能失敗。隨著業務越來越多，對於微服務之間的呼叫鏈的分析會越來越複雜。

在擁有眾多服務的微服務應用中，如何知道一次請求呼叫的是哪條鏈路？當請求呼叫失敗時，如何知道是哪個服務出現了問題導致呼叫失敗？一次請求響應時間長，到底是哪些服務耗時長的？……
你可能會說，可以通過檢視每個服務的日誌來分析這些資訊。但是應用的服務有可能部署到了上百個節點上，人工查詢顯然是不現實的。
為了檢視微服務應用在實際執行中各個服務的執行狀態，每次呼叫各個環節執行情況，我們需要一個微服務應用的體檢中心，這就是全鏈路追蹤。
為微服務“全身檢查”

SaCa ACAP 在微服務領域積累了大量的技術實踐，打造了一套獨有的全鏈路追蹤元件。
通過服務呼叫日誌我們能夠分析出整個微服務應用的呼叫情況。為了解決服務日誌分散在各個節點上，首先需要將日誌統一進行收集，然後將收集的資料進行過濾彙總，之後對彙總的資料進行鏈路分析，形成鏈路呼叫的資料，最後將資料用友好清晰的方式展現出來，這就是鏈路追蹤的全過程。
你可能會說“這個過程聽起來好像日誌分析系統啊”，沒錯，我們的鏈路追蹤就是基於 ELK 日誌分析系統方案實現的。使用 Filebeat 收集各個服務的日誌、使用 Logstash 完成日誌資料的過濾， Elasticsearch 負責日誌的儲存於分析。

但是不要以為這就是鏈路追蹤的全部，SaCa ACAP 還能解決更多問題。
程式碼入侵性
作為支撐業務元件，應當儘可能少入侵或者無入侵其他業務系統，對於使用方透明，減少開發人員的負擔。
對於應用的程式設計師來說，是不需要知道有追蹤系統這回事的。如果一個追蹤系統想生效，就必須需要依賴應用的開發者主動配合，那麼這個追蹤系統也太脆弱了，往往由於追蹤系統在應用中植入程式碼的 bug 或疏忽導致應用出問題，這樣才是無法滿足對追蹤系統“無所不在的部署”這個需求。
為此 SaCa ACAP 採用了應用採用了應用監控元件 SkyWalking。它基於 Javaagent 技術，對程式碼無入侵。將應用和探針一起部署，就能實現對服務的監控。服務每次呼叫都會產生相應的日誌資訊。
探針的效能消耗
APM 元件服務的影響應該做到足夠小。服務呼叫埋點本身會帶來效能損耗，這就需要呼叫追蹤的低損耗，在一些高度優化過的服務，即使一點點損耗也會很容易察覺到，而且有可能迫使線上服務的部署團隊不得不將追蹤系統關停。
效能的損耗很大一部分來自於將日誌同步寫入到檔案當中。同步檔案 IO 操作會產生阻塞，造成執行緒等待和執行緒上線文切換。
解決辦法就是採用非同步方法，非同步方法先在堆記憶體中儲存日誌，然後批量寫入到檔案中。
但是非同步寫入會佔用一部分用於處理業務的堆記憶體，為了儘可能的減少對業務執行的影響，我們首先將日誌寫入到堆外記憶體中，然後在寫入到檔案中。減少 IO 阻塞的同時也降低了對業務執行的影響。
分散式追蹤 ID
業務系統中，涉及到各種各樣的 ID ，如在支付系統中就會有支付 ID 、退款 ID 等。
一般來說有下面幾點要素：
唯一性：確保生成的 ID 是全網唯一的
有序遞增性：確保生成的 ID 是對於某個使用者或者業務是按一定的數字有序遞增的
高可用性：確保任何時候都能正確的生成 ID
帶時間： ID 裡面包含時間

我們的 ID 生成演算法是基於 Twitter 的 snowflake 演算法。
41 位的時間序列，精確到毫秒，可以使用 69 年
10 位的機器標識，最多支援部署 1024 個節點
12 位的序列號，支援每個節點每毫秒產生 4096 個 ID 序號，最高位是符號位始終為 0
同時我們對演算法進行了優化，解決了分散式環境下會出現的 ID 非全域性遞增的情況。
體檢報告實時展現
如何快速發現問題？如何判斷故障影響範圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路效能問題以及實時容量規劃？等等這些問題除了需要一個優質的後端追蹤元件外，還需要一個使用者體驗友好的互動介面。
SaCa ACAP 全鏈路追蹤元件就是一套包含互動介面的完整方案。
應用拓撲追蹤

直觀展現整個應用的服務呼叫關係，服務間呼叫流量，服務部署主機資訊，服務內元件型別，監控整個應用各個服務真實執行情況。
呼叫鏈路追蹤

服務名稱，服務型別等搜尋條件快速定位呼叫鏈路，呼叫鏈路執行狀態一目瞭然。
服務型別追蹤

監控呼叫鏈路中服務裡面各項元件，直觀展現耗時比例。

全面識別監控 10 種類別 35 種元件與框架。
鏈路耗時追蹤

監控呼叫鏈路中服務執行順序，直觀展現各個階段耗時情況，助力效能分析和容量規劃。
鏈路節點追蹤詳情

鏈路中服務執行詳情展示，高效定位關鍵問題。

來源：東軟平臺產品 https://platform.neusoft.com/