TOP100summit分享實錄 | 如何構建一套全鏈路的故障追蹤和故障自愈系統？

本文內容節選自由msup主辦的第七屆TOP100summit，三七互娛運維開發負責人童傳江分享的《三七互娛故障追蹤和故障自愈系統》實錄。

分享者童傳江在維行業7年工做經驗，作過網絡管理，作過應用運維，目前專一於運維開發，對於行業所要解決的質量、成本、效率、安全，有完整的交付和實踐經驗，愛好普遍，熱衷於解決疑難問題和分享。

編者按：2018年11月30日-12月3日，第七屆全球軟件案例研究峯會在北京國家會議中心盛大開幕，現場解讀「壹佰案例榜單」。本文爲三七互娛運維開發負責人童傳江老師分享的《三七互娛故障追蹤和故障自愈系統》案例實錄。

在實際運維過程當中，由於業務系統愈來愈複雜，變動愈來愈頻繁，老是存在各類各樣監控未覆蓋或者之前未知的故障發生。如何構建一套全鏈路的故障追蹤和故障自愈系統，成了質量保證部門的剛需，經過行業標準化的PaaS平臺模式和Trace追蹤技術，從而實現整個架構的質量可控。

今天，我將從兩個方面分享故障追蹤的實例，第一方面，關於運維平臺的總體架構，分別從成本、效率和質量三個維度解決的大體方向；第二方面，關於在鏈路追蹤具體的案例實踐。

運維平臺的總體架構

現階段，關於運維平臺有三個大方向的問題須要解決：

第一個是成本，有些公司認爲這個問題不是很是嚴重，但公司發展到必定規模，運維成本對於運維部門來講是一個很是大的挑戰。像服務器、CDN、寬帶的成本能夠佔到營收的百分之幾以上，是一個很大的支出。運維成本核心要解決的是搞清楚具體錢花在哪一個方向，並對這些成本問題進行優化。

第二個是效率，這是運維面臨的主要問題。對於基礎設施的交付、中間件的交付，或是代碼發佈，分解業務需求交付從上到下每個步驟，並讓每一個一個步驟變得更快，這是咱們要解決的第二個問題。

第三個是質量，這個問題很簡單，業務是否正常、用戶體驗是否良好等，若是說有問題，到底哪裏出現問題，這是運維部門要保障的。

那麼，如何解決以上三個問題呢？

從技術方面來看，主要劃分三個模塊，第一個模塊，對基礎設施的交付；第二個模塊，運維開發能力層面；第三個模塊，前端接入層面。

從基礎設施能力方面來看，由於運維的場景不一樣，現有狀況在基礎設施層面交付很是繁雜，有些應用須要裸機，咱們就要直接進行裸機自動化系統完整交付；有些業務須要自動擴容，咱們就要提供IAAS的平臺；在基礎設施方面，操做系統交付能力上有一個「封裝」。將裸機，虛擬化IAAS，容器化IAAS，公有云統一貫上封裝。核心爲提供操做系統能力。

從運維層面來看，第一塊是CMDB，它包括了資產到應用，以及整個關聯關係，全部須要關聯到成本或質量的相關數據都存在CDMB中。第二塊是任務通道，對全部下層交付的系統實現各類各樣的自動化，經過任務通道來執行的，分化細節來看，提供了腳本執行、文件傳輸、配置分發、任務編排、定時調度、以及一套API。第三塊是數據通道，之前的監控數據，日誌數據、APM數據或者像交換機Netflow等各類各樣的數據都在數據通道中。 數據通道的核心是作收集數據、傳輸數據、計算數據、存儲收集、展現數據，數據通道核心在用一套邏輯，提供同一個數據處理能力。第四塊是第三方API，如上圖所示，涉及到各類公有云，微信，DNS等平臺。接入能力層面，主要是提供前端的WEB端，包括移動端app上的封裝，關於API Gateway，咱們現有的實現API網關主要作Web防火牆這樣的應用規則。

如今，咱們來詳細看一下CMDB數據的具體模型。以下圖所示：

