網約車系統開發方案與容量評估_網約車軟件開發_網約車系統_網約車系統開發方案

為企業提供一體化出行系統行業解決方案

咨詢熱線: 13428762705

首頁 / 最新動態 / 行業資訊 /

網約車系統開發方案與容量評估

2022-09-09 10:23:34 行業資訊

Ptaxi猿著整理了網約車系統開發方案與容量評估相關內容，跟著小編一起來看看吧

一、網約車系統項目背景

Ptaxi網約車軟件開發客戶

二、網約車系統業務流程

網約車系統業務流程_網約車軟件開發_網約車系統_網約車系統開發方案

網約車系統客戶端設計

考慮乘客獲取預估價格的查詢是否會有性能瓶頸，我的理解應該是調用地圖提供商接口，獲取公里數，再計算價格。只需考慮ecs能夠橫向擴容即可。

網約車系統司機端設計

搶單模式：

1.司機端搶單模式下，主動查詢符合條件的訂單列表，此處需要考慮列表查詢算法優化。壓力在數據庫端，避免全表掃描，可采用網格定義方式提高查詢效率，降低數據庫壓力。

2.獲取列表后，司機端需要點擊搶單，對于多個司機返回列表并排序在前的客戶訂單狀態，會存在熱更新，有且只有一個司機能夠對某個客戶訂單update并打上司機id。搶單時update司機id為搶單司機id where司機id=Null，并讀取update返回記錄條數，如果update返回記錄為0則說明搶單失敗，即司機id已被更新不為null。此處直接利用數據庫鎖即可，考慮到司機數量遠小于乘客數量，并且司機搶單并非定時秒殺模式，時間分散，因此數據庫鎖影響可以忽略。

派單模式：

后臺計算匹配的司機id，并向客戶端進行推送。此處僅需考慮對計算過程的效率以及性能壓力即可，同樣匹配邏輯是尋找最近距離司機，同樣通過網格編號查詢距離，通過子域id限定查詢范圍，提高查詢效率。

三、網約車系統架構設計

1.客戶端通過軟負載均衡SLB接入服務端。

2.服務端利用ESS彈性計算功能，支持在CPU超過一定閾值時，進行彈性擴容。

3.司機端服務于乘客端服務進行分離，以支持系統解耦，按需擴容。

4.司機端與乘客端服務器在首期只連接一個RDS數據庫，后續按需進行分布式數據庫擴容。

5.利用Redis存放網格id與網格子域的映射關系的映射關系，以保障快速查詢。

網約車系統架構設計_網約車軟件開發_網約車系統_網約車系統開發方案

四、網約車系統核心算法

通過地圖網格算法的方式，降低經緯度計算壓力，通過網格子域的方式，減少查詢范圍，提高訂單匹配效率。網格算法：A1，B1，屬于同一子域（圖中不同顏色），子域ID為sub-zone，在同一子域中查詢匹配條件。

網約車系統核心算法_網約車軟件開發_網約車系統_網約車系統開發方案

五、網約車系統性能評估

目標：通過性能評估，獲知系統支持容量，對后續擴容進行支持。

工具：Apache ab test

服務器配置：16c32g服務器上部署應用服務節點

測試條件：假設搶單時司機連續點擊次數平均為3次

測試內容：

程序只從數據庫讀取一條字段記錄做的select查詢處理的QPS壓測地址

http://www.hxtylt.cn/api/test/qps

網約車系統性能評估測試內容

http://www.hxtylt.cn/api/test/qps

網約車系統性能評估測試內容

程序做了事務處理的TPS壓測地址

http://www.hxtylt.cn/api/test/tps

網約車系統性能評估測試內容

http://www.hxtylt.cn/api/test/tps

網約車系統性能評估測試內容

測試結果分析：

1.HTTP性能明顯優于HTTPS性能，其中原因是HTTPS進行了通訊加密，應用程序還需承擔證書卸載的壓力，如果采用SLB進行證書卸載，HTTPS性能可以進一步提升。2.在HTTP通訊條件下，吞吐量QPS以及TPS均在并發為1000時出現拐點，因此該配置服務器最大支持的HTTP并發為1000，QPS最高為802，TPS最高為750。

3.在不采用SLB的情況下，吞吐量QPS以及TPS均在并發為500時出現拐點，因此該配置服務器最大支持的HTTPS并發為500，QPS最高113，TPS最高為130。

因此系統如需HTTP通訊支持吞吐量超過1000或HTTPS通訊支持吞吐量超過500時，則需要進行配置升級，通過橫向擴容進行支持，并考慮數據庫瓶頸情況。

六、推薦配置

根據性能評估結果，服務端配置至少兩臺16c32g以上進行負載均衡，單臺能夠達到700+QPS。后續按需進行橫向彈性擴容。拆分為4c8gECS則至少各需要4臺。

網約車系統推薦配置