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

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