怎麼實現微服務的實時效能分析?

當開發者從微服務架構獲得敏捷時，觀測整個系統的執行情況成為最大的痛點。在本文，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 平臺，各種不同型別的分析應用可以同時操作，如利用一個統一的大資料平臺進行批量處理、流和圖形處理。

下一步則是研究系統的可擴充套件性方面，如通過增加主機線性提升資料提取速度，並同時處理成千上萬租戶的應用蹤跡。