那么使用微服務(wù)就一定好么？

全鏈路追蹤！微服務(wù)運(yùn)維人員終于解放了

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

顯然已經(jīng)晚了

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

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

系統(tǒng)中各服務(wù)的運(yùn)行狀態(tài)才會(huì)健康

那么，如何為“微服務(wù)”體檢呢？

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

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

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

在擁有眾多服務(wù)的微服務(wù)應(yīng)用中，如何知道一次請(qǐng)求調(diào)用的是哪條鏈路？當(dāng)請(qǐng)求調(diào)用失敗時(shí)，如何知道是哪個(gè)服務(wù)出現(xiàn)了問題導(dǎo)致調(diào)用失敗？一次請(qǐng)求響應(yīng)時(shí)間長(zhǎng)，到底是哪些服務(wù)耗時(shí)長(zhǎng)的？……

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

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

為微服務(wù)“全身檢查”

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

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

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

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

代碼入侵性

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

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

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

探針的性能消耗

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

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

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

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

分布式追蹤 ID

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

一般來說有下面幾點(diǎn)要素：

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

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

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

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

體檢報(bào)告實(shí)時(shí)展現(xiàn)

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

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

應(yīng)用拓?fù)渥粉?/p>

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

調(diào)用鏈路追蹤

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

服務(wù)類型追蹤

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

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

鏈路耗時(shí)追蹤

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

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

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

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