CDMB主要分爲兩大塊，第一塊是資源，第二塊是應用。資源是通用的，而應用這一塊是應用分類、應用單體，這裏要注意的是，全部的應用CMDB層面，咱們是將它拆分到具體的PaaS平臺，全部的應用和單體應用跑到中間件上面，而數據是記錄在CDMB中的。若是說一個應用若是須要依賴集羣，則須要Master、VIP各類各樣的屬性。實際上關聯到基礎設施的操做系統的進程上去了，全部運維的數據都是放入CMDB這張表裏面，我若是須要解決成本問題，是能夠依據一條鏈路的，先從業務出發，找到個人資產花費了多少，由於核心的成本在資產上，關於成本問題，咱們能夠經過CMDB將這個數據找出來。

關於效率問題，其實核心是在交付基礎設施、交付中間件、交付代碼作持續集成。經過基礎設施的交付效率提高，中間件交付效率的提高，代碼交付效率的提高，來實現到總體效率提高，全部的數據依舊是放在CMDB這張表裏面。

關於質量問題，咱們的業務依然是運行在中間件上，中間件運行在真實的資源上，在運維層面的上一層或中間一層保證業務的質量。

綜上所述，咱們大體介紹了一個平臺最開始的總體架構，包括CMDB的詳細解釋。接下來，再介紹一下，在這個模型上如何對成本、效率、質量問題如何具體解決？

關於運維成本，CMDB簡化了邏輯關係，固定資產存在帳單，咱們的業務存在收入，並非說一個業務它的運維成本高，就必定有問題。實際上，咱們是按一個收入佔比的，運維成本高，收入也隨着增長。基於以上，咱們能夠很是清晰的獲得一個財務數據，這個財務數據的核心是某一個應用收入了多少錢，它的收入佔比是多少。固然，由於有詳細的關聯數據，依然能夠知道各類各樣的錢花在了什麼地方。

關於提高運維效率的大致方向如何解決？

咱們對整個業務作了抽象，第一塊做爲基礎設施，第二塊是中間件這一層，第三塊是持續交付，真實的業務在最上面。IAAS如何提高需求？咱們在對於IAAS實現交互就像實現雲平臺同樣，操做系統安裝無論作自動系統安裝仍是雲API，其餘的IAAS提供一套統一的API/用戶界面本身申請/本身獲取基礎設施的資源。

關於效率PaaS平臺，在中間件這層，咱們會使用MySQL。在產品集羣把MySQL作成雲化模型的管理模式，主要是在改變思路，之前的業務須要一個MySQL，DBA會給它一個MySQL。但實際在進行雲化模式管理的時候，咱們會將普通的MySQL實現成一個雲化的產品，在業務須要時，它將本身進行申請。全部的自動化可以將一個MySQL集羣實現成雲化模式的話，核心須要的技術能力主要仍是運維能力、開發能力、交付能力、平臺能力。CMDB、數據通道和第三方API，咱們只能使用基礎的運維能力層，可以實現到相似於把普通的MySQL實現雲化，好比，騰訊雲、阿里雲同樣的MySQL集羣，看一下詳細界面，雲化監控或是須要人工接入的都把它雲化成雲平臺模式，提供給業務方塊，自助操做。

在運維效率方面的提高，從IAAS、PaaS層面咱們核心要作的是，雖然如今沒有能力從技術能力、各個組件開發成一個雲化產品，但實際上，咱們在運維能力上能作到在產品層面相似於雲的產品，提高運維的效率。

如今，咱們詳細介紹一下關於運維質量的方面。

關注質量解決的方式主要分爲四大方面，如上圖所示，咱們對於應用依賴的模塊作了抽象化，所以，下面兩塊是通用的；第一塊，保證的是咱們在IAAS層面或是操做系統層面的質量；第二塊，咱們全部業務都是跑在中間件上，雖然中間件是用了通用的開源軟件，抽象化後依然是雲平臺；第三塊，是關於鏈路追蹤，這在下面會詳細解釋；第四塊，是常規的業務自己的監控，好比，遊戲行業有可能會遊戲登陸、註冊、充值。對於IAAS、PaaS層面，主要核心是接入CMDB數據，讓Open-Falcon數據和業務關聯，實現最開始的監控。

