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

yuwp1998發表於2020-11-04

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

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

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

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/

相關文章