本文整理自GOPS2016全球運維大會主會場聽云研發(fā)副總裁廖雄杰題為《運籌帷幄“追溯應(yīng)用性能問題根源》的演講。 今天帶來的主題是《追溯應(yīng)用性能問題的根源》，我們先來看一下，在平時的運維研發(fā)過程中，一個復(fù)雜應(yīng)用交付鏈的環(huán)境下我們會在服務(wù)器端部署應(yīng)用，最終用戶端會通過不同的接入方式，比如用瀏覽器去訪問，用手機(jī)打開一個APP去訪問，那時如果你的瀏覽器渲染能力或者APP本身的一些切換能力不足的話，都會對應(yīng)用的性能產(chǎn)生影響。那么在這么復(fù)雜的場景下面，我們怎樣去快速地監(jiān)控，在出現(xiàn)問題后如何快速地追溯問題呢。 我們先簡單看下圖，實際工作中的部署環(huán)境可能比這更復(fù)雜得多。用戶遍布在手機(jī)端瀏覽器端 服務(wù)器本身后端也是有很多的服務(wù)器組成，同時我們可能也會用近兩年比較熱門的微服務(wù)化架構(gòu)，服務(wù)和服務(wù)之間本身也會存在很多復(fù)雜的調(diào)用。在這么復(fù)雜的架構(gòu)下面，出現(xiàn)性能問題時如何去快速地發(fā)現(xiàn)和進(jìn)行追溯，這是一個值得關(guān)注的問題。在我們的日常運維過程中，經(jīng)常也會碰到這一問題，剛才蕭老師也說到運維經(jīng)常用“背鍋俠“這個詞語，這個詞聽起來心里還挺不是滋味的，但實際上這也是運維人員的現(xiàn)狀。用戶遇到問題的時候打電話來投訴，一般情況下首先找的也是運維，這沒有辦法，因為出現(xiàn)問題我們總是需要一個入口把這個問題去說出來。 那么在不同的架構(gòu)下如何追溯?先從App端到Server端說起看下性能問題如何追溯。我們知道APP端距離服務(wù)器端很遠(yuǎn)，運維人員通常出現(xiàn)問題的時候很難去接觸到用戶那一端。當(dāng)用戶端出現(xiàn)問題時就比較麻煩了，而實現(xiàn)追溯問題的方式就是我們可以在App那一端通過嵌碼的方式在開發(fā)階段攔截它的請求和響應(yīng)，因為APP經(jīng)常是在網(wǎng)絡(luò)請求，以及跟網(wǎng)絡(luò)、服務(wù)器端進(jìn)行API交互的時候出現(xiàn)問題。這個時候通過攔截請求和響應(yīng)，把服務(wù)器端的響應(yīng)時間注入到自定義HTTP頭里面，這樣監(jiān)控時就可以與Server端進(jìn)行透明交互。我們拿到這些監(jiān)控數(shù)據(jù)，就可以快速地定義一些問題。 從App端的監(jiān)控數(shù)據(jù)里面看到了首包時間在某個點出現(xiàn)了高峰，首包時間我們通常是會覺得服務(wù)器端在響應(yīng)時出現(xiàn)了問題，出現(xiàn)了一些復(fù)雜的調(diào)用。這在用戶端呈現(xiàn)出的就是響應(yīng)慢，甚至出現(xiàn)了卡頓，這個時候我們通過一些打點的方式把APP客戶端的數(shù)據(jù)和服務(wù)器端的數(shù)據(jù)關(guān)聯(lián)起來進(jìn)行分析。這是我們看到一次App端慢響應(yīng)的時候。 從圖中看到一個3秒多的請求，我們通過一些打點的方式將服務(wù)器端的數(shù)據(jù)關(guān)聯(lián)起來。看一下后端在干什么事情，發(fā)現(xiàn)由于后端有一個請求，其響應(yīng)時間有兩秒多。再深入地去看一下服務(wù)器端，然后點Next看一下詳細(xì)的情況，發(fā)現(xiàn)這個方法用掉了整個服務(wù)器調(diào)用時間的90%。 而從這些信息看并不能實際地分析出來它到底是什么問題，但是我們可以在下圖看出來，這一次請求調(diào)用有55次，總響應(yīng)時間有2秒多鐘 開發(fā)人員根據(jù)這一現(xiàn)狀很快地分析出來，根因是Filterlterator的方法出現(xiàn)了問題，這樣開發(fā)人員可以快速定位追溯這個問題。 同樣這樣的監(jiān)控方式也可以應(yīng)用到其他端。APP端相對來說比較復(fù)雜一點，我們要把監(jiān)控的數(shù)據(jù)通過打點的方式嵌入進(jìn)去有點難度，但是對于Browser瀏覽器端相對比App要簡單一些。說到Browser端我們首先想到通過JS，很多網(wǎng)站都有通過JS的注入做一些事情，比如說做廣告的分析，做點擊量用戶行為的分析。同樣這樣的一個手段也可以做性能分析，包括可以從瀏覽器端到服務(wù)器整個后端，對整個數(shù)據(jù)庫整個過程去做追蹤。下面分享一下怎樣從Browser端到Server端怎樣追蹤性能問題。 追蹤實現(xiàn)的方式都是大同小異，只是在不同的技術(shù)手，里面采取的方式會不太一樣。在Browser端是有兩個方式，一個是對主頁面，主頁面是直接的JSP請求，這個請求沒有辦法篡改，這時能做的就是在服務(wù)器端攔截服務(wù)器端JSP/PHP編譯過程。攔截的話，每一次請求就可以將服務(wù)器端的響應(yīng)時間攔截下來，采集出來通過直接注入到JSP的頁面里面，代碼也好或者是其他的過程也好只要攔截過程就可以注入進(jìn)去。 還有像經(jīng)常會有一步請求，Ajax的請求很多時候就不通過這樣的方式了，對Ajax采取另外一個方式，在瀏覽器里面Ajax的請求是大部分通過XmlHttpRequest的對象去實現(xiàn)的，這個對象可以對它進(jìn)行攔截，任何方法都是可以替換的，這樣把它發(fā)出請求的方法攔截下來，把我們要的直接向剛才App端一樣，把響應(yīng)時間通過自定義Request和Resp頭傳輸。 這個追蹤數(shù)據(jù)傳輸過去以后，我們就可以看到運維最關(guān)心的圖，就是不同的數(shù)據(jù)連接、跳轉(zhuǎn)、追蹤的事情。這里面跟剛才差不多，我們看到的是Blooth的響應(yīng)時間，也看到服務(wù)器的響應(yīng)時間，我們是可以把它的服務(wù)器端的響應(yīng)時間進(jìn)行關(guān)聯(lián)。關(guān)聯(lián)起來如果有問題的話，實際上是可以很快地分析出來到底是瀏覽器前端的問題，還是服務(wù)器端后端的問題，包括一些網(wǎng)絡(luò)端的問題，通過不同的指標(biāo)都可以很快速地分辨出來。 剛才介紹的都是兩個終端的情況，對運維來說更加關(guān)注的是服務(wù)器端不同的服務(wù)之間發(fā)生問題時，怎樣去進(jìn)行追蹤。當(dāng)某一端服務(wù)發(fā)生問題影響到前端。我們可以快速地發(fā)現(xiàn)到底是哪個服務(wù)出現(xiàn)了問題，這也是我們需要去監(jiān)控的時候需要下比較多功夫的地方。我們說要把服務(wù)改成微服務(wù)架構(gòu)，一個很重要的問題是監(jiān)控如何去做，這其實是微服務(wù)架構(gòu)下與開發(fā)同等重要的問題。具體的做法與前面提到的差不多，如果是HTTP，就是去攔截HTTP Req/Resp，通過自定義HTTP頭實現(xiàn)跟蹤，而且通過HTTP頭傳輸是最安全的，對應(yīng)用基本是透明的，也不會對應(yīng)用造成干擾。 如果API的框架是其他的框架，這要根據(jù)每個不同的框架底層具體權(quán)利看，Dobbo是可以通過Attachment對象傳輸前后端追蹤數(shù)據(jù)，這個對象也是Dubbo進(jìn)行上下調(diào)用的時候，可以隨著遠(yuǎn)程的IDC請求傳到后端的，每一次請求可以將這個對象關(guān)聯(lián)起來。這個對象作為附加對象與調(diào)用的其他參數(shù)不會發(fā)生混淆，這樣我們把前后端的數(shù)據(jù)從前端傳到后端，后端傳到前端都是有可能的。Thrift也是其他的方式，如果是其他的框架要研究一下底層是怎樣傳輸?shù)摹２还茉鯓樱诵牡狞c是我們做監(jiān)控時這個自定義的數(shù)據(jù)是絕對不能夠影響業(yè)務(wù)的核心協(xié)議數(shù)據(jù)的，這樣盡量通過找HTTP頭，Attachment這一附加對象來實現(xiàn)，這樣對應(yīng)用比較安全一點。 采集到這一追蹤數(shù)據(jù)，就可以從一個服務(wù)追蹤到另外一個服務(wù)，這樣的話就成為了一種可能。像這個案例里面 它前后端是通過消息的組件來進(jìn)行傳輸。這樣的話就可以從它前端Service到后端Service，前端出現(xiàn)了狀況看后端發(fā)生了什么問題。這里面發(fā)現(xiàn)是在后端的Gateway面是有一個調(diào)用的時間比較長，這樣就可以達(dá)到快速追蹤的目的。有了追蹤的數(shù)據(jù)，也可以將應(yīng)有服務(wù)，不同的應(yīng)用服務(wù)之間的拓?fù)浣Y(jié)構(gòu)調(diào)出來。 這樣可以很快地發(fā)現(xiàn)調(diào)用過程中哪個環(huán)節(jié)是有問題的。

« 巨額融資的共享單車 未來發(fā)展難在哪兒？ | 辦公租賃O2O勢頭火熱 “樂辦網(wǎng)”的策略是聚焦經(jīng)紀(jì)人團(tuán)隊 »