那么使用微服務就一定好么？

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

一個人身體不舒服才想起沒有定期體檢

顯然已經(jīng)晚了

微服務架構(gòu)也是一樣

只有實時監(jiān)控、定期體檢

系統(tǒng)中各服務的運行狀態(tài)才會健康

那么，如何為“微服務”體檢呢？

全鏈路追蹤 就是微服務的“體檢中心”

微服務的“身體構(gòu)造”

當我們進行微服務架構(gòu)開發(fā)時，通常會根據(jù)業(yè)務來劃分微服務，各業(yè)務之間通過網(wǎng)絡通信進行調(diào)用。一個用戶操作，可能需要很多微服務的協(xié)同才能完成。在業(yè)務調(diào)用鏈路上，任何一個微服務出現(xiàn)問題或者網(wǎng)絡超時，都會導致功能失敗。隨著業(yè)務越來越多，對于微服務之間的調(diào)用鏈的分析會越來越復雜。

在擁有眾多服務的微服務應用中，如何知道一次請求調(diào)用的是哪條鏈路？當請求調(diào)用失敗時，如何知道是哪個服務出現(xiàn)了問題導致調(diào)用失敗？一次請求響應時間長，到底是哪些服務耗時長的？……

你可能會說，可以通過查看每個服務的日志來分析這些信息。但是應用的服務有可能部署到了上百個節(jié)點上，人工查找顯然是不現(xiàn)實的。

為了查看微服務應用在實際運行中各個服務的運行狀態(tài)，每次調(diào)用各個環(huán)節(jié)執(zhí)行情況，我們需要一個微服務應用的體檢中心，這就是全鏈路追蹤。

為微服務“全身檢查”

SaCa ACAP 在微服務領(lǐng)域積累了大量的技術(shù)實踐，打造了一套獨有的全鏈路追蹤組件。

通過服務調(diào)用日志我們能夠分析出整個微服務應用的調(diào)用情況。為了解決服務日志分散在各個節(jié)點上，首先需要將日志統(tǒng)一進行收集，然后將收集的數(shù)據(jù)進行過濾匯總，之后對匯總的數(shù)據(jù)進行鏈路分析，形成鏈路調(diào)用的數(shù)據(jù)，最后將數(shù)據(jù)用友好清晰的方式展現(xiàn)出來，這就是鏈路追蹤的全過程。

你可能會說“這個過程聽起來好像日志分析系統(tǒng)啊”，沒錯，我們的鏈路追蹤就是基于 ELK 日志分析系統(tǒng)方案實現(xiàn)的。使用 Filebeat 收集各個服務的日志、使用 Logstash 完成日志數(shù)據(jù)的過濾， Elasticsearch 負責日志的存儲于分析。

但是不要以為這就是鏈路追蹤的全部，SaCa ACAP 還能解決更多問題。

代碼入侵性

作為支撐業(yè)務組件，應當盡可能少入侵或者無入侵其他業(yè)務系統(tǒng)，對于使用方透明，減少開發(fā)人員的負擔。

對于應用的程序員來說，是不需要知道有追蹤系統(tǒng)這回事的。如果一個追蹤系統(tǒng)想生效，就必須需要依賴應用的開發(fā)者主動配合，那么這個追蹤系統(tǒng)也太脆弱了，往往由于追蹤系統(tǒng)在應用中植入代碼的 bug 或疏忽導致應用出問題，這樣才是無法滿足對追蹤系統(tǒng)“無所不在的部署”這個需求。

為此 SaCa ACAP 采用了應用采用了應用監(jiān)控組件 SkyWalking。它基于 Javaagent 技術(shù)，對代碼無入侵。將應用和探針一起部署，就能實現(xiàn)對服務的監(jiān)控。服務每次調(diào)用都會產(chǎn)生相應的日志信息。

探針的性能消耗

APM 組件服務的影響應該做到足夠小。服務調(diào)用埋點本身會帶來性能損耗，這就需要調(diào)用追蹤的低損耗，在一些高度優(yōu)化過的服務，即使一點點損耗也會很容易察覺到，而且有可能迫使在線服務的部署團隊不得不將追蹤系統(tǒng)關(guān)停。

性能的損耗很大一部分來自于將日志同步寫入到文件當中。同步文件 IO 操作會產(chǎn)生阻塞，造成線程等待和線程上線文切換。

解決辦法就是采用異步方法，異步方法先在堆內(nèi)存中存儲日志，然后批量寫入到文件中。

但是異步寫入會占用一部分用于處理業(yè)務的堆內(nèi)存，為了盡可能的減少對業(yè)務運行的影響，我們首先將日志寫入到堆外內(nèi)存中，然后在寫入到文件中。減少 IO 阻塞的同時也降低了對業(yè)務運行的影響。

分布式追蹤 ID

業(yè)務系統(tǒng)中，涉及到各種各樣的 ID ，如在支付系統(tǒng)中就會有支付 ID 、退款 ID 等。

一般來說有下面幾點要素：

唯一性：確保生成的 ID 是全網(wǎng)唯一的有序遞增性：確保生成的 ID 是對于某個用戶或者業(yè)務是按一定的數(shù)字有序遞增的高可用性：確保任何時候都能正確的生成 ID 帶時間： ID 里面包含時間

我們的 ID 生成算法是基于 Twitter 的 snowflake 算法。

41 位的時間序列，精確到毫秒，可以使用 69 年10 位的機器標識，最多支持部署 1024 個節(jié)點12 位的序列號，支持每個節(jié)點每毫秒產(chǎn)生 4096 個 ID 序號，最高位是符號位始終為 0

同時我們對算法進行了優(yōu)化，解決了分布式環(huán)境下會出現(xiàn)的 ID 非全局遞增的情況。

體檢報告實時展現(xiàn)

如何快速發(fā)現(xiàn)問題？如何判斷故障影響范圍？如何梳理服務依賴以及依賴的合理性？如何分析鏈路性能問題以及實時容量規(guī)劃？等等這些問題除了需要一個優(yōu)質(zhì)的后端追蹤組件外，還需要一個用戶體驗友好的交互界面。

SaCa ACAP 全鏈路追蹤組件就是一套包含交互界面的完整方案。

應用拓撲追蹤

直觀展現(xiàn)整個應用的服務調(diào)用關(guān)系，服務間調(diào)用流量，服務部署主機信息，服務內(nèi)組件類型，監(jiān)控整個應用各個服務真實運行情況。

調(diào)用鏈路追蹤

服務名稱，服務類型等搜索條件快速定位調(diào)用鏈路，調(diào)用鏈路執(zhí)行狀態(tài)一目了然。

服務類型追蹤

監(jiān)控調(diào)用鏈路中服務里面各項組件，直觀展現(xiàn)耗時比例。

全面識別監(jiān)控 10 種類別 35 種組件與框架。

鏈路耗時追蹤

監(jiān)控調(diào)用鏈路中服務執(zhí)行順序，直觀展現(xiàn)各個階段耗時情況，助力性能分析和容量規(guī)劃。

鏈路節(jié)點追蹤詳情

鏈路中服務執(zhí)行詳情展示，高效定位關(guān)鍵問題。

來源：東軟平臺產(chǎn)品 https://platform.neusoft.com/