鏈路跟蹤技術的實踐

鏈路跟蹤是什麼樣的技術？咱們在質量保證層面分爲四塊，IAAS、PaaS到業務自己再到鏈路跟蹤，這項技術是基於中間層面的。

在微服務時代，任何一個應用完成時都要經過其餘接口共同實現。如上圖所示，若是這裏是一個登陸業務A，用戶來登陸這個業務時，先調用第三方API、D和E、存儲、各自的中間件。用戶A在登陸的流程中，每個細節均可以進行鏈路回放，可以清楚的知道，一個用戶A完整的登陸過程，以及具體細節。由於鏈路跟蹤技術完成的整個細節，業界關於鏈路跟蹤技術有很是多的實踐，但咱們在本身實現時，還有不少的困難。

想要完整的實現一個鏈路跟蹤的基礎，有哪些問題須要解決呢？

第一個，性能。咱們如今是一個用於解決用戶質量的輔助功能，在引入這個功能時，最好不要影響到業務，特別是有些業務對消耗性能很是敏感，引入鏈路跟蹤後，爲了保證用戶質量而影響業務的性能，會不能被接受。第二個，應用無感知。咱們如今引入一個新技術，對於質量保證，須要開發來配合。應用不須要知道跟蹤系統的存在，也不須要開發二次配合接入。第三個，擴展性。業務隨着規模增加，整套鏈路跟蹤系統依然要可以知足對於系統需求的完成。

如今，咱們來詳細分析基於PHP鏈路跟蹤自實現原地。在Java或是其餘語言中，語言自己/社區自己對於鏈路跟蹤技術是比較成熟的，咱們能夠直接拿來用，可是對於PHP技術，已實現的大部分都是侵入式的，侵入式須要開發配合作代碼修改。

在只有維護沒有開發的狀況下，會出現一些老舊的業務，這會致使沒法接入，特別是侵入式，開發團隊比較忙或是不肯意接入你的鏈路跟蹤，那麼，整個跟蹤的實際效果會大打折扣。

上圖左邊是一個常規的PHP代碼，這是Curl函數的實現，右邊是真實的Curl擴展的源代碼，這個擴展最終是一個C函數，咱們想要實現的鏈路跟蹤是訪問函數的時候，可以知道代碼的順序、函數的輸入/輸出以及像調用時間。

基於以上PHP函數的實現以及擴展性基於C語言的實現，咱們能夠實現到什麼？

咱們依然調用了PHP的Curl的函數，這個函數自己對它進行替換，依然訪問C函數，但函數自己對它作了一個替換，請求該函數的時候，是指請求我本身的函數，本身的函數自己會調用原始函數，對原始函數進行返回，通過簡單的封裝後，咱們能拿到Curl任何一個函數的參數；關於函數的返回值，咱們要知道，訪問一串代碼函數，在一串鏈路中，能夠獲取到參數和返回值，在中間插入最終ID。由於參數有請求時間、返回時間，因此基於這樣一個更改實現，就能夠知道擴展函數調用參數、調用返回值、調動時間，咱們能夠對這個參數返回時間進行更改，並植入另外一個ID。對於這些函數作的更改，在PHP代碼中再調用函數時，就能夠像一條鏈路同樣從上到下，把整個鏈路接入。

關於單臺Server，若是跨機器識別，傳輸鏈路ID如何傳輸？

如上圖所示，基於PHP實現大部分都是Web開發的，在HTTP中追蹤一個ID，能夠實現多臺機器之間。假設一樣是一個Login請求，一個請求的傳遞，基於以上的實現，咱們就能夠實現到相似於第一塊，最開始Curl是一個擴展，咱們開啓了新擴展，任何一個PHP語言只須要打開一個新的擴展包，並植入到PHP中就能夠實現鏈路跟蹤了。

