以下為譯文
作為一種靈活性極強(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)。如圖1所示，多個(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ù)中穿梭流動(dòng)的?哪里是瓶頸點(diǎn)?如何確定用戶體驗(yàn)的延遲是由網(wǎng)絡(luò)還是調(diào)用鏈中的微服務(wù)引起?
與此同時(shí)，在云環(huán)境下，企業(yè)對基于微服務(wù)應(yīng)用的性能分析工具的需求與日俱增，因此IBM Research正在嘗試構(gòu)建基于平臺的實(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è)請求等。由于需要運(yùn)行批處理和實(shí)時(shí)分析應(yīng)用，所以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)用被編寫試圖來回答下列問題：
1. 對終端用戶的請求響應(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ù)(或請求流)需要根據(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ù)包流的移動(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請求和請求響應(yīng)通過對比標(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é)果會存儲到時(shí)間序列數(shù)據(jù)存儲區(qū)中(InfluxDB)。