推薦一款國內首個開源全鏈路壓測平臺

狂師發表於2021-07-27

前不久國內知名的系統高可用專家數列科技宣佈開源旗下核心產品能力，對外開放生產全鏈路壓測平臺產品的原始碼，並正式命名為：Takin。

目前，該專案已在Github上釋出開源，作為國內首款開源的全鏈路壓測平臺，Takin的開源將為更多企業提供超低門檻、超低成本、超高效率的效能保障能力。

1. 什麼是生產環境全鏈路壓測?

全鏈路壓測簡單來說，就是基於實際的生產業務場景、系統環境，模擬海量的使用者請求和資料對整個業務鏈進行壓力測試，並持續調優的過程，本質上也是效能測試的一種手段。

通過生產環境全鏈路壓測，真實模擬“風險”業務行為場景，實時監控系統表現，提前識別和快速定位系統的中的不確定因素，並對不確定因素進行處理，優化系統資源配比，使用最低硬體成本，使系統從容面對各種“風險”場景，達到預期的系統效能目標。通過這種方法，在生產環境上落地常態化穩定壓測體系，實現IT系統的長期效能穩定治理。

全鏈路壓測系統架構設計大體類似如下：

2. 我們為什麼需要做生產環境的效能測試

可能會有人想，效能測試不應該是在測試環境進行嗎，為什麼需要在生產環境 上面做效能測試呢？

特別是微服務架構在現代系統架構中已被普遍使用，與此同時，隨著業務的擴張和微服務數量的增加，它使系統變得非常複雜以至於人無法理解，而且，很多業務邏輯本身也非常複雜。業務複雜性和系統複雜性使保證和維持整個系統的高可用性非常困難，同時，它對研發效率也產生負面影響。

為了保證系統的高可用性，我們通常對測試環境或生產環境的單一服務進行效能測試，但是，測試環境與在生產環境區別很大，單個服務也不能代表整個服務鏈路，因此，它們都不能保證系統的高可用，通常也無法給出準確的容量評估結果。

歸結起來，主要原因有三：

1. 微服務很複雜
和單體架構相比，微服務架構增加了業務系統的複雜性，因為它的子服務數量更多，並且涉及更多的不同技術棧和框架。

2. 業務系統也很複雜
很多業務本身的業務邏輯也很複雜，其中很多業務涉及比較長的業務流程，例如電商業務。

3. 服務與服務之間的呼叫關係也很複雜
在微服務架構的系統中，服務之間的呼叫關係非常複雜，每次服務的釋出和更新都可能影響整個系統的可用性，並使開發人員難以頻繁釋出新版本。

如下這張圖中是一張典型微服務呼叫鏈路，如果服務數量再擴大幾十倍，想象一下，呼叫關係圖又會變成何種樣子：

2. 效能測試演變的四個階段

效能測試不同公司的實踐程度皆有差異，但整的來說，演進過程主要分為從線下到線上四個階段：

1.需求驅動壓測階段

需求驅動壓測，大多采用簡單的工具進行單介面或者單系統壓測，也能進行一些簡單的效能問題分析，但很多時候都沒有專門的測試團隊，需要開發進行自主壓測。這個階段，雖然有需求驅動，但大多數都是憑靠經驗法+人為拍腦袋來決定如何做，做什麼。

2.效能迴歸體系階段

組建專門的效能測試團隊搭建線下效能測試平臺，且會結合研發流程形成一些規範化體系，並會利用一些開源工具、商業工具，甚至自主開發效能測試平臺。

前兩個階段，主要效能測試開展都是集中線上下環境，如此同時，引出了一些問題，其中比較有代表性：

  • 很多公司線下做了效能測試，但到了線上還是存在很多問題，以測試環境的壓測結果來評估線上環境，效果不佳。

  • 業務增長、營銷活動增加使測試工程師對活動保障心裡沒底，每逢營銷活動問題頻發影響公司形象。

  • 效能壓測效率無法滿足增長的效能壓測需求，導致部分專案沒有效能壓測直接上線，線上故障頻發。

為了解決測試環境效能壓測的不確定性，效能壓測開始向生產環境進行演變，進入生產環境效能壓測階段。

3.生產只讀業務壓測階段

在測試環境迴歸體系階段上增加了生產只讀業務的效能壓測，對生產環境壓測進行實踐，搭建生產環境效能壓測迴歸體系，具備只讀業務生產壓測的效能問題分析能力。

4.全業務全鏈路壓測階段

