壓測背景：

LPWAN是當前物聯(lián)網(wǎng)行業(yè)中最重要的技術(shù)之一，以年復合增長率90%的驚人速度增長。NB-IOT、LoRa、ZETA 以及Sigfox是當前市場上主流的幾種LPWAN通信技術(shù)。

ZETA LPWAN 協(xié)議以超窄帶、低功耗雙向通信和多跳組網(wǎng)的特點，徹底改善了傳統(tǒng)的LPWAN協(xié)議不足之處，大大增加了LPWAN技術(shù)在物聯(lián)網(wǎng)應用的空間。

ZETag云標簽 是縱行科技基于ZETA 技術(shù)開發(fā)的傳感柔性標簽，具有公里級超廣覆蓋，低功耗特性等優(yōu)勢，與同類技術(shù)相比，成本可降低至1/3-1/10，并能支持大容量并發(fā)，使用壽命最長可達5年。與此同時，ZETag云標簽通過減小尺寸和功耗并改善性能來消除常規(guī)有源標簽的閑置，除卻物流倉儲和貨物追蹤，還可作為一次性標簽廣泛應用在資產(chǎn)定位和�；�、危廢管理的萬億級市場。

目前，ZETag云標簽 已在京東物流、中國郵政、日郵物流、上海睿池、上海派鏈等上下游物流企業(yè)物流載具及貴重包裹上實現(xiàn)應用，也是全球首例在速遞郵件上實現(xiàn)實時軌跡跟蹤的服務的物聯(lián)網(wǎng)云標簽。

數(shù)蛙科技是工業(yè)物聯(lián)網(wǎng)千萬級設備接入與管理的專業(yè)平臺提供商，目前業(yè)務場景已覆蓋電力、交通、物流、工業(yè)制造等多領(lǐng)域的商業(yè)應用。

濤思時序數(shù)據(jù)庫TDengine是目前針對時序數(shù)據(jù)庫的性能最優(yōu)的開源數(shù)據(jù)庫平臺，廣泛運用于工業(yè)、電力、車聯(lián)網(wǎng)、大數(shù)據(jù)領(lǐng)域。

數(shù)蛙科技結(jié)合縱行科技的ZETag云標簽與濤思數(shù)據(jù)的高容量時序數(shù)據(jù)庫，為物流領(lǐng)域未來高增長、高并發(fā)的物流標簽場景，進行了1000萬接入、百億級時序數(shù)據(jù)的運營級全業(yè)務模擬壓力測試。

ZETag物流標簽組網(wǎng)如下：

 

壓測目的：

本次壓力測試通過模擬1萬ZETA AP、千萬ZETA TAG標簽的在線運行，精準高效完成ZETA AP、ZETA TAG的在線協(xié)議解析、解析數(shù)據(jù)實時入庫、海量數(shù)據(jù)在線查詢與展示等流程。同時，對真實物流業(yè)務場景進行抽象，實現(xiàn)批次ZETA TAG在不同線路上發(fā)生軌跡改變，移動過程中利用不同的ZETA AP實現(xiàn)定位。ZETA TAG在線運行過程中，每隔15分鐘發(fā)送心跳包，被臨近的單個或者多個ZETA AP報送至服務端。服務端會按照策略選擇信號最好的上報數(shù)進行存庫，并利用上報信號最好的AP對ZETA TAG進行定位。

通過壓力測試，判斷當前應用環(huán)境情況下系統(tǒng)的負載能力，為今后應用范圍擴大，用戶量上升后，服務器擴容、升級等提供必要的技術(shù)支撐，及服務器規(guī)劃等。

本次測試目的是為了驗證基于數(shù)蛙連接與設備管理平臺的ZETA物流跟蹤管理能夠?qū)崿F(xiàn)千萬級ZETA TAG標簽同時在線穩(wěn)定運行、數(shù)據(jù)及時回傳、正常入庫、高效查庫。

本次測試場景的壓力與復雜度遠高于真實場景，在保障ZETA物流跟蹤當前業(yè)務可以正常開展的同時，也可以有效支撐ZETA相關(guān)業(yè)務應用的拓展與深化應用。

壓測環(huán)境：

由于壓力測試是對系統(tǒng)負載能力的測試，無法通過真實的環(huán)境來進行獲取相關(guān)指標，因此通過測試機與測試服務，模擬1萬AP、千萬ZETA TAG與服務器高頻數(shù)據(jù)交互，利用算法虛擬真實業(yè)務場景下實際的操作來進行測試。

測試機部署虛擬云設備服務，及進行壓力測試的客戶端機器，一般采用高配置的機器來進行測試。在壓力測試過程中，一般忽略測試機對壓力測試結(jié)果的影響。

 

壓測場景 ：

 

ZETA設備運行模擬：

