作為一種靈活性*的構(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)從微服務(wù)架構(gòu)獲得敏捷時(shí)，觀測(cè)整個(gè)系統(tǒng)的運(yùn)行情況成為zui大的痛點(diǎn)。如圖1所示，多個(gè)服務(wù)工作聯(lián)合對(duì)用戶請(qǐng)求產(chǎn)生響應(yīng);在生產(chǎn)環(huán)境中，應(yīng)用程序執(zhí)行過程中端到端的視圖對(duì)快速診斷并解決性能退化問題至關(guān)重要的，而應(yīng)用中多達(dá)數(shù)十的微服務(wù)(每個(gè)還對(duì)應(yīng)數(shù)百個(gè)實(shí)例)使得理解這點(diǎn)變得非常困難。信息是如何在服務(wù)中穿梭流動(dòng)的?哪里是瓶頸點(diǎn)?如何確定用戶體驗(yàn)的延遲是由網(wǎng)絡(luò)還是調(diào)用鏈中的微服務(wù)引起?

　　與此同時(shí)，在云環(huán)境下，企業(yè)對(duì)基于微服務(wù)應(yīng)用的性能分析工具的需求與日俱增，因此IBM Research正在嘗試構(gòu)建基于平臺(tái)的實(shí)時(shí)的性能分析工具，它的性質(zhì)類似于自動(dòng)縮放和負(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è)請(qǐng)求等。由于需要運(yùn)行批處理和實(shí)時(shí)分析應(yīng)用，所以Spark被采用。

　　圖2所示，這里設(shè)置了一個(gè)簡(jiǎn)單實(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的包并對(duì)其進(jìn)行實(shí)時(shí)分析。

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

　　1. 對(duì)終端用戶的請(qǐng)求響應(yīng)時(shí)，信息流是如何通過服務(wù)的?在IT Operational Analytics領(lǐng)域，這種分析操作通常被稱為“事務(wù)跟蹤”。

　　2. 在給定時(shí)間窗中，應(yīng)用中各種微服務(wù)之間的調(diào)用/被調(diào)用關(guān)系是什么?

　　3. 在給定時(shí)間口中，應(yīng)用中各種微服務(wù)的響應(yīng)時(shí)間是多少?

　　根據(jù)以上問題，這里開發(fā)了2個(gè)Spark應(yīng)用程序：1個(gè)實(shí)時(shí)事務(wù)跟蹤的應(yīng)用程序和1個(gè)批量分析應(yīng)用來生成應(yīng)用的通信圖和延遲統(tǒng)計(jì)。前者基于Spark流抽象，后者則是一組由Spark作業(yè)服務(wù)器管理的批處理作業(yè)。

　　跟蹤不同微服務(wù)之間的事務(wù)(或請(qǐng)求流)需要根據(jù)應(yīng)用程序中不同微服務(wù)之間的請(qǐng)求-響應(yīng)對(duì)創(chuàng)建因果關(guān)系。為了*不受應(yīng)用程序，這里將該應(yīng)用當(dāng)作一個(gè)黑盒。因此不妨認(rèn)為應(yīng)用程序中沒有利用任何全局*請(qǐng)求標(biāo)識(shí)符來跟蹤跨微服務(wù)的用戶請(qǐng)求。

　　為了追蹤上文所提的因果關(guān)系，這里采用了Aguilera等人在2003 SOSP論文中提出的一種對(duì)黑盒分布式系統(tǒng)進(jìn)行性能分析的方法，并做細(xì)微的修改。對(duì)于同步的網(wǎng)絡(luò)服務(wù)，論文提出了一種nesting algorithm，將分布式應(yīng)用程序表示為一個(gè)圖，各條邊代表節(jié)點(diǎn)之間的相互作用。這個(gè)nesting algorithm會(huì)檢查服務(wù)之間的調(diào)用時(shí)間戳，進(jìn)一步推斷其因果關(guān)系。簡(jiǎn)單地說，如果服務(wù)A調(diào)用服務(wù)B，而A在返回響應(yīng)之前會(huì)和服務(wù)C通信，那么服務(wù)B呼叫C被認(rèn)為是由A調(diào)用B引起的。通過分析一大組消息，這里可以得到服務(wù)間有統(tǒng)計(jì)性置信度的調(diào)用鏈，并消除可能性較小的選項(xiàng)。論文發(fā)表的原始算法旨在離線方式下操作大型的跟蹤集。這個(gè)用例會(huì)修改該算法來操作數(shù)據(jù)包流的移動(dòng)窗口，并慢慢逐步完善的拓?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流中提取并按滑動(dòng)窗口分組，即dstreams。在給定的時(shí)間窗口內(nèi)，HTTP請(qǐng)求和請(qǐng)求響應(yīng)通過對(duì)比標(biāo)準(zhǔn)的5個(gè)tuple 提取(src_ip、src_port、dest_ip、dest_port， protocol)，組成下一個(gè)DStream，然后到nesting algorithm中實(shí)現(xiàn)的其余處理管道(未在圖中顯示)。事務(wù)跟蹤應(yīng)用輸出結(jié)果會(huì)存儲(chǔ)到時(shí)間序列數(shù)據(jù)存儲(chǔ)區(qū)中(InfluxDB)。

　　第二個(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)換為<vertex,edge>對(duì)的列表。列表被聚集成兩個(gè)RDDS，一個(gè)包含頂點(diǎn)列表，而另一個(gè)為邊列表。頂點(diǎn)列表根據(jù)頂點(diǎn)名稱進(jìn)一步解析。zui后，應(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è)輸出。

　　通過Spark平臺(tái)，各種不同類型的分析應(yīng)用可以同時(shí)操作，如利用一個(gè)統(tǒng)一的大數(shù)據(jù)平臺(tái)進(jìn)行批量處理、流和圖形處理。下一步則是研究系統(tǒng)的可擴(kuò)展性方面，如通過增加主機(jī)線性提升數(shù)據(jù)提取速度，并同時(shí)處理成千上萬租戶的應(yīng)用蹤跡。后續(xù)會(huì)繼續(xù)匯報(bào)這方面的進(jìn)展情況。