簡單介紹PHP中的分散式跟踪

摘要：自從實現微服務化後，我們碰到了許多問題。其中最大的問題就是如何排除故障，服務化後的介面通常會依賴多個服務，依賴介面的緩慢會直接影響介面的服務品質。這種依賴導致的緩慢情況在線上很常見，但是並不好排查，究 ...

  自從實現微服務化後，我們碰到了很多問題。其中最大的問題就是如何排除故障，服務化後的介面通常會依賴多個服務，依賴介面的緩慢會直接影響介面的服務品質。

        這種依賴導致的緩慢情況在線上很常見，但是並不好排查，究其原因是線上都是透過日誌進行追蹤的大量的日誌開發人員並不是很直觀，且有的公司開發人員是看不到線上具體執行情況。一般來說線上這些小機率故障代表系統的隱患，當流量增加後這些隱患會被放大甚至直接導致線上大規模故障，為了避免類似的事情我們需要做很多事情，最直觀的就是用分散式追蹤系統去統計分析。

        我們常見到大牛在講線上表現怎麼優化，怎麼提高效能，其實有個重要的還環節他們並沒有提及，他們是如何發現低機率故障？分散式追蹤系統在大型網路公司是很常見，但是中小型公司是沒有技術實力去實現這個系統的。而從我們角度來看即使流量很小但是對於公司仍舊很重要的系統是我們需要強化的，能夠發現問題才能解決問題這是我一直貫徹的宗旨。

        分散式追蹤系統特定的實現是有一定技術難度的，要實現效能的捕捉、日誌寫入、日誌收集整理、日誌傳輸、日誌儲存、日誌索引、日誌即時分析、最後合併展示，要求系統能夠應付大流量系統的衝擊。如每次請求每個介面產生1k的日誌，那麼QPS 2000 的伺服器就會產生2M的日誌，如果是一次請求依賴5個介面那麼就是每秒10M的日誌，當線上業務更複雜流量更大的時候，這個數值還會增加。

        大型網路公司有許多分散式追蹤系統，能夠承受數十億流量，但是對於小公司來說這種架構負擔很大，其中許多環節如依賴分散式訊息系統、分散式儲存、分散式計算，光這幾個至少會使用6台以上伺服器，對於一般小型公司性價比不高。

        這次我們開源的分散式追蹤是有兩款，一款是給中小型網路公司使用的單機版他可以支撐PV 2000w的業務系統（如支付系統）。另外還有一款支援分散式數十億PV的分散式追蹤系統。目前剛開放Fiery單機版（https://github.com/weiboad/fiery）這個版本是針對中小型企業使用而設計的，整個專案就是一個Jar包開箱即用，只要有Java8 runtime即可直接使用，當然系統需要簡單的做一個埋點工作。而C++分散式版本依賴東西較多對運維人員有一定能力要求，後續看單機版情況後續放出。這些完全開源內部有敏感資料的核心交易系統也完全可以使用。

        目前市面上有多個方式的分散式追蹤，有的是公司自己內部使用，有的則是小規模免費大規模付費的服務。常見的分散式追蹤是透過統計方式去記錄每一個Block的效能情況。目前我們提供的方式和市面的方式並不完全一樣，我們透過不斷的實驗做了大量的簡化，只保留我們認為真正實用的功能，我們將系統設計為關鍵系統分散式監控。如支付系統、交易系統。

        我們記錄了每個請求的具體情況、返回值、特定的性能等信息，透過表格分析可以快速的發現線上依賴接口性能（第三方或者未埋點的接口性能統計）、做埋點的介面也獨立做了效能排行分析。透過查看分析表格後我們可以快速的找到最慢的介面請求回放，以此分析線上效能緩慢的原因。透過實踐我們發現很多情況下都是PHP依賴的資料資源緩慢導致了PHP介面效能不佳。所以埋點的重點都是依賴資源。其他資訊使用者可以根據自己需求增加，這樣可以減少大量無用日誌，可以更節儉一些。

        這次開源的Fiery主要有三個部分、PHP侵入式埋點庫、精簡的日誌監控推送模組、服務端。這三個就實現了一個PV2000w以下的網站分散式追蹤。

        埋點庫會在入口產生Traceid（UUID）這個Traceid內隱藏著入口伺服器的IP位址，請求時間，所有後續產生的日誌都會用這個UUID作為標示。在日誌收集後所有相關日誌都會依這個UUID進行儲存。埋點庫會在運行時負責接收其他請求發送的Traceid和發送產生維護RPCID，RPCID是一個有層級的計數器，透過它我們可以將呼叫關係順序及層級直接進行還原展示給開發人員。另外在PHP運作過程中如果產生Exception也會被埋點庫擷取記錄下來，以供服務端進行去重統計。最後會將這些日誌落地到伺服器本地磁碟，由於一些原因多個PHP進程同時寫一個檔案的時候偶爾會出現亂序情況，我們現在是按進程ID加上專案名稱作為檔案名稱進行落地的。

        Fiery日誌抓取傳輸我們實作了一個簡單的版本，這麼做是為了簡化使用維運人員的工作，目前確實有很多開源提供類似的功能、但是需要依賴其他環境，這對於運維來說有一定負擔。我們還有個實驗性的PHP的日誌抓取傳輸服務，但是還是實驗的功能，預計會有一定的缺陷各位用戶可以參與調試改進。

        Fiery的服務端我們做了許多工作，內建了Lucene和Rocksdb，分別對請求進行索引和儲存。並且做了一些內存統計的工作，目前我們的統計維度是固定的，只針對本地接口，依賴接口，Mysql、Curl的響應情況進行統計、另外提供調用關係回放、錯誤日誌警報去重統計。透過這些功能可以快速的發現線上關鍵點的效能故障，系統異常。目前只是單機版，後續需要我可以將它進一步擴展成更簡單的分散式方式。

        以上這些服務並不僅僅服務於線上，目前我們內部還用他做了很多有意思的嘗試，如QA測試的環境接入一套，測試完畢後把故障接口產生的Traceid直接發給開發，開發能夠透過Traceid找到此次請求所有調用經過、參數、返回情況、性能都可以直觀看到方便分析.上線之前的單元測試也可以這麼做。前陣子我發微博推廣Fiery的時候有人還提到可以用它來做蜜罐，查看駭客入侵的過程，具體細節。後續功能還待大家繼續發掘和改進，這個系統就是為了填補PHP生態空缺而做的。

以上是簡單介紹PHP中的分散式跟踪的詳細內容。更多資訊請關注PHP中文網其他相關文章！