❶ 如何對API進行負載測試與調優（一）
本文由Donny譯自 3scale.com 的 《How to load test & tune performance on your API》
這幾年API的作用不斷演化，以前API還只是用來做內部系統之間的集成點，但現在API已成為一個公司的核心系統，一個構建於Web和移動端應用之上的核心系統。
當API僅只用來處理後台的任務（例如生成報告），那麼性能差點也不是問題。但是如今API慢慢地發展成為連接服務與終端用戶的核心紐帶。這種關鍵性的角色變化表明了一個重要的觀點：那就是API的性能真的很重要。
如果API數據源響應快，前端的應用程序的設計好點或差點影響不大，要是響應慢如蝸牛，前端的設計再出色也是然並卵。現在我們的客戶端應用展羨旅示的數據源可能都是來自多個API響應內容的聚合，性能對這種微服務構架來說真的非常重要。
可以毫不誇張的說出色的性能就是你API提供的最好功能。我們知道向目標改進的唯一正確的方法就是找到問題的關鍵點，或者叫關鍵路徑，並不斷迭代測量和調整你的架構系統，直到系統達到預定的目標。對於API來說，測量和提高性能的過程就是負載與壓力測試的過程。
本文將重點介紹如何對你的API進行負載壓力測試。我們會以一個簡單的、未測過的例子開始，然後再添加一個訪問控制層，要確保一切都經過嚴格測試，做好處理真實流量的准備工作。OK，開始吧！
首先我們要明確要測試什麼，可以是對你所有的API介面，或者是對單個API介面，或是對需要排除故障或改進的API介面的常規測試。
本文的其部分，我們將使用一個示例API。這是一個棋牌類游戲的Node.js API。它有三個API介面：
/question – 返回一個隨機黑牌
/answer – 返回一個隨機白牌
/pick – 返回一對隨機的問題與答案
你測試用的負荷情況越和真實環境的越類似，你的負載測試就越有用。如果你不知道實際流量有多少或者你不知道負載在所有介面上是否都一致，那麼就算你知道你的API可以保持400 請求/秒的吞吐量也沒啥鳥用。
所以，你應該先從收集你兄冊凳API的使用數據開始。你可以直接從你的API服務日誌或者從其他你在用的應用性能工具（例如New Relic）中獲取數據。在對你的API進行第一次測試之前，你應該對以下問題做到心中有數：
（1）每秒請求數的平均吞吐量（Average throughput in requests per second）
（2）峰值吞吐量（您在某段時間內獲得的最大流量是多少？）（Peak throughput）
（3）API各介面的吞吐量分布情況（有沒有一些介面的流量遠姿野超其他介面？）
（4）用戶的吞吐量分布情況（少數用戶產生大多數的流量，或者是更均勻分布？）
另外還需要考慮的一個關鍵點是，在測試期間將要模擬的流量會是怎樣的，主要考慮點是：
（1）重復負載生成（Repetitive load generation）
（2）模擬流量模式
（3）真實流量
通常我們最好以最簡單的方法開始測試，然後逐步演化到更為接近真實環境的測試。我們可以先用重復負載生成來做為API介面的第一個測試，這樣不僅可以驗證我們的測試環境是否穩定，更重要的是可以讓我們找到API能承受的最大吞吐量，這樣我們就可以知道API可以達到的性能上限是多少。
找到你的API性能上限值後，你就可以開始考慮如何將你的生成的測試流量塑造得更接近真實環境。使用真實流量來測試是最理想的，但實際操作不太可行。要模擬真實流量比較難，也太花時間。所以我們有一個折中點的方法：先研究你的流量分析數據，並做一個簡單的概率模擬。比如你有100個API介面（提示：原文endpoint在這里我譯為介面，翻譯成端點也可以，不過譯成介面感覺更容易理解），你檢查了上個月的使用情況，發現80%的流量來自20個介面，其中3個介面佔用了50%的流量。那麼你就可以創建一個遵循這種概率的請求列表，並提供給你的負載測試工具。這樣做就相對快多了，並且它相對比較接近你真實負載，可以顯示出你實際環境中可能遇到的問題。
最後，如果你拿到你要測試的API的真實訪問日誌，你就可以用它們來做最接近客觀現實的測試。我們待會兒要討論的大部分負載測試工具，都是接收一個請求列表作為輸入文件。你可以用你的訪問日誌，稍微做一個格式調整就可以匹配每個測試工具所需的格式。搞定這個你就可以在測試環境中輕松重現你的生產流量。
好了，你清楚了你要測試什麼鬼了，准備工作的最後一步就是配置好你的測試環境。你需要一個專用的測試環境。如果你不怕被你老闆罵的話，或者比較任性，你也可以直接在你的生產環境中進行性能測試，不過出問題別說哥事先沒跟你說清楚哈。
如果您已經設好一個預生產或沙箱環境，並且你的API也在上面運行了，那麼你就萬事俱備了。因為本文要用示例API，我們會在AWS的服務實例上設置我們的環境。
在我們的例子中，我們使用一個簡單的API，不需要從磁碟讀取或在內存中保存大型數據集。我們選擇Linux C4.large 實例就夠了。
注意：我們對比過其他相似處理資源數但內存更大的AWS實例，但實際測試中內存大部分沒使用，所以我們選了C4.large
接下來，我們將一個配好的負載測試實例（伺服器）運行起來，這只是一個運行模擬測試程序的伺服器，它會通過從多個並發連接重復發送請求到我們的API伺服器。你需要模擬的負載越高，機器的性能就要求越高。再次，這也是一個CPU密集型工作負載。這里我們選擇具有4個虛擬核，16個 ECU的優化處理器的 c4.xlarge AWS伺服器
我們選擇在相同的可用區內部署所有實例（API伺服器與測試伺服器在同一個區/機房），這樣可以將外部因素對我們測試結果的影響降到最小。
我們有一個沙箱環境來運行我們的API，同時也有另一台伺服器准備開始負載測試。如果這是你第一次做性能測試，你一定會想知道什麼是最好的方法。在本節中，我們將會分享我們如何選擇工具，同時也會介紹一下目前市面上一些公認比較好的工具。
JMeter
在人們意識當中，首當翹楚的估計是 Apache JMeter ，這是一個開源的Java程序，他關鍵的特性就是提供一個強大而完善的創建測試計劃的GUI。測試計劃由測試組件組成，測試組件定義了測試的每一個部分，例如：
（1）用來注入負載測試的線程
（2）參數化測試中使用的HTTP請求
（3）可添加偵聽器，象widget測試組件那樣，可以以不同的方式顯示測主式結果
優點：
（1）它是功能性負載測試的最好工具。你可以設定條件來為復雜的用戶流建模，還可以創建斷言來驗證行為。
（2）輕松模擬復雜的http請求，比如請求前的登錄驗證或文件上傳
（3）可擴展性強，有很多社區插件可以修改或擴展內置的行為
（4）開源並且免費
缺點：
（1）GUI學習曲線陡峭，一大堆的選項，在你運行第一個測試之前你得了解大量的概念。
（2）測試高負載時，操作步驟很麻煩。你需要先使用GUI工具來生成XML測試計劃，然後在非GUI模式下導入測試計劃運行測試，因為GUI會消耗掉本用於生成負載的大量資源。你還需要注意所有的偵聽器（收集數據與展示測量的組件）哪些要被禁用或啟用，因為它們也很耗資源。測試結束後後，你需要將原始結果數據導入GUI以才能查看結果。
（3）如果你的目標是測試一段時間內的持續吞吐量（例如在60秒內每秒請求1000次），那麼很難找到正確的並發線程數量和計時器來求出一個比較穩定的數值。
JMeter只是我們在開始測試時用的工具，我們很快開始尋找其他替代方案。原因是，如果你的目標是在Web應用上壓力測試復雜的用戶流，那麼JMeter可能是最好的工具，但如果你只是需要在一些HTTP API介面上進行性能測試，那用它就是殺雞用牛刀了。
Wrk
Wrk 是一款和傳統的 Apache Benchmark （最初用來做Apache伺服器的測試工具）非常相似的工具。wrk和ab完全不同於JMeter：
（1）一切都是可以通過命令行工具配置和執行的。
（2）配置少但強大，只有基本生成HTTP負載的必要幾項配置
（3）性能強悍
然而，和傳統ab工具相比還是有幾個優勢的地方，主要是：
（1）多線程，所以能利用多核處理器的優勢，更容易生成更高的負載
（2）利用Lua腳本很容易進行擴展默認的行為
不好的地方，主要是生成的默認報告在內容與格式上都受到限制（僅文本，無繪圖）。當你的目標是找到你的API可以處理的最大負載量，那麼wrk是你最佳選擇工具。wrk用起來很快就可以上手。
Vegeta
Vegeta 是一款開源命令行工具，但它採用的方式不同於我們以前所見的工具。它專注於如何達到與維持每秒請求數速率。也就是說它側重在測試支撐每秒X次請求時API會有怎樣的服務行為，當你有實際的數據或對你將要達到的峰值流量有個估算時就非常有用，你可以用於驗證你的API是否能滿足你的需求。
SaaS 工具
正如你之前所看到的，運行一個簡單的負載測試需要准備好配置環境。最近有些產品提供負載測試服務。我們試過兩個， Loader.io 和 Blazemeter （話外：阿里也有性能測試工具 PTS ，老外估計沒試過）。
注意：我們只試了這兩個工具的免費版，所以得到的測試結果僅適用於免費版的限定。
Blazemeter
這個產品和我們前面提到的JMeter一樣有同樣的毛病：如果你只需要用在高負載測試，你需要在GUI界面上創建測試計劃，然後在另一個運行非GUI模式的JMeter中導入這些計劃。Blazemeter允許你上傳JMeter的測試計劃到他們的雲端並運行，但可惜的是免費版只能設置50個並發用戶。
Loader.io
它是一款 SendGrid 出品的簡單而強大的雲負載測試服務工具。它有你所需要的功能和漂亮的可視報告。 Loader.io 的免費版還是不錯的，每秒最多可以有10000次請求的吞吐量，你基本上就可以用它來運行一個真實的負載測試。
我們推薦使用多個工具，以便可以多重檢查我們的測試結果，不同的工具有不同的功能與方法，可以更多方面地反映測試結果。
我們先嘗試找到我們的API可以承受的最大吞吐量。在這個吞吐量下，我們的API服務達到最大CPU利用率，同時不會返回任何錯誤或超時。這個吞吐量就可作為我們後面測試要用的每秒請求數。
同樣，重要的是要注意到：CPU是限制因素之一，但你也還必須清楚地知道哪些資源會成為你API的性能瓶頸。
我們有必要在API伺服器上安裝一些工具，以便我們在測試過程中監控資源的利用率情況。我們使用 Keymetrics.io 和 PM2 模塊。
我們的Node.js應用運行了一個非常簡單的HTTP 服務。Node.js是單線程設計的，但為了利用c4.large AWS實例中提供的雙核，我們使用PM2的集群功能來運行應用程序的兩個工作進程。
由於我們的API是完全無狀態的，所以很容易使用PM2的 核心集群模塊（PM2在內部直接使用）。PM2提供的集群功能提供了不錯的快捷命令來start/stop/reload應用程序，也可以監控進程。
我們先使用Loader.io對API進行測試。以下是持續30秒，每秒10,000次請求的測試結果，10000次請求是Loader.io免費版中允許的最大吞吐量。
在測試期間，我們觀察到API伺服器的CPU處理器在測試期間只有幾次達到100％的容量。
這表示我們的API可能還可以處理更高的吞吐量。我們接下來通過運行wrk進行第二次測試證實了這一點。我們的目標就是要將我們的API伺服器性能推到極限。
wrk -t 4 -c 1000 -d 60 --latency --timeout 3s http://api-server/questions
這里是我們對這個測試做了多次重復測試的結果：
Running 1m test @ http://api-server/question
4 threads and 1000 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 62.23ms 30.85ms 1.35s 99.39%
Req/Sec 4.07k 357.61 5.27k 94.29%
Latency Distribution
50% 60.04ms
75% 63.85ms
90% 64.17ms
99% 75.86ms
972482 requests in 1.00m, 189.89MB read
Requests/sec: 16206.04
Transfer/sec: 3.16MB
結果表明，我們的預感被證實：它達到16,206請求/秒，同時保持合理的延遲，第99百分位只有75.86毫秒。 我們將這作為我們的基準最大吞吐量，因為這一次我們看到了API伺服器的最大容量處理能力：
我們剛看到用一個簡單的方式來找出你的API可承受的最大流量負載，同時在這過程中我們介紹並討論了我們看到的一些工具。
請繼續關注本文的第二部分，我們將介紹如何控制流量，不要讓隨隨便便一個客戶端就可以輕松搞跨您的API。 我們將展示如何通過在架構前端添加代理來確保我們的API的性能不受影響。
本文譯自： How to load test & tune performance on your API