負載測試是開發后臺基礎架構的重要一環，它不但能夠演示系統在真實需求面前的性能表現，還可以通過模擬用戶與設備行為，在應用程序部署到生產環境前，找出并了解任何可能的系統瓶頸。

但是，專用的測試基礎設施可能非常昂貴且難以維護，且此類設備一般是針對特定性能狀況的一次性投資，初期投資后想要再對負載測試進行擴展就十分困難，還可能限制實驗，從而導致開發團隊的工作效率變低，應用在部署到生產環境前也無法得到充分有效的測試。

解決方案綜述

分布式負載測試采用云計算手段，在各種測試場景中這種方案都很有吸引力。云平臺使得基礎設施平臺的彈性得到高度擴展，想要通過大量模擬可產生流量的客戶端進行應用和服務測試都十分容易。此外，云計算的定價模式與負載測試的彈性特質非常相符。

無需再運行完整的虛擬機實例了，容器提供的輕量級選擇與虛擬客戶端的快速擴展完美匹配。由于其輕量級、易于部署、快速可用并適合單一任務等特質，容器是取代運行測試客戶端的優秀替代方案。

谷歌云平臺是使用容器進行分布式負載測試的極優環境，該平臺使用的谷歌容器引擎（Google Container Engine）以開源容器集群管理器Kubernetes為動力，將容器作為一級對象對其提供支持。使用容器引擎可以快速搭建容器基礎設施，并可用來管理應用部署與資源。

該解決方案演示了使用容器引擎部署分布式負載測試框架的方式。此框架使用多個容器，搭建了一個應用于簡易REST-based API的負載測試通訊。盡管這是用來測試簡單Web應用的，但同樣的模式可用于創建更為復雜的負載測試場景中，比如游戲或物聯網應用中。該方案討論了基于容器負載測試框架的通用架構。請至本文末尾查看 教程，逐步學習樣例框架的構建。

本方案著重通過容器引擎來創建負載測試通訊，被測系統是一個簡單的Web應用，使用了REST的API。借助現有的負載測試框架，塑造出下文中詳細描述到的API互動模型。并在完成被測系統的部署后，運用容器引擎來部署分布式負載測試任務。

被測系統

在軟件測試術語中，被測系統（System Under Test）指的是該測試設計時所針對的待評估系統。在該方案中，被測系統是一個部署到Google App Engine的小型Web應用，該應用通過發布基本REST樣式的端點來捕獲接收的HTTP POST請求（接收數據并不連續）。在真實場景中，Web應用可能會很復雜，并包含大量的附加組件及服務，如caching、messaging和persistence，此方案不考慮這些復雜情況。更多在谷歌云平臺上構建可擴展的Web應用相關信息，請查看 the Building Scalable and Resilient Web Applications方案。

樣例應用的源代碼請見文末教程。

示例workload

許多物聯網的部署中有類似示例應用模型中所使用的后端服務組件——設備首次注冊服務后，開始報告指標或檢測器讀數，并定期重新進行服務的注冊。

下圖展示了一個常見的后端服務組件的交互。

該交互可以用Locust這種基于Python的分布式負載測試工具來建模，Locust可以向多個目標路徑分發請求，比如向/login和/metrics目標路徑分別發送請求；還有很多負載生成軟件包也可根據項目需求選擇使用，包括JMeter、， Gatling和Tsung。

而workload將會取決于上面所說到的交互，在Locust會以一組 task的模型出現。為了盡量模擬真正的客戶端，比如同時有上千個客戶端請求接入的情況，每個Locust task需經過加權。

基于容器的計算

從架構角度來看，部署該分布式負載測試方案有兩個主要的組件：Locust容器image，還有容器編排及管理機制。

Locust的容器image是包含Locust軟件的 Docker image，Dockerfile可以在相關的Github庫中找到（見教程），而Dockerfile使用了基于Python的image，并使用一些腳本文件來啟動Locust服務，執行task。

