【2015年11月28日 51CTO.com快訊】WOT2015"互聯(lián)網(wǎng)＋"時代大數(shù)據(jù)技術(shù)峰會于今日在深圳前海華僑城GW萬豪酒店盛大揭幕，42位業(yè)內(nèi)重量級嘉賓匯聚，重磅解析大數(shù)據(jù)技術(shù)的點睛應(yīng)用。秉承專注技術(shù)、服務(wù)技術(shù)人員的理念，自2012年起WOT大會已成功舉辦七屆，積累了大量技術(shù)專家資源，成為業(yè)界重要的技術(shù)分享交流以及人脈拓展平臺。

本次峰會涵蓋九大技術(shù)主題，分別是：互聯(lián)網(wǎng)金融、O2O電商架構(gòu)、醫(yī)療應(yīng)用、商業(yè)創(chuàng)新、移動大數(shù)據(jù)、技術(shù)創(chuàng)業(yè)、社交網(wǎng)絡(luò)、數(shù)據(jù)安全、廣告數(shù)據(jù)技術(shù)。51CTO作為本次大會主辦方，將通過圖文直播與后期視頻展示，全程跟蹤報道這場技術(shù)盛宴。

下面是聽云技術(shù)副總裁廖雄杰帶來的主題為《大數(shù)據(jù)時代：精益應(yīng)用性能管理》的精彩演講。

[[157462]]

大家好，我是頭一次來深圳和大家做分享，今天是講精益應(yīng)用性能管理，我們會有很多的主機，兩年前不好意思打招呼，覺得我們系統(tǒng)里面，我們的主機數(shù)量，物理主機加上虛擬機還不到一百臺，覺得不好意思好打招呼。過了半年以后，我們物理主機、虛擬機迅速超過了一百多臺，這個在我們的互聯(lián)網(wǎng)很多公司里，這是非常常見的現(xiàn)象，我們運維主機的數(shù)量，很全面在一百臺以上甚至更多。

我們現(xiàn)在面臨一些新的挑戰(zhàn)，特別是大數(shù)據(jù)的領(lǐng)域，我們需要監(jiān)控每一臺主機后臺統(tǒng)籌的指標(biāo)，像CPU、內(nèi)存、網(wǎng)絡(luò)等，除了這些性能，應(yīng)用層要監(jiān)測的指標(biāo)就更多了，簡單的列舉一下，比如說有一些緩存，前端的QPS，應(yīng)用層可能需要和研發(fā)人員做一些運維緊密的配合，需要從應(yīng)用的日志分析一些問題。

大數(shù)據(jù)時代，我們剛才簡單列舉了幾個指標(biāo)，大數(shù)據(jù)的時代，我們的架構(gòu)發(fā)生了一些演進，我們的用戶端會向移動端遷移，遷移最終的效果是什么？我們做運維都會比較頭疼，移動端的數(shù)量，我們的日活可能上千萬，至少成千上萬，我們服務(wù)應(yīng)用的客戶端也是慢慢的提高了發(fā)展，我們的應(yīng)用端也是在往后端的云上轉(zhuǎn)移。

我們的互聯(lián)網(wǎng)領(lǐng)域，產(chǎn)品的迭代速度是非?？斓模覀冊谶@個過程中，我們的監(jiān)控能否跟上我們的產(chǎn)品迭代，我們的開發(fā)需求一直是在變的，我們后端的監(jiān)控是不是能緊隨著我們開發(fā)產(chǎn)品迭代的步伐，我們的技術(shù)架構(gòu)也是越來越復(fù)雜，至少是不斷的在往前演進，在演進的過程中延伸出我們的監(jiān)控能不能跟上我們技術(shù)架構(gòu)的變化。