實現自己是接入到一個開源軟件，咱們實現的過程當中作了一些更改，更多的是函數支持，那這是什麼意思？最開始講到實現原理的核心是作一個函數替換。咱們會在測試過程當中發現，若是沒有函數，咱們能夠增長更多本身的函數，相似於Curl Post參數抓取，增長了這個功能。咱們基於鏈路跟蹤獲取到數據碼，再進行V2格式進行輸出，最後修復bug。

接下來咱們看一下真實的基於鏈路跟蹤輸出的詳細數據。

上圖所示，左邊是一個常規的PHP代碼，右邊是鏈路輸出的數據，咱們詳細分析一下PHP代碼，這一串鏈路追蹤最終核心截取了一個函數細節，函數的耗時時間、函數的參數，咱們基於最開始的函數替換原理實現到的是，任何一個PHP函數，它在運行時能夠將輸入參數、返回值和調用時間，獲取到這一串代碼整個執行的鏈路。

固然，由於作了數據替換，因此會出現性能損耗，咱們須要經過採樣率規避這個問題，根據實際業務作到一個測試數據。關於以上內容都是做爲單機處理的，那麼，如何實現擴展到幾百臺或幾千臺規模機器？

首先，對PHP作一個擴展，再作函數替換，實現基於Zipkin-V2數據寫入到文件，數據平臺有一個數據日誌，將日誌寫到平臺中。用到Vipkin-V2協議將隔離轉化格式後，再作數據轉換，若是隻是用來查詢，它是很是簡單的Web頁面，HTML的頁面進行重寫插入到平臺裏面。在實現過程當中，有幾個細節須要注意，第一塊Logstash配置，須要作一個重命名操做，第二塊ElasticSearch搜索，通常不進行索引，咱們能夠進行字符串查詢，查詢到指定的API或指定的數據類型鏈路跟蹤。

當加了鏈路跟蹤後，最終解決什麼業務問題？

第一塊是性能統計，咱們經過函數替換能夠知道輸入、輸出的時間，和MySQL、API接口訪問時間。雖然數據能夠在第三方系統查到，但也能夠在MySQL集羣或是本身的系統、API性能分析中查到，若是能查到鏈路跟蹤，這是很是貼合業務的。

第二塊是應用拓撲，如上圖所示，咱們能夠很是清晰的看到，在經過鏈路跟蹤的時候，咱們能夠知道語言目的地，並把拓撲畫出來，若是僅僅只是基於鏈路跟蹤畫拓撲圖，是不適合現實狀況的。

一個8001Web端口，MySQL有50提機器，僅僅基於鏈路跟蹤畫出來的數據圖，50個Web介點鏈接MySQL，在運維層面屬於集羣的概念，但只是鏈路跟蹤的話，畫出來的拓撲圖可能不適合運維層面。MySQL比較簡單，基於鏈路跟蹤的數據看到的ID只是VIP，架構圖對於運維製造，是想了解真實訪問到哪一個集羣了，基於這樣的實現，咱們以前詳細介紹到CMDB，VIP數據和MySQL是有關聯的。關於這兩個數據的結合，能夠很是輕鬆的知道運維的構架圖。

上圖是一個簡化過的兩地三中心的架構，這不是單機Web，只是一個Web集羣。MySQL依然是最開始業務所支持的中間件MySQL集羣，基於鏈路架構圖畫出來，包括應用跟蹤能夠實現到的錯誤故障或耗時，能夠實際的展現到圖表上，這種應用拓撲實際上是真實的反映了現有業務運維架構。

第三塊是鏈路回放，上圖是Login頁面，一個用戶登陸須要完成什麼？全部的程序調用會像鏈路同樣展示出來，例如，調用第三方API、傳入、傳出、消耗時間、鏈接中間件、插入的數據、反饋的數據等。主要核心是作故障定位，例如，基於應用層面，某一個業務登陸發生很是嚴重的降低，咱們在鏈路跟蹤中打開登陸頁面，就能詳細的知道，API沒法提供服務，致使業務故障。總體上關於鏈路，整個質量保證處於中間那一塊，核心是從上到下訪問鏈路，來解決質量的相關問題。

以上內容來自童傳江老師的分享。

聲明：本文是由壹佰案例原創，轉載請聯繫 meixu.feng@msup.com.cn