該方案利用谷歌容器引擎用作容器編排與管理機制。容器引擎是基于開源框架Kubernetes，集合了谷歌多年在容器部署方面運行、編排與管理的經驗。基于容器的計算允許開發人員專注于應用本身，無需將精力浪費在繁瑣的托管環境部署與集成上。容器同時也使得負載測試更為輕便，通過容器整合后的應用可以在多個云環境中運行。容器引擎與Kubernetes引入了針對容器編排與管理的若干概念。

容器集群

一個容器集群包含一組云計算引擎（Compute Engine）實例，為整個應用提供基礎。在容器引擎及Kubernetes的文檔中，這些實例被稱為節點。一個集群包含一個master節點和一到多個worker節點。master節點與worker節點都運行在Kubernetes上，因此容器集群有時也被稱為Kubernetes集群。更多集群相關信息請查看 容器引擎文檔。

Pods

Pod是一組應當被集中部署的緊密耦合容器，一些pod只包含單個容器，例如該案例中，每個Locust容器都運行在自己的pod中。但是通常情況下，pod會包含多個集中執行的容器，例如該案例中，Kubernetes使用了一個包含三個容器的pod提供DNS服務。

在一個容器中， SkyDNS提供DNS服務功能。SkyDNS依賴于一個名叫etcd的鍵值存儲，而它又被封裝在另一個容器中。在pod的第三個容器中， kube2sky擔任了Kubernetes與SkyDNS之間的橋梁。

復制控制器

一個復制控制器確保特定數量的pod“副本”能夠隨時運行。如果數量過多，復制控制器會關掉其中一些；如果數量過少，復制控制器會啟動一些新的。該方案有三個復制控制器：一個確保DNS server的單個pod存續；另一個維持Locust的單個master pod；第三個則保證同時正好有10個Locust的worker pod運行。

服務

特定pod可能會因為各種原因而消失，包括節點失效或因更新維護而主動進行的節點中斷。也就是說，pod的IP地址沒有為其提供可靠的接口。更為有效的辦法是使用該接口的抽象表示，即使底層pod消失，新的pod產生，IP地址發生變化，該抽象表示不會改變。容器引擎服務通過定義一組邏輯pod及訪問相關策略，提供這種類型的抽象接口。在該方案中，有一些代表pod或成組pod的服務。例如，一個服務代表DNS server，另一個代表Locust master pod，還有一個代表那10個worker pod。

下圖展示了master節點與worker節點所包含的內容：

　　部署被測系統

該方案使用谷歌應用引擎來運行被測系統。部署被測系統需注冊可用的谷歌云平臺帳號，以安裝運行谷歌云平臺SDK，之后通過一個命令就可以部署這個樣例Web應用了，所需的源代碼在文末教程中可以找到。

部署負載測試任務

部署負載測試任務，首先需要部署負載測試master，然后是一組10個的負載測試worker。有了這些工作負載測試，就可以根據測試目的來創建大量通訊了，但需要銘記：與外部系統產生過多通訊與拒絕服務攻擊相類似，請務必回顧谷歌云平臺的 服務條款和谷歌云平臺的 使用者協議。

負載測試master

部署的第一個組件就是Locust的master，它是執行負載測試任務的入口。部署時將Locust master部署為只含單個副本的復制控制器，因為我們只需要一個master。一個復制控制器甚至在部署單個pod時都是有效的，因為它能確保高可用性。

復制控制器的配置指定了幾個元素，包括控制器的名字（locust-master）、標簽（name: locust, role: master）、容器所需要發布的端口（Web接口用8089，與worker通訊用5051和5052）。這些信息稍后會被用來配置Locust的worker控制器。下面的信息中包含端口的配置：

...

ports:

- name: locust-master-web

containerPort: 8089

protocol: TCP

- name: locust-master-port-1

containerPort: 5557

protocol: TCP

- name: locust-master-port-2

containerPort: 5558

protocol: TCP

