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

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

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

[[157462]]

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

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

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

我們的互聯網領域，產品的迭代速度是非常快的，我們在這個過程中，我們的監控能否跟上我們的產品迭代，我們的開發需求一直是在變的，我們后端的監控是不是能緊隨著我們開發產品迭代的步伐，我們的技術架構也是越來越復雜，至少是不斷的在往前演進，在演進的過程中延伸出我們的監控能不能跟上我們技術架構的變化。

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

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

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

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

    我們傳統的方法是監控基礎的指標，CPU、內存，監控到這些，我們的應用哪里出現問題導致這樣的結果。我們從應用層那邊來看，只要給他可以度量的標準，哪里出問題，哪里可以被優化的。

[[157463]]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    謝謝大家的聆聽和關注，我們是聽云，這些都是用我們運營的互聯網公司，謝謝大家。

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