乙個人身體不舒服才想起沒有定期體檢
顯然已經晚了
微服務架構也是一樣
只有實時監控、定期體檢
系統中各服務的執行狀態才會健康
那麼，如何為「微服務」體檢呢？
全鏈路追蹤 就是微服務的「體檢中心」
微服務的「身體構造」
當我們進行微服務架構開發時，通常會根據業務來劃分微服務，各業務之間通過網路通訊進行呼叫。乙個使用者操作，可能需要很多微服務的協同才能完成。在業務呼叫鏈路上，任何乙個微服務出現問題或者網路超時，都會導致功能失敗。隨著業務越來越多，對於微服務之間的呼叫鏈的分析會越來越複雜。
在擁有眾多服務的微服務應用中，如何知道一次請求呼叫的是哪條鏈路？當請求呼叫失敗時，如何知道是哪個服務出現了問題導致呼叫失敗？一次請求響應時間長，到底是哪些服務耗時長的？……
你可能會說，可以通過檢視每個服務的日誌來分析這些資訊。但是應用的服務有可能部署到了上百個節點上，人工查詢顯然是不現實的。
為了檢視微服務應用在實際執行中各個服務的執行狀態，每次呼叫各個環節執**況，我們需要乙個微服務應用的體檢中心，這就是全鏈路追蹤。
為微服務「全身檢查」
saca acap 在微服務領域積累了大量的技術實踐，打造了一套獨有的全鏈路追蹤元件。
通過服務呼叫日誌我們能夠分析出整個微服務應用的呼叫情況。為了解決服務日誌分散在各個節點上，首先需要將日誌統一進行收集，然後將收集的資料進行過濾彙總，之後對彙總的資料進行鏈路分析，形成鏈路呼叫的資料，最後將資料用友好清晰的方式展現出來，這就是鏈路追蹤的全過程。
你可能會說「這個過程聽起來好像日誌分析系統啊」，沒錯，我們的鏈路追蹤就是基於 elk 日誌分析系統方案實現的。使用 filebeat 收集各個服務的日誌、使用 logstash 完成日誌資料的過濾， elasticsearch 負責日誌的儲存於分析。
我們的 id 生成演算法是基於 twitter 的 snowflake 演算法。
41 位的時間序列，精確到毫秒，可以使用 69 年
10 位的機器標識，最多支援部署 1024 個節點
12 位的序列號，支援每個節點每毫秒產生 4096 個 id 序號，最高位是符號位始終為 0
同時我們對演算法進行了優化，解決了分布式環境下會出現的 id 非全域性遞增的情況。
體檢報告實時展現
如何快速發現問題？如何判斷故障影響範圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路效能問題以及實時容量規劃？等等這些問題除了需要乙個優質的後端追蹤元件外，還需要乙個使用者體驗友好的互動介面。
saca acap 全鏈路追蹤元件就是一套包含互動介面的完整方案。
應用拓撲追蹤
直觀展現整個應用的服務呼叫關係，服務間呼叫流量，服務部署主機資訊，服務內元件型別，監控整個應用各個服務真實運**況。
呼叫鏈路追蹤
服務名稱，服務型別等搜尋條件快速定位呼叫鏈路，呼叫鏈路執行狀態一目了然。
服務型別追蹤
監控呼叫鏈路中服務裡面各項元件，直觀展現耗時比例。
全面識別監控 10 種類別 35 種元件與框架。
鏈路耗時追蹤
監控呼叫鏈路中服務執行順序，直觀展現各個階段耗時情況，助力效能分析和容量規劃。
鏈路節點追蹤詳情
鏈路中服務執行詳情展示，高效定位關鍵問題。
微服務鏈路追蹤原理
在微服務橫行的時代，服務化思維逐漸成為了程式設計師的基本思維模式，但是，由於絕大部分專案只是一味地增加服務，並沒有對其妥善管理，當介面出現問題時，很難從錯綜複雜的服務呼叫網路中找到問題根源，從而錯失了止損的 時機。而鏈路追蹤的出現正是為了解決這種問題，它可以在複雜的服務呼叫中定位問題，還可以在新人加...
微服務的鏈路追蹤概述
微服務架構下的問題 在大型系統的微服務化構建中，乙個系統會被拆分成許多模組。這些模組負責不同的功能，組合成系 統，最終可以提供豐富的功能。在這種架構中，一次請求往往需要涉及到多個服務。網際網路應用構建在 不同的軟體模組集上，這些軟體模組，有可能是由不同的團隊開發 可能使用不同的程式語言來實現 有可能...
微服務鏈路追蹤 微服務的戰爭 選型？分布式鏈路追蹤
在經歷微服務的戰爭 級聯故障和雪崩 的 p0 級別事件後，你小手一攤便葛優躺了。開始進行自我覆盤，想起這次排查經歷，由於現在什麼基礎設施都還沒有，因此在接收到客戶反饋後，你是通過錯誤日誌進行問題檢查的。但在級聯錯誤中，錯誤日誌產生的實在是太多了，不同的服務不同的鏈路幾乎都擠在一起，修復時間都主要用在...