下一步，我們會部署一個Service，以確保發布的端口可以通過hostname訪問其它pod：集群中的端口以及通過描述性端口名稱的referenceable。通過使用服務，即便在master失效，復制控制器又生成了新pod的情況下，我們也可以很容易地找到Locust的worker，并可與master通訊。Locust的master服務也包含在集群層面創建外部轉發規則的指令，提供訪問集群資源的外部通訊能力。注意：還需創建防火墻規則，以提供訪問目標樣例的完整入口。

在部署Locust master之后，就可以通過符合外部轉發規則的公開IP地址來訪問Web接口了。部署Locust worker之后，可開啟模擬器并通過Locust Web接口來查看匯總統計。

負載測試worker

下一步部署的組件是Locust worker，用來執行負載壓力測試。Locust worker是通過能生成10個pod的單個復制控制器來部署的。這些pod分布在Kubernetes的集群中。每個pod通過環境變量來控制重要的配置信息，像是被測系統的hostname和Locust master的hostname。worker的復制控制器配置方式請查看下面的教程。配置包含控制器的名稱、locust-worker、標簽（name: locust, role: worker），還有前面描述的環境變量。下面代碼包含配置的名稱、標簽、副本數：

kind: ReplicationController apiVersion: v1 metadata: name: locust-worker

labels: name: locust role: worker spec: replicas: 10 selector: name: locust

role: worker ...

對于Locust worker來說就無需部署額外服務了，因為worker pod自身不需支持任何入站通訊——它們直接與Locust master pod相連。

下圖展示了Locust master與Locust worker之間的關系。

在復制控制器部署Locust worker之后，就可以返回Locust master的Web接口來查看worker部署數量相應的slave數。

執行負載測試任務

開啟負載測試

Locust的主Web接口允許執行針對被測系統的負載測試任務，見下圖：

開啟時指定模擬的用戶數、用戶應當產生的速率。下一步，點擊Start開始模擬。隨著時間流逝、用戶產生，可以看到統計數據開始按模擬指數進行聚合，像是請求數、每秒請求數，如下圖：

　　停止模擬只需點擊Stop，測試就會終止。完整結果可以下載表格查看。

擴展客戶端

按比例增加模擬用戶會導致Locust worker pod數隨之增長。在Locust的worker控制器中有詳細說明，復制控制器部署10個Locust的worker pod。通過復制控制器增加pod的數量，Kubernetes提供了不需重新部署即可調整控制器大小的能力。例如，通過kubectl命令行工具可以調整worker pod的數量。下面的命令可以將Locust的worker pod數量增加到20：

$ kubectl scale --replicas=20 replicationcontrollers locust-worker

在發出擴容命令后，等待幾分鐘，所有pod在此時間段內完成部署并啟動。所有pod啟動后，回到Locust master的Web接口，重啟負載測試。

資源與成本

這個解決方案使用了四個容器引擎節點，每個都受云計算引擎VM標準n1-standard-1類型的支持。你可以使用谷歌云平臺的定價計算器估算運行容器集群的月開銷。上文提到過，可以按需定制容器集群的大小。定價計算器可以協助你自定義集群特點，借此評估開銷的增減。

下一步

現在可以查看如何使用容器引擎來創建簡單Web應用的負載測試框架了。容器引擎允許你指定建立負載測試框架容器所需的節點數量。容器引擎還允許你將負載測試工作節點合并到pod中，并制定容器引擎運行時想要保持的pod數量。

使用同樣的模式來創建不同環境變量與應用的負載測試框架。例如，使用該模式創建信息系統、數據流管理系統與數據庫系統的負載測試框架。創建新的Locust任務，甚至是不同的負載測試框架。

擴展框架的另一辦法是自定義收集到的指數。例如，你可能想要測量每秒的請求數，或者監聽負載增加后的響應延遲情況，或是查看響應失敗率與錯誤類型。有多種可選的監控方式，包括 谷歌云監控（Google Cloud Monitoring）。