如何監(jiān)控我們的應(yīng)用系統(tǒng)的性能？我們有很多的主機，成百上千臺主機的基礎(chǔ)指標(biāo)，我們有成熟的監(jiān)控手段，我們的CPU內(nèi)存，我們的監(jiān)控系統(tǒng)里要加一個RDB。我們應(yīng)用以后的架構(gòu)，我們?nèi)绾伪O(jiān)控我們的應(yīng)用，后端有很多的服務(wù)和指標(biāo)，其實都是需要去監(jiān)控的，我們后臺的架構(gòu)可能會有數(shù)據(jù)庫，我們會有NoSQL，我們的架構(gòu)上可能做一些服務(wù)化的治理，我們會有大量的API調(diào)用，大量的API、遠程的調(diào)用，我們的服務(wù)會往云端轉(zhuǎn)移，這個過程中會帶來監(jiān)控的手段和以前有很大的不同，消息隊列是我們架構(gòu)里面比較常見的幾個組件。

    如何在我們的架構(gòu)中對我們的應(yīng)用進行持續(xù)的監(jiān)控？精益化的性能管理的概念，我們做開發(fā)、做管理的同事可能比較熟悉，我們經(jīng)常講，我們是做敏捷開發(fā)，中間可能引入一些精益的流程，或者是敏捷式的流程，我們看其中比較有名的過程控制方法，這也是六西格瑪?shù)倪^程控制里比較重要的概念。

    我們需要對我們的系統(tǒng)進行定義，我們首先要對我們的系統(tǒng)里面每一個指標(biāo)進行度量，這個度量的前提是，要把我們要定義的東西首先全部拆解成一個一個具體的性能指標(biāo)，比如說CDU網(wǎng)絡(luò)，都會有比較成熟的指標(biāo)，我們應(yīng)用這塊是不是有一些標(biāo)準(zhǔn)化的指標(biāo)？我們度量之后就會對我們要做的管理進行分析，指標(biāo)出來我們需要去分析，什么樣的指標(biāo)算是有問題？我們需要有標(biāo)準(zhǔn)化的分析方法。分析完之后需要有一個改善的過程，進行一些控制，不斷改進、控制、度量分析的流程和迭代的持續(xù)演進。

    我們很重要的理念，他沒有更好的概念，我們能不能在下一步做得更好？我們說我們應(yīng)用的性能是可以精確的度量。我們精細化的性能管理里，我們用APM的方式，怎么樣持續(xù)的做數(shù)據(jù)改進和優(yōu)化，監(jiān)控這個東西，剛才說我們的應(yīng)用系統(tǒng)，我們說不太好去監(jiān)控，首先是在我們的應(yīng)用里，需要監(jiān)控的指標(biāo)，首先要精確的度量出來，這是我們遇到的挑戰(zhàn)，不同的應(yīng)用系統(tǒng)是有不同的組件，我們怎么樣把它標(biāo)準(zhǔn)化？通常的方式，被監(jiān)控的技術(shù)組件的IO，從應(yīng)用系統(tǒng)本身進行監(jiān)控，應(yīng)用本身就是我們系統(tǒng)里非常好的監(jiān)控手段，所有后臺的服務(wù)都是通過應(yīng)用去調(diào)用的，我們能不能用我們的應(yīng)用直接在運行的過程中，把監(jiān)控和所有的指標(biāo)都監(jiān)控起來，這個是可行的。

    我們傳統(tǒng)的方法是監(jiān)控基礎(chǔ)的指標(biāo)，CPU、內(nèi)存，監(jiān)控到這些，我們的應(yīng)用哪里出現(xiàn)問題導(dǎo)致這樣的結(jié)果。我們從應(yīng)用層那邊來看，只要給他可以度量的標(biāo)準(zhǔn)，哪里出問題，哪里可以被優(yōu)化的。

