[[183644]]

目前，國內的APM市場雖未及全球市場的繁盛，也已開始呈現騰飛的態勢，國內出品的APM產品可謂百花齊放。然而自從進入2016年之后，國內的IT從業者們開始紛紛把目光聚集在通過Server端植入探針來獲取數據的后端Server類APM產品上面。從數據獲取的角度來說，這類產品可以更加全面深入地展現業務的性能損耗，幫助企業技術團隊更好地管理業務質量和IT設備質量。但是，現階段國內Server類產品五花八門，想選擇一款最適合自己團隊的產品還應先從APM本身需求來看。

企業為什么需要APM服務?答案很簡單，APM可以幫助企業技術團隊更好的管理業務質量和IT設備質量。那么是不是所有的APM產品都能做到這兩方面呢，以Server端APM產品為例，我們需要從如下幾個方面來分析：

關鍵字：大量服務集群、多層級業務拓撲

首先，你的技術團隊所運維或者運營的Server架構體系是什么規模的呢?是兩三臺服務器，還是數十臺、數百臺甚至上千臺服務器?另外，你的業務拓撲關系是簡單的單線調用關系還是極其復雜的網狀的連環調用拓撲?我想，以目前國內互聯網和APP發展的規模與勢頭，稍具規模的企業，其業務服務的拓撲架構以及后端服務器規模都不會太簡單的。業務被執行時，一條請求就可能需要在各個應用服務器、web服務器、數據庫、NoSQL等服務節點之間反復調用、跳轉，這些節點可能組成一個大的業務集群，此外，我們還通常會在某個節點部署幾臺虛擬機來做負載均衡。因此，你所需要的Server端APM產品就必須支持復雜的邏輯結構和多層級的集群拓撲。當然，你所關注的業務集群不會僅是兩三個，所以你的APM產品還需要支持同時接收并處理大量探針產生的數據。如果能夠支持三個邏輯拓撲層級，并且可以同時處理500個以上探針的數據，應該能夠滿足現階段國內大部分企業的技術團隊了。

關鍵字：多線程、自定義代碼

其次，我們使用Server端APM產品，最主要的目的還是做業務流程分析，找出業務被調用時，時間損耗最嚴重的代碼。因此，若想準確定位出業務的性能損耗瓶頸，就需要探針能擷取到足夠全面的數據。所以這里有兩個因素需要注意：***，APM產品要支持異步線程調用的數據獲取，并能夠將異步線程數據與主線程數據以及業務調用關聯起來。因為在請求調用中，除了主線程的處理之外，很可能還會調用其它服務，從而新開一到多個線程來工作。這些異步線程同主線程一樣在消耗著整個業務的運行時間，且有可能對主線程產生拖累。第二，一定要支持用戶自定義代碼的監測。我們都知道，研發工程師在coding過程中會寫出大量符合自己業務邏輯的自定義函數以便調用，這就會給探針獲取數據造成瓶頸。所以說，支持‘關聯異步線程’與‘自定義代碼’這兩個從使用者角度看來非常關鍵的需求點，正是一部分APM產品功能上相對欠缺的地方。

關鍵字：數據關聯分析

除以上兩點外，Server端APM產品還應在數據分析中突顯出各環節數據的關聯性。已經使用過APM相關產品的朋友會了解，APM平臺中會提供很多不同的分析入口，如：業務過程、數據庫、NoSQL等。使用者從不同的入口進入查看相應層面的數據。但是，在有一些APM平臺中，這些模塊是相互割裂的，使得大家無法對數據進行真正的鉆取分析。更先進的做法是把各個層面的數據全部打通，讓使用者可以對每條業務請求自由的串聯查看。比如：從數據庫入口進入后，可以關聯查看每條錯誤SQL語句都是由哪些請求調用的。這一點對于細化關鍵問題尤為重要，也是我們需要著重關注的。