[[171672]]

當(dāng)開發(fā)者從微服務(wù)架構(gòu)獲得敏捷時，觀測整個系統(tǒng)的運(yùn)行情況成為***的痛點(diǎn)。在本文，IBM Research 展示了如何用 Spark 對微服務(wù)性能進(jìn)行分析和統(tǒng)計，由 Cloudinsight 工程師編譯整理。

引言

作為一種靈活性極強(qiáng)的構(gòu)架風(fēng)格，時下微服務(wù)在各種開發(fā)項目中日益普及。在這種架構(gòu)中，應(yīng)用程序被按照功能分解成一組松耦合的服務(wù)，它們通過 REST APIs 相互協(xié)作。

通過這個設(shè)計原則，開發(fā)團(tuán)隊可以快速地不斷迭代各個獨(dú)立的微服務(wù)。同時，基于這些特性，很多機(jī)構(gòu)可以數(shù)倍地提升自己的部署能力。

然而凡事都有兩面性，當(dāng)開發(fā)者從微服務(wù)架構(gòu)獲得敏捷時，觀測整個系統(tǒng)的運(yùn)行情況成為***的痛點(diǎn)。

內(nèi)容概要

多個服務(wù)工作聯(lián)合對用戶請求產(chǎn)生響應(yīng)。在生產(chǎn)環(huán)境中，應(yīng)用程序執(zhí)行過程中端到端的視圖對快速診斷并解決性能退化問題至關(guān)重要的，而應(yīng)用中多達(dá)數(shù)十的微服務(wù)(每個還對應(yīng)數(shù)百個實例)使得理解這點(diǎn)變得非常困難。

信息是如何在服務(wù)中穿梭流動的?

哪里是瓶頸點(diǎn)?

如何確定用戶體驗的延遲是由網(wǎng)絡(luò)還是調(diào)用鏈中的微服務(wù)引起?

與此同時，在云環(huán)境下，企業(yè)對基于微服務(wù)應(yīng)用的性能分析工具的需求與日俱增，因此我們正在嘗試構(gòu)建基于平臺的實時的性能分析工具，它的性質(zhì)類似于自動縮放和負(fù)載平衡等服務(wù)。

通過捕獲和分析應(yīng)用中微服務(wù)的網(wǎng)絡(luò)通信，服務(wù)按非侵入式的方式進(jìn)行。

在云環(huán)境中，服務(wù)分析需要處理海量來自實時租戶應(yīng)用的通信追蹤，進(jìn)一步發(fā)現(xiàn)應(yīng)用程序拓?fù)浣Y(jié)構(gòu)，跟蹤當(dāng)服務(wù)通過網(wǎng)絡(luò)微服務(wù)時的單個請求等。由于需要運(yùn)行批處理和實時分析應(yīng)用，所以 Spark 被采用。

Spark 操作分析

圖2所示，這里設(shè)置了一個簡單實驗來描述如何利用 Spark 進(jìn)行操作分析。

整體的環(huán)境是一個 OpenStack 云，一組基于微服務(wù)的應(yīng)用程序運(yùn)行在不同租戶的網(wǎng)絡(luò)中，還有一個小型Spark集群。

在每個 Nova 計算主機(jī)上安裝的軟件網(wǎng)絡(luò) tap 來捕獲通過租戶網(wǎng)絡(luò)內(nèi)的網(wǎng)絡(luò)數(shù)據(jù)包。從租戶網(wǎng)絡(luò)中捕獲的 Wire-data 被投入 Kafka bus。

同時，在 Spark 應(yīng)用中編寫連接器，獲取 Kafka 的包并對其進(jìn)行實時分析。

因此，Spark 應(yīng)用被編寫試圖來回答下列問題：

• 對終端用戶的請求響應(yīng)時，信息流是如何通過服務(wù)的?在 IT Operational Analytics領(lǐng)域，這種分析操作通常被稱為“事務(wù)跟蹤”。
• 在給定時間窗中，應(yīng)用中各種微服務(wù)之間的調(diào)用/被調(diào)用關(guān)系是什么?
• 在給定時間口中，應(yīng)用中各種微服務(wù)的響應(yīng)時間是多少?

根據(jù)以上問題，這里開發(fā)了2個 Spark應(yīng)用程序：

• 實時事務(wù)跟蹤的應(yīng)用程序
• 批量分析應(yīng)用來生成應(yīng)用的通信圖和延遲統(tǒng)計
• 前者基于 Spark 流抽象，后者則是一組由 Spark 作業(yè)服務(wù)器管理的批處理作業(yè)。