[[157463]]

    我們再看一下我們怎么樣做到這一點，從我們的應(yīng)用層去完成自我的性能發(fā)現(xiàn)過程，這個過程我們簡單的用代碼來表示，我們要監(jiān)控這個業(yè)務(wù)方法，比如說這個業(yè)務(wù)的方法叫做XXOO，我們里面有兩個很簡單的業(yè)務(wù)邏輯方法，我們怎么樣監(jiān)控這個業(yè)務(wù)方法和性能？做的方式很簡單，總共分三步：一是在代碼的塊頭插入，代碼掉入執(zhí)行時間打一個標(biāo)注，把這個時間算進來。***一步把這個指標(biāo)上傳到我們的系統(tǒng)里。我們也可以把這個異常信息捕捉起來自動上傳上去，異常通常在我們應(yīng)用優(yōu)化里也是非常重要的關(guān)注點。

    做完這個以后，是不是就比較***了？顯然不是的，我們運維的同學(xué)、開發(fā)的同學(xué)都要提出異議，運維會想說，這個東西必須在我們的業(yè)務(wù)代碼里插入，運維首先是不能接受的，必須讓研發(fā)干這個事情，我們的應(yīng)用、我們的開發(fā)迭代，是不是要嵌入這個代碼，需要規(guī)范的流程確保每個開發(fā)都有這樣的監(jiān)控意識把它管理，標(biāo)準(zhǔn)的代碼放進去，在運維的層面上實施起來是不太可控的。

    我想干的事情就是XXOO，插入和我用戶代碼無關(guān)的代碼。我們有沒有什么辦法，這個過程我們想到這一點，我們發(fā)現(xiàn)問題的話，下一步我們要去改進這個流程，首先我們要去看到代碼是標(biāo)準(zhǔn)的，作為的應(yīng)用都可以數(shù)據(jù)庫調(diào)用，Linuxe調(diào)用也不一樣，我們可以對它調(diào)用的方法進行類似的操作，可以用非常標(biāo)準(zhǔn)的方式監(jiān)控起來，我們能不能用自動化的方式完成這個過程？不需要開發(fā)人員手動的插入代碼，這樣看起來比較手動的代碼。

    拿Java舉一個例子，這個過程對Java是有這樣的機制，其他也有類似的方式實現(xiàn)。我們以Java舉個例子，我們要干的事情是把標(biāo)準(zhǔn)的代碼用一個標(biāo)準(zhǔn)的組件直接插到應(yīng)用里，不需要業(yè)務(wù)的開發(fā)人員手動修改，我們Java里面有一個參數(shù)叫做JavaAgent，有一些做代碼的診斷和運維的同學(xué)做一些類似的事情可能會用agent。實現(xiàn)了方式是他會有每個函數(shù)的入口，啟動一個應(yīng)用服務(wù)器還是我們自己的寫的程序，最終都會用這個方法去啟動除了這個函數(shù)以外，還有一個函數(shù)是Premain函數(shù)，這個函數(shù)我們可以用Instrumentatian動態(tài)加載的時候，我們執(zhí)行的時候是我們JAM所看到的自解碼，我們自己直接改掉就可以了，把那幾行代碼插到程序員寫好的Classloader的代碼里就可以自動實現(xiàn)。

    我們用簡單的代碼給大家看看是怎么體現(xiàn)的，這個是我們原始的業(yè)務(wù)類的方法。怎么具體實現(xiàn)呢？我們用一個比較容易看的方式，做自解碼修改的話，我們要干的事情是把自解碼改掉，這個通常是需要非常了解自解碼，事實上我們有一些第三方的框架是可以提供讓我們以非常高級的方式，跟普通寫代碼的方式一樣去修改他，寫一個普通的業(yè)務(wù)代碼很類似 ，可能會稍微麻煩一些。

    這是一個Agent這個是一個單獨的組件，這個不用修改任何的代碼，我們在這里面，我們舉簡單的例子，我們確實是想監(jiān)控XXOO的方法，讓我們拿到XXOO的方法以后，我們用在標(biāo)框的前面，在他的前面加上一個執(zhí)行的時間，同樣我們在后面插入一個執(zhí)行的時間，我們就可以把執(zhí)行的時間算出來。

    為了看起來比較簡單，我是用了比較簡單的框架，這個是可以用于修改自解碼，還有JavaASM，性能會比Java好很多，他的接口用起來比他更頂層一些，麻煩一些。這樣的代碼插進來以后，配合我們的Java的參數(shù)，我們配合Classloader，我們加入一個參數(shù)，以Agent的方式完成的代碼的注入。運行的結(jié)果就是這樣，XXOO是我們的業(yè)務(wù)代碼產(chǎn)生的輸出，后面就是我們剛才自動插進去的代碼輸出，這個我們把它稍微改一下上傳到我們的監(jiān)控系統(tǒng)里，我們的監(jiān)控系統(tǒng)會監(jiān)控日常、報警，所有的監(jiān)控都可以做出來。

    具體的過程剛才已經(jīng)簡單的介紹過了，首先我們通常實現(xiàn)自動化監(jiān)控的時候，關(guān)鍵點是在剛才的自解碼，在函數(shù)里我們是可以修改自解碼，改完以后再返回給虛擬機，這是我們改過的代碼，他其實看到的是我們改過的自解碼，這個和我們的應(yīng)用，在我們的開發(fā)過程中、應(yīng)用里去寫的效果是一樣的，性能也是一樣的。

    我們需要去監(jiān)控一些我們的系統(tǒng)里面對于web的頂替，我們會從它的請求到響應(yīng)，他的響應(yīng)時間是我們最關(guān)心的，這是用戶直接感受到的時間，這個時間背后是可以分解，按他的組件去分解，在這個過程中我們和調(diào)用數(shù)據(jù)庫，可能會調(diào)用各種各樣的東西，任何一個環(huán)節(jié)出現(xiàn)性能問題，最終都可以占到我們響應(yīng)時間的結(jié)果，這些組件都可以監(jiān)控起來。

    說到自動化，我們有一個很重要的，剛才是自動的嵌入，很顯然我們是不能對所有的方法做嵌入操作，任何新的東西會影響到系統(tǒng)本身的性能，對所有的代碼干這樣的事情，***的結(jié)果可能是不可預(yù)知的。我們最關(guān)心的是，我們的后臺，我們常用的系統(tǒng)里，我們常用的架構(gòu)里，我們最可能產(chǎn)生性能問題的是數(shù)據(jù)庫，比如說壓力比較大，后臺的數(shù)據(jù)庫任何的指標(biāo)都可能會影響到整個應(yīng)用和調(diào)用的時間。

    比如說一般普通本機執(zhí)行的操作，通常情況下，除非代碼非常糟糕，產(chǎn)生性能問題的幾率，像數(shù)據(jù)庫，還有一個容易產(chǎn)生問題的地方，我們會調(diào)用云端的API，這個過程中，有網(wǎng)絡(luò)的地方，都是一個潛在的風(fēng)險點，MQ也是一樣，掉線的話，大部分都是一些標(biāo)準(zhǔn)的地方。

    再結(jié)合剛才的過程看一下我們對系統(tǒng)能監(jiān)控哪些指標(biāo)，我們監(jiān)控的***要素，我們要把他的應(yīng)用系統(tǒng)里的所有組成部分分解，然后標(biāo)準(zhǔn)指標(biāo)化進行度量，這個里面會監(jiān)控響應(yīng)時間，API調(diào)用，會有外部服務(wù)的時間，API調(diào)用的時間，包括會有一些IDC的調(diào)用，還有數(shù)據(jù)庫的時間，整個組合起來是我們看到應(yīng)用的響應(yīng)時間。

    對于外部應(yīng)用，我們首先要對指標(biāo)進行分解，我們的業(yè)務(wù)請求，訪問到哪個url，這個是我們監(jiān)控用戶所關(guān)心最基本的單元，我們每一個請求，他的響應(yīng)時間是什么樣的，對應(yīng)到后面的響應(yīng)時間，如果發(fā)生什么問題，我們可以關(guān)注他后面問題出在數(shù)據(jù)庫還是出在我們其他的組件上，我們希望看到應(yīng)用方，我發(fā)現(xiàn)現(xiàn)在主機CPU有點高，內(nèi)存有點高，到底是哪個組件出來問題？我們看最基礎(chǔ)的應(yīng)用。

    我們看到一個比較慢的訪問時間，這里有160多秒的請求訪問，剛才說我們希望他到底去哪兒，首先可以看出來到底是哪幾個后端的組件調(diào)用的方法占用系統(tǒng)的絕大部分，在這里，這個圖上體現(xiàn)的是四個階段，他是我們這里面對我們造成***影響的部分。

    剛才嵌碼有一個地方?jīng)]體現(xiàn)出來，每個方法監(jiān)控起來，我們會把調(diào)用數(shù)輸出，我們可以非常清晰的看到，調(diào)用對象是哪個函數(shù)。每個函數(shù)發(fā)現(xiàn)問題，對于開發(fā)人員還不夠，有的時候，有些函數(shù)還要再調(diào)一調(diào)，我們可以做得更直接一點，我們是可以看到，他到底是在每個原文件的每個代碼上的問題，所有的問題都是可能的。

    我們現(xiàn)在在這個圖上看到的是SQL的操作，它的SQL是什么樣的？這個SQL我們可以現(xiàn)場抓出來，也可以對它進行一些其他的操作，比如說在現(xiàn)場的計劃，優(yōu)化細節(jié)可以看到的話，我們優(yōu)化的結(jié)果可以看到是否規(guī)范。

    這個是我們剛才說的比較簡單的方式，后臺可能很多的服務(wù)，可以通過API和其他的服務(wù)框架，做一些應(yīng)用之間的調(diào)用鏈，前端的應(yīng)用發(fā)生問題的時候里有的時候是由于后端的服務(wù)產(chǎn)生的問題導(dǎo)致前端，我們監(jiān)控到前端，如果不監(jiān)控后端還是很麻煩的，后臺提示大家的節(jié)點，排查的時候能不能自動的把后端慢的過程也輸出出來。比如說我們在這個地方看到一個前臺的應(yīng)用情況，我們追蹤進去，發(fā)現(xiàn)后端的某個API調(diào)用是URL，這個我們是希望在這個地方，我們在這個地方自動關(guān)聯(lián)過去的話，我們會看到他剛才這個API調(diào)用是由于后端提供服務(wù)的Sever出現(xiàn)了問題，他的SQL直接抓到，他的響應(yīng)時間很短，問題在于他是執(zhí)行了，在同一個云端他執(zhí)行了1900多次，這個不慢就奇怪了，這個是通過自動嵌碼的方式把前后端可以串聯(lián)起來去幫助我們?nèi)プ隹焖俚姆治?、定位、診斷，基本上可以現(xiàn)場做出來。

    謝謝大家的聆聽和關(guān)注，我們是聽云，這些都是用我們運營的互聯(lián)網(wǎng)公司，謝謝大家。

以上是51CTO.com記者為您從一線帶來的精彩報道。更多精彩內(nèi)容盡在51CTO.com獨家報道，敬請期待！