雷 擎

(對(duì)外經(jīng)濟(jì)貿(mào)易大學(xué)信息學(xué)院，北京 100029)

1 引言

隨著云計(jì)算的發(fā)展，微服務(wù)架構(gòu)的優(yōu)勢(shì)使其逐漸成為云服務(wù)提供商普遍采用的軟件體系結(jié)構(gòu)。微服務(wù)對(duì)其構(gòu)成的云應(yīng)用程序進(jìn)行的細(xì)粒度控制，縮短了將新功能投入運(yùn)營(yíng)的時(shí)間，已被諸如Facebook、LinkedIn和Amazon之類的大型Web公司廣泛使用。微服務(wù)通過基于虛擬機(jī)VM或基于容器虛擬化的基礎(chǔ)架構(gòu)技術(shù)，可以提供高度的可伸縮性、可用性和可移植性。但是，由于基于微服務(wù)的部署更具動(dòng)態(tài)性和易變性，架構(gòu)和部署方式不同于傳統(tǒng)應(yīng)用程序，也給系統(tǒng)監(jiān)測(cè)和性能建模帶來了新的挑戰(zhàn)。

與傳統(tǒng)軟件架構(gòu)相比，微服務(wù)具有更高的發(fā)布頻率和速度，在運(yùn)營(yíng)環(huán)境中進(jìn)行廣泛性能測(cè)試的可行性受到限制，所以基于單體服務(wù)器的性能評(píng)估和傳統(tǒng)軟件測(cè)試的性能評(píng)估都不完全適合于微服務(wù)[1]。通過對(duì)微服務(wù)和云測(cè)試領(lǐng)域已發(fā)表的論文研究發(fā)現(xiàn)，學(xué)者們研究的成果集中在云應(yīng)用程序建模、構(gòu)建和服務(wù)方面，對(duì)云服務(wù)性能測(cè)試研究較少，大多數(shù)與微服務(wù)的性能測(cè)試沒有直接關(guān)系。對(duì)于微服務(wù)性能測(cè)試方面的研究，包括測(cè)試方法、測(cè)試工具、基準(zhǔn)測(cè)試以及評(píng)價(jià)標(biāo)準(zhǔn)和機(jī)制都還處于探索階段。

針對(duì)微服務(wù)的服務(wù)特性，本文借鑒Web服務(wù)質(zhì)量的測(cè)試方法和評(píng)價(jià)標(biāo)準(zhǔn)，基于Kubernetes平臺(tái)對(duì)微服務(wù)的虛擬化平臺(tái)和架構(gòu)性能進(jìn)行測(cè)試研究。在實(shí)驗(yàn)過程中采用了新的仿真工具Kubemark，通過Kubemark在Kubernets上部署集群，使用從運(yùn)營(yíng)數(shù)據(jù)中提取出的負(fù)載模型加載仿真負(fù)荷，測(cè)試不斷增加的負(fù)載或突然的負(fù)載峰值是否可能會(huì)違反Kubernetes的服務(wù)級(jí)別目標(biāo)SLO(Service Level Objectives)，測(cè)試不同類型的微服務(wù)負(fù)載會(huì)對(duì)系統(tǒng)資源產(chǎn)生的性能影響，是對(duì)微服務(wù)性能測(cè)試方法、工具和評(píng)價(jià)標(biāo)準(zhǔn)的一種嘗試和探索。

2 背景和相關(guān)工作

2.1 國(guó)內(nèi)外研究現(xiàn)狀

通過對(duì)國(guó)內(nèi)外微服務(wù)研究領(lǐng)域的研究成果進(jìn)行對(duì)比，本文發(fā)現(xiàn)雖然有一些學(xué)者對(duì)于微服務(wù)安全性、可用性和系統(tǒng)性能進(jìn)行了研究，但研究的重點(diǎn)主要集中在體系結(jié)構(gòu)方面[2]。

