當開發者從微服務架構獲得靈活時，觀測整個系統的運作情況成為最大的痛點。在本文，ibm research 展示了如何用 spark 對微服務性能進行分析和統計，由 cloudinsight 工程師編譯整理。
引言
作為一種靈活性極強的構架風格，時下微服務在各種開發項目中日益普及。在這種架構中，應用程式被按照功能分解成一組松耦合的服務，它們通過 rest apis 互相協作。
通過這個設計原則，開發團隊可以快速地不斷疊代各個獨立的微服務。同時，基于這些特性，很多機構可以數倍地提升自己的部署能力。
然而凡事都有兩面性，當開發者從微服務架構獲得靈活時，觀測整個系統的運作情況成為最大的痛點。
内容概要
多個服務工作聯合對使用者請求産生響應。在生産環境中，應用程式執行過程中端到端的視圖對快速診斷并解決性能退化問題至關重要的，而應用中多達數十的微服務(每個還對應數百個執行個體)使得了解這點變得非常困難。
資訊是如何在服務中穿梭流動的?
哪裡是瓶頸點?
如何确定使用者體驗的延遲是由網絡還是調用鍊中的微服務引起?
與此同時，在雲環境下，企業對基于微服務應用的性能分析工具的需求與日俱增，是以我們正在嘗試建構基于平台的實時的性能分析工具，它的性質類似于自動縮放和負載平衡等服務。
通過捕獲和分析應用中微服務的網絡通信，服務按非侵入式的方式進行。
在雲環境中，服務分析需要處理海量來自實時租戶應用的通信追蹤，進一步發現應用程式拓撲結構，跟蹤當服務通過網絡微服務時的單個請求等。由于需要運作批處理和實時分析應用，是以 spark 被采用。
spark 操作分析
圖2所示，這裡設定了一個簡單實驗來描述如何利用 spark 進行操作分析。
整體的環境是一個 openstack 雲，一組基于微服務的應用程式運作在不同租戶的網絡中，還有一個小型spark叢集。
在每個 nova 計算主機上安裝的軟體網絡 tap 來捕獲通過租戶網絡内的網絡資料包。從租戶網絡中捕獲的 wire-data 被投入 kafka bus。
同時，在 spark 應用中編寫連接配接器，擷取 kafka 的包并對其進行實時分析。
是以，spark 應用被編寫試圖來回答下列問題：
對終端使用者的請求響應時，資訊流是如何通過服務的?在 it operational analytics領域，這種分析操作通常被稱為“事務跟蹤”。
在給定時間窗中，應用中各種微服務之間的調用/被調用關系是什麼?
在給定時間口中，應用中各種微服務的響應時間是多少?
根據以上問題，這裡開發了2個 spark應用程式：
實時事務跟蹤的應用程式
批量分析應用來生成應用的通信圖和延遲統計
前者基于 spark 流抽象，後者則是一組由 spark 作業伺服器管理的批處理作業。
跟蹤不同微服務之間的事務(或請求流)需要根據應用程式中不同微服務之間的請求-響應對建立因果關系。為了完全不受限應用程式，這裡将該應用當作一個黑盒。
是以不妨認為應用程式中沒有利用任何全局唯一請求辨別符來跟蹤跨微服務的使用者請求。
為了追蹤上文所提的因果關系，這裡采用了 aguilera 等人在 2003 sosp 論文中提出的一種對黑盒分布式系統進行性能分析的方法，并做細微的修改。
對于同步的網絡服務，論文提出了一種 nesting algorithm，将分布式應用程式表示為一個圖，各條邊代表節點之間的互相作用。
這個 nesting algorithm 會檢查服務之間的調用時間戳，進一步推斷其因果關系。
簡單地說，如果服務 a 調用服務 b，而 a 在傳回響應之前會和服務 c 通信，那麼服務 b 呼叫 c 被認為是由 a 調用 b 引起的。
通過分析一大組消息，這裡可以得到服務間有統計性置信度的調用鍊，并消除可能性較小的選項。論文發表的原始算法旨在離線方式下操作大型的跟蹤集。
這個用例會修改該算法來操作資料包流的移動視窗，并慢慢逐漸完善的拓撲結構推斷。
圖3顯示了事務跟蹤應用中作業的部分工作流程。圖4顯示了在一個租戶應用中的事務跟蹤，由 spark 應用推導。
packet 流到達塊中，以 pcap 格式封裝。
個體流從packet流中提取并按滑動視窗分組，即 dstreams。
在給定的時間視窗内，http請求和請求響應通過對比标準的5個 tuple 提取
srcip
srcport
destip
destport
protocol組成下一個 dstream，然後到nesting algorithm中實作的其餘處理管道(未在圖中顯示)。
事務跟蹤應用輸出結果會存儲到時間序列資料存儲區中(influxdb)。
标準批量分析應用程式
第二個 spark 應用是一個标準批量分析應用程式，在給定的時間視窗産生服務調用圖以及調用延遲統計。應用作為标準批處理作業被送出到 spark 作業伺服器。
如圖5所示，批量分析應用從 influxdb 分離出獨立事務跟蹤，并将每個獨立事務跟蹤轉換為對的清單。
清單被聚內建兩個 rdds:
一個包含頂點清單
另一個為邊清單
頂點清單根據頂點名稱進一步解析。最後，應用程式的調用圖在有向圖中計算，以及圖中每條邊延遲時間的統計資料。
該圖是應用程式時間演變圖的一個執行個體，表示給定時間内的狀态。圖6和7顯示調用圖和租戶應用延遲時間的統計資料，作為該批次的分析作業輸出。
結束語
通過 spark 平台，各種不同類型的分析應用可以同時操作，如利用一個統一的大資料平台進行批量處理、流和圖形處理。
下一步則是研究系統的可擴充性方面，如通過增加主機線性提升資料提取速度，并同時處理成千上萬租戶的應用蹤迹。後續會繼續彙報這方面的進展情況。
作者：數控小v
來源：51cto