Raft算法：保障分布式系統(tǒng)共識的穩(wěn)健之道
1. 什么是Raft算法？Raft 是英文”Reliable、Replicated、Redundant、And Fault-Tolerant”（“可靠、可復制、可冗余、可容錯”）的首字母縮寫。Raft算法是一種用于在分布式系統(tǒng)
圖片
如果有用戶反饋某個頁面很慢，我們知道這個頁面的請求調(diào)用鏈是 A -----> C -----> B -----> D(圖片有誤)，怎么來定位是由哪個服務引起的問題呢？
更進一步，如果每個服務 Service A,B,C,D 都部署在好幾臺機器上。怎么知道某個請求調(diào)用了服務的具體哪臺機器呢？
圖片
可以明顯看到，由于無法準確定位每個請求經(jīng)過的確切路徑，在微服務這種架構下有以下幾個痛點：
1. 排查問題難度會比較大，解決問題的周期長
2. 特定場景很難再次復用
3.系統(tǒng)性能瓶頸分析同樣也不同意
這就需要一個分布式調(diào)用鏈追蹤系統(tǒng)。
圖片
如果要我們自己實現(xiàn)一個這樣的分布式追蹤系統(tǒng)，該怎么去設計？
首先，我們必須得區(qū)分每個調(diào)用鏈，得給它分配一個全局唯一的 TraceID，并且在調(diào)用鏈上的每次調(diào)用都帶上這個 ID，這樣每個調(diào)用都被關聯(lián)起來了。
圖片
然后，我們得記錄所有調(diào)用的先后次序和父子關系。
假設有以上這樣的調(diào)用鏈，如果我們只記錄了這四個調(diào)用：
A---->B
B---->C
A---->D
D---->E
D---->F
雖然我們知道它屬于一個調(diào)用（TraceID 相同），還是無法畫出完整的調(diào)用拓撲圖。
所以必須得記錄父子關系：
A---->B 是 B---->C 的父調(diào)用
A---->D 是 D---->E 的父調(diào)用
A---->D 還是 D---->F 的父調(diào)用
圖片
微服務是來實現(xiàn)業(yè)務的，肯定不能來干這個監(jiān)控和跟蹤的活兒，那樣對微服務的侵入性就太強了。
所以必須得有一個獨立的組件，在不干擾微服務的情況下，監(jiān)控微服務之間的調(diào)用，把這些 ID 生成， 這個獨立的組件就是 Agent。
Agent 要想施展魔法，需要安裝在每個服務所在的機器上：
圖片
這個魔法師遵循的規(guī)則也非常簡單，以上圖中服務 A 上的 Agent 為例：
當 Agent 監(jiān)測到有人調(diào)用服務 A 時，沒有 ParentSpanID，它意識到這是一次全新的調(diào)用，于是創(chuàng)建新的 TraceID。
當 Agent 察覺到 A 調(diào)用了 B 時，生成 SpanID = 1，并將此 ID 作為 ParentSpanID 傳遞給 B。這樣，當 B 調(diào)用 C 時，B 的 Agent 就能生成此次調(diào)用的 SpanID 為 1.1。
當 Agent 察覺到 A 調(diào)用 D 時，生成 SpanID = 2，并將此 ID 作為 ParentSpanID 傳遞給 D。
4. 在 D 調(diào)用 E 和 F 時，分別生成 SpanID 2.1 和 2.2。
指定微服務中的“RPC 調(diào)用的公用程序”（例如 Dubbo 中的 MonitorFilter.invoke方法）， 然后在運行時，通過動態(tài)修改字節(jié)碼的方式來增強它：
圖片
當服務 A 調(diào)用服務 B 時， Agent 就可以做點兒手腳，修改 header 了：
圖片
Agent 雖然監(jiān)控、生成了足夠多的數(shù)據(jù)，但是單個 Agent 無法獲得全局視圖，我們需要一個全局的收集器來把 Agent 的數(shù)據(jù)收集上來，這樣才能生成全局的調(diào)用鏈。
結構如下圖：
圖片
本文鏈接：http://www.www897cc.com/showinfo-26-46491-0.html聊聊微服務鏈路服務
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
上一篇： 九個免費開源的GIF編輯器
下一篇： 如何回溯解決組合問題和字符串分割
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號