ZETA AP ：每10s主動連接服務端，連續(xù)30min未連上等待2min再次連接;連接狀態(tài)下1min一次心跳交互;連續(xù)三次未收到ACK，發(fā)起重連。

ZETA TAG ：每15分鐘上報一次心跳包;心跳報文被不同AP接收上報后，服務端會比較后保留首次 收到TAG心跳后3s內(nèi)RSSI最強上報的AP位置信息作為TAG的當前位置。

客戶端場景模擬描述：

運輸、配送線路 ：本次場景模擬線路總計200條，線路可以配置。

運輸車輛 ：本次場景模擬運輸車輛50000部，貨車會模擬真實物流場景在既定線路上進行移動，車上ZETAG標簽隨之移動。

ZETA AP ：本次模擬10000臺，每條線路上分布500臺ZETA AP

ZETA TAG數(shù)量 ：本次模擬在運ZETAG1000萬個，ZETAG隨運輸車輛移動，每隔15分鐘的心跳報文被相鄰的2-3個ZETA AP接收。

服務端業(yè)務描述：

每15分鐘內(nèi)完成千萬在運ZETAG標簽心跳數(shù)據(jù)包解析(加上冗余報文，每15分鐘內(nèi)解析心跳報文數(shù)量2000多萬條);

完成ZETA TAG心跳數(shù)據(jù)比較與冗余數(shù)據(jù)過濾;

完成解析出的海量TAG位置信息實時分類入庫;

4、支持ZETA TAG最新位置更新與軌跡查詢;

5、每分鐘完成1萬ZETA AP的心跳報文解析、存儲;

6、完成ZETA AP運行狀態(tài)信息的接收與存儲;

7、支持ZETA AP運行狀態(tài)信息查詢。

根據(jù)測試系統(tǒng)中消息的業(yè)務場景情況，選取以下指標作為場景壓力測試情況判斷依據(jù)：

A、ZETA AP在線情況統(tǒng)計

B、ZETA AP在線率

C、在線ZETAG標簽數(shù)量

D、ZETA標簽解析包數(shù)量

E、1/5/15分鐘CPU平均負載

F、內(nèi)存使用量

壓測技術(shù)：

系統(tǒng)監(jiān)控

服務端與客戶端系統(tǒng)監(jiān)控和業(yè)務數(shù)據(jù)監(jiān)控采用Prometheus&Grafana做統(tǒng)計與展示

時序數(shù)據(jù)監(jiān)控 --- Grafana&TDengine監(jiān)控插件(監(jiān)控TDengine數(shù)據(jù)總量、丟包數(shù)以及增長速率)

 

系統(tǒng)指標監(jiān)控 --- Grafana&&Prometheus監(jiān)控插件，用node_exporter采集數(shù)據(jù)(監(jiān)控CPU，內(nèi)存，網(wǎng)絡、存儲四大指標)

 

業(yè)務消息監(jiān)控 --- Grafana&Prometheus監(jiān)控插件，業(yè)務層通過Prometheus client實時統(tǒng)計各個消息路由節(jié)點上發(fā)包數(shù)、收包數(shù)以及丟包數(shù)等指標，業(yè)務層主要指標如下：

 

時序數(shù)據(jù)

ZETag物流標簽的地址域是4個字節(jié)，最高的一個字節(jié)是保留字節(jié)，本次壓測的ZETag物流標簽的實際地址域是3個字節(jié)，所以ZETag地址為FF XX XX XX，總計16,777,215個標簽的地址，如果按照一個標簽設備一個子表的方式設計，需要1600多萬個子表。根據(jù)實測結(jié)果，Tdengine 1.6.3單機版本子表數(shù)量超過49萬就極不穩(wěn)定，很容易崩潰，但子表數(shù)量在10萬以下具有良好的性能。所以子表設計采用了一種虛擬分組設計，將最低兩個字節(jié)(總計65,535個子表)作為子表空間，每個子表存儲一個字節(jié)(總計255個標簽)的標簽時序數(shù)據(jù)。

時序數(shù)據(jù)模型設計 ：

 

 

240億數(shù)據(jù)存儲空間占用230G磁盤空間

 

數(shù)據(jù)存儲目錄

 

時序數(shù)據(jù)入庫示例：

 

時序數(shù)據(jù)入庫策略：

本次模擬了1300多萬的物流標簽15分鐘一個心跳，平均1.4萬多的QPS，峰值QPS很容易超過Tdengine的入庫QPS閥值，導致Tdengine崩潰。在消息路由層設計了一個基于令牌桶算法的消息緩存層進行削峰處理，在保證時序數(shù)據(jù)的順序性的同時，也能讓時序數(shù)據(jù)以比較平穩(wěn)的速率批量入庫。由于Tdengine沒有提供erlang的連接池程序，最開始用默認的http客戶端來入庫，長時間運行不穩(wěn)定，最后我們把Tdengine原生的c語言的連接池程序進行了改造，添加了mqtt訂閱功能，通過mqtt協(xié)議來轉(zhuǎn)發(fā)批量存庫時序數(shù)據(jù)。