國(guó)外的學(xué)者對(duì)于微服務(wù)性能方面的研究主要從2個(gè)角度展開：一是從集群硬件平臺(tái)角度，在微服務(wù)體系結(jié)構(gòu)下，分別直接加載CPU的基準(zhǔn)測(cè)試、網(wǎng)絡(luò)性能基準(zhǔn)測(cè)試，收集CPU利用率、內(nèi)存訪問延遲、網(wǎng)絡(luò)帶寬和延遲以及存儲(chǔ)開銷等數(shù)據(jù)，使用硬件的性能指標(biāo)來衡量微服務(wù)平臺(tái)的性能[3,4]；另一方面是基于AWS Lambda、Microsoft Azure等商業(yè)的云平臺(tái)，通過API加載負(fù)荷，測(cè)試虛擬機(jī)和容器的啟動(dòng)運(yùn)行時(shí)間、狀態(tài)轉(zhuǎn)換、負(fù)載能力等來評(píng)估不同微服務(wù)架構(gòu)的虛擬平臺(tái)性能[5,6]。另外，有一些學(xué)者在云計(jì)算的虛擬化技術(shù)之間的性能比較領(lǐng)域做了大量工作，例如對(duì)于同樣的基準(zhǔn)測(cè)試，測(cè)試KVM、Docker、LXC和CoreOs Rocket等對(duì)于系統(tǒng)硬件性能的差異[7]。這些研究成果也可以從側(cè)面反映采用不同虛擬化技術(shù)的系統(tǒng)中，微服務(wù)可能呈現(xiàn)的性能。

國(guó)內(nèi)的學(xué)者對(duì)于微服務(wù)的研究主要集中在應(yīng)用方面，對(duì)于云平臺(tái)性能的研究在2015年已經(jīng)有學(xué)者涉及[8]，在輕量虛擬化技術(shù)之間的性能對(duì)比，以及虛擬機(jī)和容器技術(shù)的性能方面，國(guó)內(nèi)學(xué)者已經(jīng)開始有所關(guān)注[9 - 11]。但是，有關(guān)這些問題研究的方法、深度和熱度，與國(guó)外的研究相比還有很大的距離。有關(guān)微服務(wù)性能和測(cè)試方面的研究，也還沒有搜索到相關(guān)的學(xué)術(shù)論文。

從國(guó)內(nèi)外的研究來看，目前微服務(wù)性能測(cè)試的研究與用戶所獲得服務(wù)的性能和質(zhì)量都沒有直接關(guān)系，也缺少基于Kubernetes平臺(tái)的性能研究。由于在微服務(wù)架構(gòu)中，每個(gè)微服務(wù)都實(shí)現(xiàn)自己的功能，并通過與語言和平臺(tái)無關(guān)的API與其他微服務(wù)進(jìn)行通信，微服務(wù)的資源使用量取決于所實(shí)現(xiàn)的功能和工作負(fù)載，因此本文借鑒Web服務(wù)性能評(píng)估方法，直接測(cè)試微服務(wù)的吞吐量、請(qǐng)求成功率、響應(yīng)時(shí)間分布等性能指標(biāo)來進(jìn)行微服務(wù)系統(tǒng)性能評(píng)估，是一個(gè)有意義的嘗試。

2.2 Kubertnetes體系結(jié)構(gòu)

云計(jì)算的2個(gè)關(guān)鍵技術(shù)——資源管理中的隔離技術(shù)和控制技術(shù)，是云計(jì)算根據(jù)消費(fèi)者需求動(dòng)態(tài)分配和重新分配不同的物理和虛擬資源的基礎(chǔ)，從而能夠?qū)崿F(xiàn)云計(jì)算的多負(fù)載、高并行管理和運(yùn)行。資源隔離是指一項(xiàng)工作負(fù)載的執(zhí)行不能影響同一系統(tǒng)上另一工作負(fù)載的執(zhí)行要求。資源控制是指將工作負(fù)載限制為一組特定資源的能力。目前云資源管理主要基于2種技術(shù)：虛擬機(jī)和容器。研究人員發(fā)現(xiàn)，基于以Docker為代表的容器化帶來的開銷更少，與基于虛擬機(jī)管理程序的云相比，具有更好的資源控制能力，可以獲得更好的應(yīng)用程序性能。但是，微服務(wù)使用容器技術(shù)以Docker模式進(jìn)行部署，隔離性也相對(duì)較差，如果需要很高的安全性，就必須通過犧牲純?nèi)萜鞑渴鸬男阅軄慝@得更多可靠的隔離。