實時事務(wù)跟蹤的應(yīng)用程序

跟蹤不同微服務(wù)之間的事務(wù)(或請求流)需要根據(jù)應(yīng)用程序中不同微服務(wù)之間的請求-響應(yīng)對創(chuàng)建因果關(guān)系。為了完全不受限應(yīng)用程序，這里將該應(yīng)用當(dāng)作一個黑盒。

因此不妨認(rèn)為應(yīng)用程序中沒有利用任何全局唯一請求標(biāo)識符來跟蹤跨微服務(wù)的用戶請求。

為了追蹤上文所提的因果關(guān)系，這里采用了 Aguilera 等人在 2003 SOSP 論文中提出的一種對黑盒分布式系統(tǒng)進(jìn)行性能分析的方法，并做細(xì)微的修改。

對于同步的網(wǎng)絡(luò)服務(wù)，論文提出了一種 nesting algorithm，將分布式應(yīng)用程序表示為一個圖，各條邊代表節(jié)點(diǎn)之間的相互作用。

這個 nesting algorithm 會檢查服務(wù)之間的調(diào)用時間戳，進(jìn)一步推斷其因果關(guān)系。

簡單地說，如果服務(wù) A 調(diào)用服務(wù) B，而 A 在返回響應(yīng)之前會和服務(wù) C 通信，那么服務(wù) B 呼叫 C 被認(rèn)為是由 A 調(diào)用 B 引起的。

通過分析一大組消息，這里可以得到服務(wù)間有統(tǒng)計性置信度的調(diào)用鏈，并消除可能性較小的選項。論文發(fā)表的原始算法旨在離線方式下操作大型的跟蹤集。

這個用例會修改該算法來操作數(shù)據(jù)包流的移動窗口，并慢慢逐步完善的拓?fù)浣Y(jié)構(gòu)推斷。

圖3顯示了事務(wù)跟蹤應(yīng)用中作業(yè)的部分工作流程。圖4顯示了在一個租戶應(yīng)用中的事務(wù)跟蹤，由 Spark 應(yīng)用推導(dǎo)。

• Packet 流到達(dá)塊中，以 PCAP 格式封裝。
• 個體流從Packet流中提取并按滑動窗口分組，即 dstreams。
• 在給定的時間窗口內(nèi)，HTTP請求和請求響應(yīng)通過對比標(biāo)準(zhǔn)的5個 tuple 提取

srcip

srcport

destip

destport

protocol組成下一個 DStream，然后到nesting algorithm中實現(xiàn)的其余處理管道(未在圖中顯示)。

事務(wù)跟蹤應(yīng)用輸出結(jié)果會存儲到時間序列數(shù)據(jù)存儲區(qū)中(InfluxDB)。

標(biāo)準(zhǔn)批量分析應(yīng)用程序

第二個 Spark 應(yīng)用是一個標(biāo)準(zhǔn)批量分析應(yīng)用程序，在給定的時間窗口產(chǎn)生服務(wù)調(diào)用圖以及調(diào)用延遲統(tǒng)計。應(yīng)用作為標(biāo)準(zhǔn)批處理作業(yè)被提交到 Spark 作業(yè)服務(wù)器。

如圖5所示，批量分析應(yīng)用從 InfluxDB 分離出獨(dú)立事務(wù)跟蹤，并將每個獨(dú)立事務(wù)跟蹤轉(zhuǎn)換為對的列表。

列表被聚集成兩個 RDDS:

一個包含頂點(diǎn)列表

另一個為邊列表

頂點(diǎn)列表根據(jù)頂點(diǎn)名稱進(jìn)一步解析。***，應(yīng)用程序的調(diào)用圖在有向圖中計算，以及圖中每條邊延遲時間的統(tǒng)計數(shù)據(jù)。

該圖是應(yīng)用程序時間演變圖的一個實例，表示給定時間內(nèi)的狀態(tài)。圖6和7顯示調(diào)用圖和租戶應(yīng)用延遲時間的統(tǒng)計數(shù)據(jù)，作為該批次的分析作業(yè)輸出。

結(jié)束語

通過 Spark 平臺，各種不同類型的分析應(yīng)用可以同時操作，如利用一個統(tǒng)一的大數(shù)據(jù)平臺進(jìn)行批量處理、流和圖形處理。

下一步則是研究系統(tǒng)的可擴(kuò)展性方面，如通過增加主機(jī)線性提升數(shù)據(jù)提取速度，并同時處理成千上萬租戶的應(yīng)用蹤跡。后續(xù)會繼續(xù)匯報這方面的進(jìn)展情況。