美團內部的RPC服務大多構建在Thrift之上，在日常開發服務的過程中，需要針對這些服務進行壓力測試（以下簡稱壓測）來發現潛在問題。常用的方法有：
- 使用一些指令碼語言如：Python、Ruby等，讀取線上日誌構建請求，用多執行緒模擬使用者請求進行壓測
- 使用開源工具進行壓測
然而，無論採取哪種方法，壓測都是一個十分耗時而又繁瑣的過程，主要痛點有：
- 需要寫很多程式碼解析日誌，還原請求，對於比較複雜的請求，解析很容易出錯
- 需要搭建指令碼或者工具的執行環境，通常這一過程比較耗時
- 由於打壓方法沒有統一，導致打壓的結果指標比較混亂，有的結果甚至以終端輸出的方式展示，非常不直觀
- 對一個應用的打壓測試，由於環境、程式碼的問題，導致組內同學很難共享
針對上述問題，提供一個簡單好用的壓測工具是十分有必要的。
是否有必要重複造輪子
在構建壓測工具之前，對於一些現有的開源工具進行了調研。現在主流的壓測工具主要有以下幾個：
JMeter
JMeter是一個比較老牌的壓測工具，主要針對HTTP服務進行打壓，該工具在以下方面並不滿足美團內部的壓測需求：
- 預設不支援Thrift的打壓測試
- 需要本地安裝，並且配置複雜
- 對於使用者操作並不友好
twitter/iago
iago 是一個由Twitter開源的壓測工具，支援對HTTP、Thrift等服務進行壓測，其主要問題如下：
- 對每個壓測應用都需要建立一個專案
- 壓測結果並不直觀
- 流量重放依賴本地檔案
- 專案依賴於一個較老版本的Scala，搭建不便
- 相關文件比較少
除此之外，當時還考察了Gatling、Grinder、Locust 等一些常見的壓測工具，都因為適用場景和美團的需求有些出入而排除了。
綜上，針對當前壓測工具的一些現狀，構建一個簡單易用的壓測工具還是很有必要的。
目標
針對之前提到的痛點，新的壓測工具主要提供以下功能：
- 線上流量拷貝
- 簡單易用的操作介面（接入壓測的時間應該控制在1小時以內）
- 清晰的圖表能反映壓測應用的各項指標
- 滿足包括Thrift、HTTP等服務的壓測需求
如何構建
抽象
目標已經明確，怎麼實現呢？首先是抽象壓測的過程。
一個典型的壓測過程如圖所示，首先在init方法裡面，進行一些初始化的工作，比如連線資料庫，建立客戶端等。接下來，在run方法裡面發出壓測請求，為了保證能夠對服務產生足夠的壓力，這裡通常採用多執行緒併發訪問，同時記錄每次請求的發起時間和結束時間，這兩個時間的簡單相減就能夠得到每次請求的響應時間，利用該結果就可以計算出TP90、平均響應時間、最大響應時間等指標，等壓測結束後，通過destroy方法進行資源回收等工作。
以上過程可以用介面表示，無論是壓測Thrift服務還是HTTP服務，本質上都是這三個方法實現的不同。考慮到壓測工具的靈活性和通用性，壓測工具可以將這個介面交給打壓測試的同學實現，而壓測工具則重點實現多執行緒打壓，打壓結果的聚合等比較耗時的工作。
|
1 2 3 4 5 |
interface Runner { def init(Test app) // 初始化壓測 def run(Test app, String log) // 每次打壓請求，傳入log方便構建請求 def destroy(Test app) // 壓測完畢後，回收資源 } |
拷貝流量
Thrift服務打壓的難點之一就是如何簡單地拷貝線上真實流量用來構建打壓請求。一些大型的Thrift服務資料結構非常複雜，寫打壓指令碼的時候需要很多程式碼來解析日誌，而且容易出錯。 因此提供一個簡單好用的拷貝流量方法是十分有必要的。
在這裡壓測工具提供了一個叫VCR（錄影機）的工具來拷貝流量。VCR能夠將線上的請求序列化後寫到Redis裡面。
考慮到使用者需要檢視具體請求和易用性等需求，最終選取了JSON格式作為序列化和反序列化的協議。同時需要部署在生產環境，為了降低對線上服務的影響，這裡採取了單執行緒非同步寫的方式來拷貝流量。
聚合資料
應用打壓完成後，需要一些指標來評估壓測結果，常見的指標有：
- 最大響應時間
- 平均響應時間
- QPS
- TP90
- TP50
壓測工具採用了 InfluxDB 來完成資料的聚合工作。
以TP90為例子，僅需要一行查詢就能實現需求。
|
1 |
SELECT PERCENTILE(response_time, 90) FROM test_series GROUP BY time(10s) |
架構
整體而言，整個打壓過程如下：
實踐
拷貝流量
美團內部的服務大多使用Java來構建，VCR以Maven Package的方式提供給使用者。
對使用者來說只需要2行程式碼可以拷貝流量。
為了不影響線上服務，通常選取單臺機器進行流量拷貝工作。
|
1 2 3 4 5 6 7 8 9 10 11 12 |
public class TestAppRPC implements TestApp.Iface { private Vcr _vcr = new Vcr("testapp"); // 指定拷貝流量的key @Override public TestResponse echo(TestRequest req) throws TException { _vcr.copy(req); // 拷貝操作 long start = System.currentTimeMillis(); TestResponse response = new TestResponse(); return response; } } |
一旦流量拷貝完成後，通過Web介面，使用者能夠檢視日誌的收集情況和單條日誌的詳情。
壓測邏輯實現
壓測工具採用Groovy來進行編寫。對每個應用來說，只需要實現runner介面就可以實現對應用的打壓。
|
1 2 3 4 5 |
interface Runner { def init(Test app) def run(Test app, String log) def destroy(Test app) } |
以Thrift服務為例：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
class TestServiceRunner implements Runner { RPCService.Client _client TTransport _transport; @Override def init(Test app) { def conf = app.config // 讀取應用配置 _transport = new TFramedTransport(new TSocket(conf.get("thrift_service_host") as String, conf.get("thrift_service_port") as int)) TProtocol protocol = new TBinaryProtocol(_transport) _client = new RPCService.Client(protocol) _transport.open() } @Override def run(Test app, String log) { TestRequest req = Vcr.deSerialize(log, TestRequest.class) // 將拷貝流量反序列化 _client.echo(req) // 傳送請求 } @Override def destroy(Test app) { _transport.close() // 關閉服務 } } |
建立應用
實現以上介面後，就可以對應用進行打壓了。
使用者可以通過Web介面建立應用，除了必填配置以外，使用者可以按照應用靈活配置。
效能指標
使用者可以通過直觀的圖表來檢視應用的各種效能指標。
結束語
壓測工具上線以來，已經接入了20多個應用，完成數百次打壓實驗，現在應用的接入時間僅需要15～30分鐘。保證了美團服務的穩定和節省了開發同學的時間，使大家告別了以往繁瑣冗長的打壓測試。
歡迎對這方面有興趣的同學一起討論。