Kubernetes是一個(gè)開源的容器編排系統(tǒng)，基本工作單元稱為Pod。每一個(gè)Pod都擁有其自己的唯一IP地址，可以與集群中的任何其他Pod相互訪問。Kubernetes將一個(gè)或多個(gè)容器部署在Pod中，在靈活性和隔離性上有更多的優(yōu)勢(shì)[12]。

Kubernetes高層架構(gòu)由控制組件和監(jiān)測(cè)組件組成。 控制組件保持整個(gè)系統(tǒng)功能一致性，監(jiān)測(cè)組件負(fù)責(zé)計(jì)算系統(tǒng)資源的使用情況，收集指標(biāo)，監(jiān)視整個(gè)系統(tǒng)的運(yùn)行狀況，如圖1所示。

Figure 1 Kubernetes architecture圖1 Kubernetes體系機(jī)構(gòu)

(1)控制組件。

控制組件主要包含7個(gè)組件。其中Apiserver是Kubernetes控制平面的前端，即主服務(wù)器上提供Kubernetes API服務(wù)的組件。 Kubectl提供針對(duì)Kubernetes集群運(yùn)行命令的命令行界面。 etcd實(shí)現(xiàn)一致且高度可用的鍵值存儲(chǔ)，用作所有集群數(shù)據(jù)的Kubernetes后備存儲(chǔ)。 Scheduler是主服務(wù)器上的組件，用于監(jiān)視未分配節(jié)點(diǎn)的新Pod，并選擇一個(gè)要在其上運(yùn)行的節(jié)點(diǎn)。 Controller-Manager是主機(jī)上的運(yùn)行控制器。 從邏輯上講，每個(gè)控制器是一個(gè)單獨(dú)的進(jìn)程，但是為了降低復(fù)雜性，它們都被編譯為單個(gè)二進(jìn)制文件并在一個(gè)進(jìn)程中運(yùn)行。 Kubelet是集群中每個(gè)節(jié)點(diǎn)上運(yùn)行的代理，管理并確保容器正常運(yùn)行。Kube-Proxy組件通過在主機(jī)上維護(hù)網(wǎng)絡(luò)規(guī)則并執(zhí)行連接轉(zhuǎn)發(fā)來啟用Kubernetes服務(wù)。

(2)監(jiān)測(cè)組件。

監(jiān)測(cè)組件主要包含2個(gè)組件。其中cAdvisor是專門為容器而構(gòu)建的，是開源容器資源使用和性能分析代理，支持Docker容器。在Kubernetes中，cAdvisor已集成到Kubelet二進(jìn)制文件中。cAdvisor會(huì)自動(dòng)發(fā)現(xiàn)計(jì)算機(jī)中的所有容器，并收集CPU、內(nèi)存、文件系統(tǒng)和網(wǎng)絡(luò)使用情況統(tǒng)計(jì)信息。cAdvisor還可以通過分析計(jì)算機(jī)上的“root”容器來提供整個(gè)計(jì)算機(jī)的使用情況。Heapster是Kubernetes 1.0.6及更高版本兼容的性能監(jiān)視和指標(biāo)收集系統(tǒng)，不僅可以收集有關(guān)系統(tǒng)的工作負(fù)載，Pod和容器的性能指標(biāo)，還可以收集群集生成的事件和其他信號(hào)。Heapster完全開源，并且支持多種用于持久存儲(chǔ)數(shù)據(jù)的后端。