時序數(shù)據(jù)出庫策略：

由于對子表進行虛擬分組設計，查找任何一個物流標簽數(shù)據(jù)的物流軌跡數(shù)據(jù)都有非常便捷的尋址算法，快速查找到用戶層期望的時序數(shù)據(jù)，在百億級數(shù)據(jù)規(guī)模的情況下，查詢速度也可以到毫秒級。

ZetaEtag即時數(shù)據(jù)查詢接口 ：/zeta/etag/{tag}

超時時間為5秒

隨機讀tag，數(shù)據(jù)庫內(nèi)數(shù)據(jù)58169933條

tag 生成方式：FF開頭后六位隨機生成

 

* 返回status code為200(找到目標tag)或404(找不到目標tag)兩者都視為調(diào)用成功

ZetaEtag歷史數(shù)據(jù)接口 ：zeta/etag/history/{tag}

超時時間為5秒

對所有tag隨機讀，limit值為100，日期范圍在合理范圍內(nèi)隨機產(chǎn)生，數(shù)據(jù)庫內(nèi)數(shù)據(jù)58169933條

tag生成方式：FF開頭后六位隨機生成

日期生成方式：1569558137——1569579737間隨機數(shù)

 

2019年10月份做壓測報告時，沒有記錄240億時的API統(tǒng)計，把去年的壓測鏡像恢復回來，240億標簽數(shù)據(jù)時的查詢速度如下

 

消息路由

ZETag物流標簽數(shù)據(jù)從數(shù)據(jù)產(chǎn)生到數(shù)據(jù)落庫，1300多萬ZETag標簽 =》5萬卡車進程=》1萬AP基站客戶端連接進程=》1萬AP的服務端連接進程=》65535虛擬分組進程=》消息緩存調(diào)度進程 =》Tdengine的mqtt客戶端=》Tdengine連接池存儲進程，消息需要經(jīng)過7次轉(zhuǎn)發(fā)，每一跳都需要小心處理內(nèi)存釋放和消息堵塞問題。每15分鐘有將近3000萬-4500萬消息的生產(chǎn)和消費，需要有非常好的GC處理機制。其中1萬AP的服務端連接進程--》65535虛擬分組進程，這一跳消息轉(zhuǎn)發(fā)速率沒有固定的對應關(guān)系，兩點之間QPS波動非常大，用開源的mqtt消息轉(zhuǎn)發(fā)和消費組策略也非常容易導致消息堵塞和內(nèi)存持續(xù)上漲。這里也還是得益于之前的虛擬分組設計，通過虛擬分組比較好的解決了這一跳的高效消息路由，同時也把這兩點之間的消息轉(zhuǎn)發(fā)的QPS峰值削的比較平。

影子設備

本次測試模擬的是類似雙11這樣的物流標簽軌跡最繁忙的場景，模擬了5萬臺卡車裝滿(200多件貼上ZETag標簽的快遞件)快遞件，在200多條線路上飛奔，在行駛過程中不停切換AP基站，上報ZETag標簽軌跡數(shù)據(jù)，滿懷期望的用戶時不時登錄快遞網(wǎng)站查看一下自己購買的貨物到了何處。我們在系統(tǒng)中設計了5萬個卡車影子設備，1萬的AP基站影子設備和65535虛擬分組影子設備來處理這一較為復雜的業(yè)務場景�？ㄜ囉白釉O備承載了ZETA標簽信息，線路位置信息和線路沿途的AP基站信息的交互，AP基站影子設備承載了ZEtag通信協(xié)議處理，虛擬分組影子設備承擔了1300萬ZETag標簽的邊緣計算和時序數(shù)據(jù)存儲處理。

任務調(diào)度

每15分鐘有將近3000萬-4500萬ZETag標簽消息的生產(chǎn)和消費除了需要良好的GC機制，同時也需要一個良好的任務調(diào)度機制。治大國如烹小鮮，每一個影子設備上面的任務調(diào)度處理細節(jié)非常關(guān)鍵，每一個小的偏差都會被乘以一個3000-45000萬的系數(shù)放大，對任務調(diào)度質(zhì)量要求是零缺陷。合理的分組策略(也即合理的影子設備設計)非常關(guān)鍵，可以從宏觀上對系統(tǒng)資源進行削峰，在單個影子設備上進行完美的微操作，讓每一個影子設備的任務調(diào)度策略達到零缺陷。

壓測結(jié)果：

 

  

(新媒體責編：syhz0808)