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

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

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

[[157462]]

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

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

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

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

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

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

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

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

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

[[157463]]

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

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

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

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

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

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

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

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

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

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

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

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

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

    我們看到一個比較慢的訪問時間，這里有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)化的結果可以看到是否規(guī)范。

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

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

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