2.3 Kubemark體系結(jié)構(gòu)

本文采用Kubemark模擬集群測(cè)試工具來實(shí)現(xiàn)微服務(wù)性能測(cè)試的研究。Kubemark是Kubernetes的一個(gè)獨(dú)立模塊，可以用于構(gòu)建Kubernetes的模擬測(cè)試集群，進(jìn)行Kubernetes上微服務(wù)的性能測(cè)試[13]。

在頂層設(shè)計(jì)上，Kubemark集群由2部分組成(如圖2所示)：一個(gè)真實(shí)的控制節(jié)點(diǎn)(Kubemark Master Node)和由一組“虛擬(Hollow)”節(jié)點(diǎn)構(gòu)成的模擬集群(External Cluster)。其中任何加前綴“虛擬(Hollow)”的組件都是實(shí)際組件對(duì)應(yīng)的模擬組件，內(nèi)部使用其真實(shí)核心代碼實(shí)現(xiàn)。例如Kubelet的對(duì)應(yīng)模擬組件是HollowKubelet。Kubemark使用這些模擬組件創(chuàng)建仿真測(cè)試集群，從而確保了模擬性能測(cè)試程序的可維護(hù)性。模擬集群建立在真實(shí)的Kubernetes集群之上，用每一個(gè)真實(shí)的Pod可以作為模擬集群中一個(gè)工作節(jié)點(diǎn)(HollowNode)，其中運(yùn)行模擬組件HollowKubelet、HollowProxy和HollowNodeProblemDetector。因此，單個(gè)真實(shí)節(jié)點(diǎn)能夠運(yùn)行多套Kubelet和Kube-Proxy程序集來模擬多個(gè)節(jié)點(diǎn)。到Kubernetes v1.6為止，Kubemark可以支持5 000個(gè)節(jié)點(diǎn)的集群規(guī)模。實(shí)際上，Kubernetes所有基準(zhǔn)測(cè)試是基于Kubemark構(gòu)建的模擬集群，而不需要構(gòu)建數(shù)千個(gè)真實(shí)節(jié)點(diǎn)。

Figure 2 Kubemark architecture圖2 Kubemark體系結(jié)構(gòu)

通過Kubemark性能測(cè)試工具，本文可以使用較少的硬件資源構(gòu)建大型的Kubernetes模擬集群，配置模擬集群的應(yīng)用測(cè)試數(shù)據(jù)集，在模擬的Kubernetes集群上運(yùn)行端到端測(cè)試e2e(End-to-End)，獲得集群的性能指標(biāo)。Kubemark集群的測(cè)試數(shù)據(jù)雖然與真實(shí)集群略有不同，但可以代表真實(shí)集群的數(shù)據(jù)。因此，Kubemark可用于直接在真實(shí)集群上運(yùn)行端到端測(cè)試，作為對(duì)真實(shí)集群執(zhí)行性能測(cè)試的方案。

3 測(cè)試設(shè)計(jì)和實(shí)驗(yàn)

3.1 微服務(wù)性能度量指標(biāo)選取

云平臺(tái)的用戶通常通過Internet從Web瀏覽器訪問自己訂制的資源(例如數(shù)據(jù)、軟硬件資源或第三方服務(wù))，并且通過與云服務(wù)提供商所簽定的合同，即服務(wù)級(jí)別協(xié)議SLA(Service-Level Agreement)，來為使用的計(jì)算機(jī)資源和服務(wù)付費(fèi)。SLA規(guī)定了服務(wù)提供商在給定價(jià)格必須提供的服務(wù)質(zhì)量QoS(Quality of Service)，包括服務(wù)時(shí)間段、服務(wù)響應(yīng)時(shí)間和吞吐量等。服務(wù)性能QoS的要求一般體現(xiàn)為服務(wù)響應(yīng)時(shí)間和吞吐量。與吞吐量相比，Web客戶更直接的體驗(yàn)通常是服務(wù)響應(yīng)時(shí)間。例如，點(diǎn)擊一個(gè)鏈接，看到響應(yīng)頁面的時(shí)間的長(zhǎng)短會(huì)讓用戶對(duì)Web服務(wù)的質(zhì)量有更加直觀的感覺。

