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 生態空缺而做的。
後續還會提供更多的功能,敬請期待……
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
否則很難通過。
(以上系廣告合作內容,請同學們注意甄別內容真偽!)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
點擊展開全文


※有贊的zan framework安裝與使用2
※PHP實現文本快速查找-二分查找法
※swoole2-mysqlpool:基於 Swoole 2 協程特性實現的 MySQL 連接池
※Deployer 5.0.0 發布,PHP 編寫應用部署工具
※symfony中使用NelmioApiDocBundle進行API管理
TAG:PHP技術大全 |
※PHP 第一個PHP程序
※盤點:PHP常用的HTML標籤相關的字元串格式化函數,你知道幾個?
※探索嵌入式PHP與C/C+結合的無限種可能
※使用PHP更新redis失敗一個的問題
※世界上最好的語言PHP:OpenCV與計算機視覺已在我掌控之下
※分享一些PHP面試題目
※世界上最好的語言PHP:我也可以用OpenCV搞計算機視覺
※Python與PHP的對決:誰是工程師最喜歡和最討厭的語言?
※這才是現代PHP該有的樣子
※十周後,62%的PHP網站將運行在一個不受支持的PHP版本上
※幾張圖為你分析HTML、JS與PHP之間的數據傳輸
※PHP程序的JSON
※PHP的純CPU基準測試
※在使用 Go 兩年之後,我又轉回 PHP 了
※PHP PDO fetch 模式各種參數的輸出結果一覽
※一張GIF圖片就能讓伺服器宕機的PHP漏洞
※PHP的文件載入
※用於PHP開發的VS代碼
※PHP-Beast 加密你的PHP源代碼
※PHP 已死?