怎么實(shí)現(xiàn)微服務(wù)的實(shí)時(shí)性能分析?

作者：數(shù)控小V 2016-09-18 23:40:38

當(dāng)開發(fā)者從微服務(wù)架構(gòu)獲得敏捷時(shí)，觀測整個(gè)系統(tǒng)的運(yùn)行情況成為最大的痛點(diǎn)。

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

引言

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

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

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

內(nèi)容概要

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

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

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

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

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

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

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

Spark 操作分析

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

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

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

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

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

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

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

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

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

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

因此不妨認(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)用程序表示為一個(gè)圖，各條邊代表節(jié)點(diǎn)之間的相互作用。

這個(gè) nesting algorithm 會檢查服務(wù)之間的調(diào)用時(shí)間戳，進(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)計(jì)性置信度的調(diào)用鏈，并消除可能性較小的選項(xiàng)。論文發(fā)表的原始算法旨在離線方式下操作大型的跟蹤集。

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

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

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

srcip

srcport

destip

destport

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

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

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

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

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

列表被聚集成兩個(gè) RDDS:

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

另一個(gè)為邊列表

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

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