因此，本文在測(cè)試中對(duì)微服務(wù)的性能進(jìn)行度量的標(biāo)準(zhǔn)采用RFC 2679和IETF RFC5166定義的p百分位數(shù)，也就是在服務(wù)響應(yīng)時(shí)間某界限內(nèi)的服務(wù)請(qǐng)求所占總量的百分比，又稱為百分位數(shù)延遲。這個(gè)標(biāo)準(zhǔn)在服務(wù)和網(wǎng)絡(luò)性能研究中已經(jīng)被研究人員廣泛采用[14,15]。假定fT(t)是響應(yīng)時(shí)間T的概率分布函數(shù)。TD是客戶根據(jù)客戶支付的費(fèi)用請(qǐng)求，并與其服務(wù)提供商達(dá)成一致的期望目標(biāo)響應(yīng)時(shí)間，則保證SLA服務(wù)性能指標(biāo)的公式為：

(1)

其中，客戶在不到TD的時(shí)間得到服務(wù)響應(yīng)的服務(wù)請(qǐng)求，至少占所有請(qǐng)求總數(shù)的γ%，這個(gè)性能指標(biāo)就稱為p百分位數(shù)。通過這個(gè)性能指標(biāo)，客戶可以統(tǒng)計(jì)服務(wù)的QoS是否達(dá)到服務(wù)商承諾的標(biāo)準(zhǔn)；另一方面，服務(wù)商可以通過這個(gè)指標(biāo)進(jìn)行反向計(jì)算，來測(cè)量系統(tǒng)提供各種不同服務(wù)的性能差異，以及整個(gè)系統(tǒng)所提供的總體服務(wù)性能和業(yè)務(wù)可擴(kuò)展尺度。

SLA中具體定義服務(wù)響應(yīng)時(shí)間的是服務(wù)級(jí)別目標(biāo)SLOs，使用Kubernetes定義的服務(wù)性能標(biāo)準(zhǔn)如表1所示。

Table 1 SLOs for service response time

在實(shí)驗(yàn)中，通過Kubemark的監(jiān)測(cè)代理獲取每個(gè)服務(wù)請(qǐng)求所發(fā)出的請(qǐng)求時(shí)間和響應(yīng)資源時(shí)間，然后對(duì)占所有請(qǐng)求總數(shù)分別在50%,90%和99%時(shí)，對(duì)這些服務(wù)請(qǐng)求的響應(yīng)時(shí)間界限進(jìn)行統(tǒng)計(jì)，以此來測(cè)度系統(tǒng)提供各種不同微服務(wù)的性能差異，以及在系統(tǒng)微服務(wù)負(fù)載逐步增加時(shí)，Kubernetes中各種資源響應(yīng)的情況，測(cè)度不同微服務(wù)對(duì)于系統(tǒng)性能的壓力和影響情況。

3.2 測(cè)試實(shí)驗(yàn)設(shè)計(jì)

性能測(cè)試是為了獲得系統(tǒng)在某種特定的條件下(包括特定的負(fù)載條件下)的性能指標(biāo)數(shù)據(jù)。本文測(cè)試方案包括密度測(cè)試(Density Testing)和負(fù)載測(cè)試(Load Testing)。密度測(cè)試是測(cè)試一個(gè)節(jié)點(diǎn)支持不同數(shù)量Pod時(shí)的各項(xiàng)性能指標(biāo)。通過密度測(cè)試，可以選擇單節(jié)點(diǎn)最佳的Pod配置數(shù)量。負(fù)載測(cè)試是在系統(tǒng)上模擬實(shí)際用戶負(fù)載的過程，檢測(cè)微服務(wù)及其系統(tǒng)在正常和高負(fù)載期間的行為。