在上一個階段的基礎上增加寫入業務的效能壓測，進而開展對全業務實行全鏈路壓測，具備全業務的效能壓測能力、問題定位能力，做的更好一些還會增加系統防護能力，比如降級、限流、故障演練等。

3. Takin介紹

Takin是一款基於Java的開源系統，可嵌入到各個服務節點，實現生產環境的全鏈路效能測試，尤其適合面向微服務架構系統。通過Takin，系統中的中介軟體和應用可以在生產環境識別真實流量和測試流量，保證它們進入不同的資料庫，實現真實和測試流量的現網隔離。

Takin具備以下4個特點：

  • 業務程式碼0侵入：在接入、採集和實現邏輯控制時，不需要修改任何業務程式碼；

  • 資料安全隔離：可以在不汙染生產環境業務資料情況下進行全鏈路效能測試，可以在生產環境對寫型別介面進行直接的效能測試；

  • 安全效能壓測：在生產環境進行效能壓測，對業務不會造成影響；

  • 效能瓶頸快速定位：效能測試結果直接展現業務鏈路中效能瓶頸的節點。

Takin結構

專案地址：

https://github.com/shulieTech/Takin
或者
https://gitee.com/mirrors/Takin.git

4. Takin安裝及使用

1､準備一臺裝有docker的伺服器，配置儘量要高些。

2､修改 Docker 映象地址為阿里雲：vim /etc/docker/daemon.json,更新為：

{
  "registry-mirrors": ["<https://q2gr04ke.mirror.aliyuncs.com>"]
}

配置生效：systemctl daemon-reload

3､ 下載拉取映象

docker pull registry.cn-hangzhou.aliyuncs.com/forcecop/forcecop:v1.0.0

4、啟動映象

docker run -d -p 80:80 -p 2181:2181 -p 3306:3306 -p 6379:6379 -p 8086:8086 -p 9000:9000 -p 10032:10032 -p 6628:6628 -p 8000:8000 -p 6627:6627 -p 8888:8888 -p 29900-29999:29900-29999 registry.cn-hangzhou.aliyuncs.com/forcecop/forcecop:v1.0.0

-d是後臺啟動，-p是需要開放的埠，容器執行初始化的時候需要安裝一些必要的元件需要十分鐘的樣子，-d可以忽略後臺元件的安裝資訊，如果想要檢視安裝資訊可以去除-d引數。

5、進入容器，更改配置：docker exec -it 9754b1ff1491 bash

6、修改serverUrl：vi /data/apps/dist/tro/index.html，，將serverUrl配置成伺服器本機IP地址。

7、重啟Nginx服務：nginx -s reload。

8、配置sugre-deploy啟動命令，其中說明一下，sugre-deploy為大資料平臺模組。

[root@30e961d36c91 data]# ps -ef | grep surge
root      4336     1 66 17:48 ?        00:03:20 java -jar surge-deploy-1.0-jar-with-dependencies.jar {"172.17.0.2":"192.168.1.138"}
root      4574    18  0 17:53 ?        00:00:00 grep --color=auto surge
[root@30e961d36c91 data]# kill -9 4336
[root@30e961d36c91 data]# ps -ef | grep surge
root      4582    18  0 17:54 ?        00:00:00 grep --color=auto surge

9、更改sugre-deploy的啟動命令：vi /data/install.sh,將sugre-deploy的啟動命令引數“172.17.0.2”對應的value（192.168.1.138這個）更改為宿主機的IP，儲存。

10、重啟sugre-deploy

nohup java -jar surge-deploy-1.0-jar-with-dependencies.jar '{"172.17.0.2":"192.168.1.220"}' > surge.out  2>&1 &

11、進入壓測控制檯

輸入壓測控制檯地址：http://docker宿主機IP/tro/#/login
示例： http://192.168.1.220/tro/#/login

預設賬號密碼：賬號:admin 密碼:pamirs@2020

如果能看見如上圖，恭喜您，成功安裝了Takin，接下來就可以開啟壓測之旅啦~

利用Takin在壓測結束後，系統會自動生成一份壓測報告，將本次壓測所產生的資料進行記錄和存檔，可隨時通過檢視報告來回溯壓測時的效能指標變化情況，分析效能瓶頸與定位定能問題。

如下圖所示：

可檢視壓測全域性或單個業務活動的TPS、RT、成功率、SA的指標趨勢。

請求流量跟蹤：

官方快速入手指南：

https://docs.shulie.io/docs/opensource

相關文章