本文實(shí)驗(yàn)基于Kubernetes，采用集群模擬工具Kubemark作為測(cè)試工具，使用腳本語言創(chuàng)建一個(gè)包含100個(gè)節(jié)點(diǎn)的模擬測(cè)試集群，模擬測(cè)試集群平均節(jié)點(diǎn)密度采用每個(gè)節(jié)點(diǎn)設(shè)置30個(gè)Pods，如表2所示。測(cè)試中，采用端到端測(cè)試策略加載數(shù)據(jù)，測(cè)試Kubernetes通過REST over HTTP提供的系統(tǒng)級(jí)微服務(wù)性能。

Table 2 Simulation cluster configuration

測(cè)試的數(shù)據(jù)根據(jù)端到端腳本設(shè)計(jì)測(cè)試任務(wù)加載，測(cè)試包括POST、PUT、DELETE、PATCH和GET等各種API請(qǐng)求對(duì)系統(tǒng)資源操作時(shí)，Kubernetes所提供的微服務(wù)性能，具體的各種API的請(qǐng)求數(shù)量不定。在測(cè)試時(shí)，針對(duì)每一個(gè)API請(qǐng)求，采集在處理這個(gè)請(qǐng)求時(shí)所使用到的各種系統(tǒng)資源響應(yīng)時(shí)間數(shù)據(jù)。例如，采集Kubernetes平臺(tái)響應(yīng)POST請(qǐng)求所需要的endpoints、pods、nodes等資源信息，獲取其服務(wù)響應(yīng)時(shí)間數(shù)據(jù)。由于各種API請(qǐng)求使用的系統(tǒng)資源有很大部分相同，例如pods、namespaces等，表3中間一列列出了測(cè)試中所有的資源對(duì)象，對(duì)應(yīng)于表3中左邊一列所有的API操作。具體每一種API操作對(duì)于系統(tǒng)資源的使用，在后續(xù)有具體圖表說明。例如，向Kubernetes平臺(tái)POST其定義的資源endpoints，獲取其服務(wù)響應(yīng)時(shí)間數(shù)據(jù)。資源具體的測(cè)試動(dòng)作和所操作的資源對(duì)象如表3所示。

Table 3 Tests tasks and resource objects

在測(cè)試過程中，主要采集API調(diào)用的服務(wù)響應(yīng)延遲和Pod啟動(dòng)時(shí)間數(shù)據(jù)，選取微服務(wù)的關(guān)鍵SLI(Service Level Indicator)服務(wù)請(qǐng)求延遲，獲取指標(biāo)在百分位為50,90和99時(shí)的數(shù)據(jù)值作為測(cè)試結(jié)果數(shù)據(jù)。

3.3 測(cè)試結(jié)果和分析

(1)密度測(cè)試。

本文進(jìn)行的密度測(cè)試是測(cè)試集群Pod創(chuàng)建后進(jìn)行調(diào)度，然后配置到每個(gè)節(jié)點(diǎn)上，最后成功啟動(dòng)所耗費(fèi)的時(shí)間。測(cè)試過程中，每個(gè)節(jié)點(diǎn)將從無到有完成30個(gè)Pods配置啟動(dòng)，對(duì)于模擬測(cè)試集群的100個(gè)節(jié)點(diǎn)，將有3 000個(gè)Pods需要?jiǎng)?chuàng)建、調(diào)度、運(yùn)行并啟動(dòng)。圖3中展示了在測(cè)試過程中50%,90%,99%和100%的Pods成功啟動(dòng)時(shí)所耗費(fèi)的時(shí)間延遲，并通過堆積圖顯示了啟動(dòng)過程中各階段所耗費(fèi)的時(shí)間延遲。通過這個(gè)測(cè)試可以看出，在系統(tǒng)微服務(wù)負(fù)載逐步增加時(shí)，總體上對(duì)微服務(wù)性能的影響，通過Kubernetes中各種資源響應(yīng)的情況(如Pod)可以看出，不同微服務(wù)對(duì)于系統(tǒng)性能的壓力和影響情況，限于篇幅本文只給出了對(duì)于GET和LIST微服務(wù)各種系統(tǒng)資源的響應(yīng)時(shí)間。

Figure 3 Delay of each stage of Pod startup in Density Testing圖3 密度測(cè)試中Pod完成啟動(dòng)的各階段延時(shí)

在完成所有Pods啟動(dòng)過程中，平臺(tái)也同時(shí)模擬用戶發(fā)出微服務(wù)請(qǐng)求，通過DELETE、GET、LIST、PATCH、POST和PUT對(duì)所有的資源進(jìn)行操作。其中對(duì)Pods進(jìn)行操作的各種服務(wù)請(qǐng)求響應(yīng)時(shí)間延遲如圖4所示。圖4中分別給出了50%,90%和99%的請(qǐng)求被成功響應(yīng)的時(shí)間延遲。

Figure 4 Microservice performance for Pod operations in Density Testing圖4 密度測(cè)試中對(duì)Pod操作的微服務(wù)性能

表3中其他資源的操作性能，在測(cè)試中都有相應(yīng)的性能數(shù)據(jù)產(chǎn)生，本文選取了GET和LIST微服務(wù)請(qǐng)求作為示例，分別給出了50%,90%和99%的請(qǐng)求被成功響應(yīng)的時(shí)間延遲，如圖5和圖6所示。圖中的x軸是操作的資源對(duì)象，標(biāo)識(shí)是參照表3的資源對(duì)象縮寫。

Figure 5 Request response delay for GET requests in Density Testing圖5 密度測(cè)試中GET請(qǐng)求的請(qǐng)求響應(yīng)延遲

Figure 6 Request response delay of LIST request in Density Testing圖6 密度測(cè)試中LIST請(qǐng)求的請(qǐng)求響應(yīng)延遲

(2)負(fù)載測(cè)試。

負(fù)載測(cè)試通常是根據(jù)預(yù)期的客戶行為和系統(tǒng)日常狀態(tài)對(duì)系統(tǒng)運(yùn)行時(shí)負(fù)荷、狀態(tài)和用戶服務(wù)請(qǐng)求進(jìn)行建模。負(fù)載測(cè)試中通過向系統(tǒng)加載模擬的負(fù)荷和服務(wù)請(qǐng)求，查驗(yàn)系統(tǒng)中各種資源的使用狀況和響應(yīng)時(shí)間，從而衡量系統(tǒng)的服務(wù)質(zhì)量(QoS)性能，以及確定系統(tǒng)在正常和預(yù)期峰值負(fù)載條件下的行為。一般情況下，在允許軟件系統(tǒng)上線之前，都需要在與生產(chǎn)環(huán)境相同的測(cè)試環(huán)境中進(jìn)行負(fù)載和性能測(cè)試。如果系統(tǒng)或服務(wù)受服務(wù)級(jí)別協(xié)議或SLA約束，則負(fù)載測(cè)試尤為重要。

本文使用Kubemark建立了Kubernetes平臺(tái)日常運(yùn)行模型，通過端到端測(cè)試模式模擬用戶行為加載了對(duì)各種系統(tǒng)資源操作的微服務(wù)請(qǐng)求，具體的操作請(qǐng)求和系統(tǒng)資源如表3所示。在測(cè)試過程中系統(tǒng)提供各種不同微服務(wù)的性能差異，本文實(shí)驗(yàn)收集了DELETE、GET、LIST、PATCH、POST和PUT等對(duì)表3中所有資源進(jìn)行操作服務(wù)請(qǐng)求的相關(guān)數(shù)據(jù)，分析所有這些統(tǒng)計(jì)數(shù)據(jù)并生成負(fù)載測(cè)試報(bào)告，從這些報(bào)告中可以看出各種不同微服務(wù)的性能差異。本節(jié)選取具有代表性的數(shù)據(jù)作為示例進(jìn)行分析，包括資源Pod的各種操作請(qǐng)求的響應(yīng)時(shí)間延遲(如圖7所示)、GET、LIST微服務(wù)請(qǐng)求的響應(yīng)時(shí)間延遲(如圖8和圖9所示)。

Figure 7 Performance of microservice for Pod operations in Load Testing圖7 負(fù)載測(cè)試中對(duì)Pod操作的微服務(wù)性能

從圖7可以看出，在對(duì)Pod的操作提供服務(wù)時(shí)，90%的GET、LIST、PATCH、POST和PUT請(qǐng)求可以在5 000 ms內(nèi)得到響應(yīng)，其中50%的服務(wù)請(qǐng)求得到響應(yīng)的延遲時(shí)間是另40%的一半左右，而剩余的9%請(qǐng)求，需要比90%的請(qǐng)求耗費(fèi)多1～3倍的時(shí)間才能得到響應(yīng)。相比較而言，對(duì)Pod的DELETE操作請(qǐng)求與其他操作的區(qū)別比較明顯，它耗費(fèi)12 000 ms左右才能完成90%的請(qǐng)求響應(yīng)，這比其他操作的多1～2倍的時(shí)間。但總體上說，這些服務(wù)響應(yīng)時(shí)間都遠(yuǎn)遠(yuǎn)小于1 s，符合Kubernetes所定義的SLOs，即99%的API調(diào)用在1 s內(nèi)響應(yīng)。

圖8和圖9分別給出了GET和LIST對(duì)各種資源的操作請(qǐng)求的響應(yīng)時(shí)間，包括成功地響應(yīng)50%,90%和99%請(qǐng)求的時(shí)間延遲。圖中的x軸是操作的資源對(duì)象，標(biāo)識(shí)是參照表3的資源對(duì)象縮寫。其中PATCH、POST和PUT請(qǐng)求呈現(xiàn)的數(shù)據(jù)形態(tài)與圖8的GET相似。

Figure 8 Request response delay for GET request in Load Testing圖8 負(fù)載測(cè)試中GET請(qǐng)求的請(qǐng)求響應(yīng)延遲

Figure 9 Request response delay of LIST request in Load Testing圖9 負(fù)載測(cè)試中LIST請(qǐng)求的請(qǐng)求響應(yīng)延遲

4 結(jié)束語

本文使用集群仿真工具Kubemark創(chuàng)建了100個(gè)節(jié)點(diǎn)Kubernetes集群，選擇端到端(End-to-End)的測(cè)試策略對(duì)Kubernetes所提供的微服務(wù)性能進(jìn)行測(cè)試，并給出了集群微服務(wù)的性能分析。實(shí)驗(yàn)結(jié)果表明，通過模擬真實(shí)平臺(tái)的運(yùn)行狀況，仿真測(cè)試能夠給出集群資源的利用狀態(tài)和對(duì)資源操作的相關(guān)性能指標(biāo)。仿真測(cè)試是云平臺(tái)微服務(wù)性能測(cè)試的有效研究方法。通過仿真測(cè)試可以規(guī)避在真實(shí)云平臺(tái)微服務(wù)性能測(cè)試所面臨的運(yùn)營(yíng)、成本、規(guī)模、安全、測(cè)試數(shù)據(jù)等問題。如果在生產(chǎn)環(huán)境中出現(xiàn)了系統(tǒng)可用性問題，可以通過對(duì)運(yùn)營(yíng)時(shí)的負(fù)載特點(diǎn)進(jìn)行仿真實(shí)驗(yàn)來解決，或者通過仿真實(shí)驗(yàn)來發(fā)現(xiàn)生產(chǎn)環(huán)境中有可能存在的致命問題。