陳曉陽

(上海賽可出行服務(wù)科技有限公司南京分公司， 南京 210018)

0 引言

隨著社會經(jīng)濟和科技的飛速發(fā)展，出行方式變得多樣化，人們逐漸把網(wǎng)約車作為主流的出行方式，這是社會發(fā)展到一定階段的產(chǎn)物. 但是隨著網(wǎng)約車的發(fā)展，其存在的問題也日益凸顯，比如車輛準入和駕駛員審核不嚴、政府監(jiān)管疏漏、平臺監(jiān)管真空等，嚴重觸及公共利益[1]，所以必須對網(wǎng)約車進行合規(guī)化監(jiān)管. 何謂合規(guī)？簡單來說，就是網(wǎng)約車的司機和車輛是不是符合國家的相關(guān)網(wǎng)約車規(guī)范化標準，需要相關(guān)部門進行報審?fù)ㄟ^才能進行營運. 2016年12月份開始實施的《北京市網(wǎng)絡(luò)預(yù)約出租汽車經(jīng)營服務(wù)管理實施細則》，規(guī)定了網(wǎng)絡(luò)服務(wù)平臺數(shù)據(jù)庫接入政府有關(guān)部門監(jiān)管平臺[2]. 2018年為了進一步加強對網(wǎng)約車的安全管理，交通運輸部辦公廳和公安部辦公廳聯(lián)合發(fā)布《進一步加強網(wǎng)絡(luò)預(yù)約出租汽車和私人小客車合乘安全管理的緊急通知》，并在當年年底清退了不符合條件的車輛和駕駛員. 《緊急通知》(以下簡稱)標志著網(wǎng)約車行業(yè)合規(guī)化工作全面展開[3].

針對以上《緊急通知》的出臺，對于網(wǎng)約車公司來說，技術(shù)實現(xiàn)上，有一定的挑戰(zhàn)性. 網(wǎng)約車和交通部門技術(shù)對接主要依據(jù)的是交通運輸部辦公廳印發(fā)的《網(wǎng)絡(luò)預(yù)約出租汽車監(jiān)管信息交互平臺總體技術(shù)要求(暫行)》的通知[4]，里面涉及網(wǎng)約車公司基本信息、車輛和駕駛員基本信息、車輛和司機實時定位信息、營運訂單相關(guān)信息等，具體的接口有20多個.

基于上述背景，本文針對網(wǎng)約車上報監(jiān)管平臺的系統(tǒng)架構(gòu)演變的相關(guān)問題展開研究，深入探討此系統(tǒng)架構(gòu)的演變，以求快速滿足網(wǎng)約車監(jiān)管平臺的技術(shù)要求，同時對系統(tǒng)的可擴展性、性能等進行優(yōu)化，以及存在的不足之處和后續(xù)工作的展望.

1 軟件系統(tǒng)架構(gòu)設(shè)計

1.1 軟件系統(tǒng)架構(gòu)

隨著軟件系統(tǒng)不斷的升級換代，以及相關(guān)知識和經(jīng)驗的累積，軟件系統(tǒng)架構(gòu)的概念是軟件系統(tǒng)發(fā)展到一定階段的產(chǎn)物. 軟件系統(tǒng)架構(gòu)是一個既古老，又很現(xiàn)代的研究領(lǐng)域. 對于一個軟件系統(tǒng)的設(shè)計，通常先要對軟件系統(tǒng)的整體架構(gòu)進行分析和設(shè)計，相當于蓋房子要先有圖紙一樣，同時隨著新技術(shù)的發(fā)展，為軟件系統(tǒng)架構(gòu)設(shè)計注入了新鮮血液，好的軟件系統(tǒng)架構(gòu)，會帶來軟件系統(tǒng)的各方面性能的提升. 軟件系統(tǒng)架構(gòu)不僅指定了軟件系統(tǒng)的組織和拓撲結(jié)構(gòu)，而且顯示了系統(tǒng)需求和組件之間的對應(yīng)關(guān)系[5].

1.2 系統(tǒng)架構(gòu)前期總體設(shè)計

由于開發(fā)時間比較緊張，以及初始開通的城市也比較少，所以網(wǎng)約車上報監(jiān)管平臺系統(tǒng)初始的架構(gòu)設(shè)計比較單一，沒有考慮到通用性的設(shè)計模式，具體總體架構(gòu)設(shè)計如圖1所示. 說明:①公司的相關(guān)基礎(chǔ)信息(如經(jīng)營信息、運價信息、許可證信息等)、車輛和司機信息數(shù)據(jù)是通過Excel解析導(dǎo)入到數(shù)據(jù)庫中(注:運營人員從后臺管理系統(tǒng)頁面上傳Excel文件到服務(wù)器，服務(wù)自動解析Excel并把數(shù)據(jù)導(dǎo)入數(shù)據(jù)庫中). ②運營訂單的相關(guān)數(shù)據(jù)是大數(shù)據(jù)部門通過ETL工具(注:ETL工具主要用于大數(shù)據(jù)的抽取、清洗、轉(zhuǎn)換、裝載等)實時導(dǎo)入到數(shù)據(jù)庫中. ③上游服務(wù)通過調(diào)用“心跳服務(wù)”(注：心跳服務(wù)主要是實時傳輸司機車輛的定位數(shù)據(jù)，同時監(jiān)聽司機是否在線. )傳輸司機車輛定位數(shù)據(jù)，“心跳服務(wù)”直接把數(shù)據(jù)寫入kafka里面，然后交通部(地方交管委)上報服務(wù)直接消費kafka里的數(shù)據(jù)傳輸給交通部和地方交管委. ④交通部(地方交管委)上報服務(wù)分別定時去相應(yīng)的數(shù)據(jù)庫撈取未上報數(shù)據(jù)(注:根據(jù)傳輸標志位report_flag進行識別)進行傳輸.

圖1 初始系統(tǒng)架構(gòu)設(shè)計圖

1.3 系統(tǒng)設(shè)計存在的問題

交通部監(jiān)管平臺和地方交管委監(jiān)管平臺存在較大差別. 交通部監(jiān)管平臺是網(wǎng)約車公司必須傳輸?shù)钠脚_，服務(wù)必須部署在Windows系統(tǒng)平臺才能運行，因為交通部傳輸必須連接相應(yīng)的Windows VPN客戶端，不支持Linux操作系統(tǒng). 而地方交管委的監(jiān)管平臺屬于選擇性傳輸?shù)姆绞?，有的地方交管委不需要進行對接，他們是直接拉取交通部的上報數(shù)據(jù)進行監(jiān)管. 而有的地方交管委則單獨做了一套監(jiān)管平臺，要求網(wǎng)約車公司進行傳輸，需要傳輸?shù)膬?nèi)容會比交通部的要多，以實現(xiàn)網(wǎng)約車的精準化管控. 本系統(tǒng)初始對外傳輸方式示意圖如圖2所示，交通部和地方交管委是分開傳輸?shù)?，這里需要說明的是，初始階段由于開通服務(wù)的城市數(shù)量少，開發(fā)時間比較緊，所以沒有充分考慮后續(xù)系統(tǒng)的可擴展性，各個城市的傳輸都是單獨的一套服務(wù)進行部署，數(shù)據(jù)庫也是1城1個，主要考慮到不同的地方交管委傳輸?shù)膬?nèi)容會有差異，而傳輸方式也存在一定的不同之處.

圖2 初始對外傳輸方式示意圖

以上海市傳輸為例，要部署1套交通部的監(jiān)管平臺傳輸?shù)姆?wù)，還要部署1套上海交管委的監(jiān)管平臺傳輸?shù)姆?wù)，共享1個數(shù)據(jù)庫，其他城市以此類推，這樣整個系統(tǒng)的架構(gòu)設(shè)計顯得十分地冗余和臃腫. 隨著公司開城數(shù)量的增加，這樣的系統(tǒng)架構(gòu)已經(jīng)明顯跟不上開城的速度，每開1個城市都得至少部署1個服務(wù)和申請1臺數(shù)據(jù)庫，人力成本和資源成本不斷增加，系統(tǒng)的可擴展性很差.

2 解決方案

2.1 系統(tǒng)架構(gòu)重構(gòu)

針對前述的系統(tǒng)架構(gòu)設(shè)計存在的相關(guān)問題，經(jīng)過慎重的評估，決定對當前系統(tǒng)采取“重構(gòu)”的解決方案. 何謂重構(gòu)?簡單來說，重構(gòu)是對軟件內(nèi)部結(jié)構(gòu)的調(diào)整，目的是在不改變軟件可觀察行為的前提下，提高其理解性，降低其修改成本[6]. 在工程實踐活動中，編程往往考慮的是功能的實現(xiàn)，而重構(gòu)則是在功能實現(xiàn)的基礎(chǔ)上，考慮系統(tǒng)的穩(wěn)定性、性能、可擴展性等.

2.2 可行性分析

系統(tǒng)重構(gòu)前，必須充分分析和評估重構(gòu)的可行性和風(fēng)險. 對此，本文基于如下幾個方面進行了綜合考量，決定進行重構(gòu).

1) 開城數(shù)量. 當前開城數(shù)量在10個左右，并不算太多，處于可控范圍，重構(gòu)后的系統(tǒng)傳輸功能不會受影響.

2) 交通部傳輸. 因為交通部傳輸?shù)膮f(xié)議都是按同1個協(xié)議進行傳輸，沒有什么變化，不同的只是各個城市的城市碼不同，所以多個城市交通部的傳輸可合并成1套.

3) 地方交管委傳輸. 由于不同地方交管委的要求不同，傳輸?shù)膬?nèi)容和傳輸方式都存在差異，所以總的思路是“求同存異”. 把相同之處采用直接合并的方式，不同之處采用擴展的方式，比如字段差異，就進行類中擴字段，再比如傳輸方式差異，就利用“策略模式”(注:1種軟件設(shè)計模式)的設(shè)計模式進行傳輸方式的擴展. 通過2種不同的方式，把地方交管委傳輸也合并成1個服務(wù).

4) 數(shù)據(jù)庫. 由于交通部都是同樣的傳輸協(xié)議，即傳輸內(nèi)容完全一致，所以采用統(tǒng)一的表即可. 而地方交管委傳輸存在一定的差異，針對同樣的上報內(nèi)容，字段的差異，直接在表上進行字段擴展，或者在系統(tǒng)中進行字段轉(zhuǎn)義;針對新增的上報內(nèi)容，直接進行新增表的操作. 這樣交通部和地方交管委的數(shù)據(jù)都可合并在1個數(shù)據(jù)庫中，便于操作和管理.

5)上游服務(wù)影響. 整個系統(tǒng)是采用業(yè)界經(jīng)典的SpringBoot微服務(wù)的架構(gòu),只需要重構(gòu)上報監(jiān)管平臺相關(guān)服務(wù)，由于內(nèi)部系統(tǒng)間沒有傳輸協(xié)議的變動，所以上游服務(wù)不需要進行改動，系統(tǒng)間影響面較小.

6)可擴展性. 后續(xù)開城數(shù)量會越來越多，上報監(jiān)管平臺的對接速度直接影響公司開城拿證的速度，必須提高系統(tǒng)的可擴展性，適應(yīng)開城速度.

7)分布式機制. 上報服務(wù)采用多實例部署，以加速數(shù)據(jù)的傳輸速度，同時為了防止重復(fù)傳輸數(shù)據(jù)，系統(tǒng)通過使用Redis鎖機制，構(gòu)建分布式鎖，分布式鎖是控制分布式系統(tǒng)之間同步訪問共享資源的一種方式[7]. 此外，對每個實例可動態(tài)編組，比如幾個城市為1組，專門消費這個組內(nèi)的數(shù)據(jù)，這樣有利于提升查詢數(shù)據(jù)的效率，也防止瞬間數(shù)據(jù)量巨大，消費慢的問題.

3 重構(gòu)后的系統(tǒng)架構(gòu)

3.1 重構(gòu)后的系統(tǒng)架構(gòu)設(shè)計

圖3為重構(gòu)后的系統(tǒng)架構(gòu)設(shè)計圖，這里與初始架構(gòu)圖中，存在區(qū)別的地方是:①整個系統(tǒng)共享1個數(shù)據(jù)庫，大大節(jié)約了資源，也便于進行維護. ②增加了可配置的頁面，對相關(guān)交通部和地方交管委的傳輸方式、地址等配置進行集中管理，同時在服務(wù)中增加配置變化的監(jiān)聽機制，便于動態(tài)變更配置，提高了系統(tǒng)的動態(tài)性. ③增加定時數(shù)據(jù)清理和重試機制，以及每日統(tǒng)計功能. 對于傳輸成功的數(shù)據(jù)，次日凌晨1點之后先對前1天的訂單數(shù)據(jù)進行統(tǒng)計，然后進行刪除數(shù)據(jù)操作，防止數(shù)據(jù)積壓數(shù)據(jù)庫導(dǎo)致慢查詢. 對于傳輸失敗的數(shù)據(jù)，進行定時恢復(fù)傳輸標志位(注:傳輸標志位report_flag置0)再次重試傳輸. 如果有些數(shù)據(jù)一直傳輸失敗，則可能存在問題數(shù)據(jù)，統(tǒng)一在周日凌晨1點進行刪除.

3.2 重構(gòu)后的效果

重構(gòu)后的上報監(jiān)管平臺系統(tǒng)總體運行平穩(wěn)，系統(tǒng)功能與重構(gòu)前一致，屬于平滑過渡.

表1是重構(gòu)前后相關(guān)指標的對比，具體說明如下：

表1 重構(gòu)前后相關(guān)評價指標對比

1)從可維護性的角度，系統(tǒng)的微服務(wù)數(shù)量從原有的20個下降到3個，服務(wù)器數(shù)量從原有的26個下降到6個，數(shù)據(jù)庫從原有的10個下降到1個，大大降低了維護的難度.

2)從穩(wěn)定性的角度，由于增加了相關(guān)網(wǎng)絡(luò)健康狀態(tài)的監(jiān)控，使得系統(tǒng)上報斷開的平均時間間隔從100 min下降到了2 min，系統(tǒng)的穩(wěn)定性較之前更加穩(wěn)定，數(shù)據(jù)消費更加連續(xù).

3)從傳輸性能的角度，每分鐘傳輸數(shù)據(jù)條數(shù)從10 000提升到25 000條，單次傳輸數(shù)據(jù)包容量從60 KB提高到800 KB，Kafka隊列主題數(shù)量從10個下降到1個，消費的平均延遲時間從30 s下降到5 s，系統(tǒng)的響應(yīng)速度增加，隊列的消費速度加快，上報的及時性得到大幅提升，同時系統(tǒng)CPU的利用率從原來的30%提高到了65%.

4)從可擴展性角度，后續(xù)新增新的城市上報，只需要在頁面進行配置相關(guān)的城市代碼和傳輸?shù)刂芳纯桑麻_城開發(fā)速度從原來的7 d降低到了0.5 d，極大縮短了開城的時間，無需修改代碼，同時也新增了訂單數(shù)據(jù)的統(tǒng)計功能，做到了“開閉原則”.

此外，2021年2月，交通運輸部發(fā)布1月份全國網(wǎng)約車平臺數(shù)據(jù)傳輸情況(見圖4)，當月訂單量超過100萬單的網(wǎng)約車平臺公司中，按雙合規(guī)完成訂單率公司排前3名[8]，這是公司上報系統(tǒng)重構(gòu)后進行數(shù)據(jù)傳輸?shù)慕Y(jié)果. 通過官方公布的數(shù)據(jù)，也從側(cè)面驗證了重構(gòu)后的系統(tǒng)傳輸情況良好，達到了優(yōu)化的效果.

圖4 2021年1月交通部網(wǎng)約車平臺數(shù)據(jù)傳輸情況截圖

4 結(jié)論

軟件系統(tǒng)架構(gòu)設(shè)計對軟件系統(tǒng)的影響是深遠的，良好的系統(tǒng)架構(gòu)設(shè)計是系統(tǒng)運轉(zhuǎn)正常的關(guān)鍵. 本文通過論述網(wǎng)約車上報監(jiān)管平臺的系統(tǒng)架構(gòu)演變過程，理論聯(lián)系實際，使得網(wǎng)約車上報監(jiān)管平臺系統(tǒng)的傳輸性能得到提升. 當然系統(tǒng)的優(yōu)化之路是無止境的，盡管上述的優(yōu)化方案使得系統(tǒng)各方面性能得到大幅提升，但仍存在一些不足. 主要體現(xiàn)在幾個方面:

1)有些基礎(chǔ)數(shù)據(jù)的入庫還是沿用Excel文件導(dǎo)入的方式，不夠智能化，還需要人工的方式，后續(xù)可進行去人工化的改造.

2)對于上報監(jiān)管平臺服務(wù)的多實例分組特性還可繼續(xù)細化，比如根據(jù)不同城市的傳輸性能再進行動態(tài)組合，以達到負載均衡的效果.

3)傳輸過程中對于數(shù)據(jù)的合規(guī)化率還有進一步優(yōu)化空間，可增加對部分數(shù)據(jù)合規(guī)化的校驗.

4)與“滴滴”等大型網(wǎng)約車公司的上報監(jiān)管平臺架構(gòu)相比，當前系統(tǒng)性能還存在一定的差距，因為現(xiàn)階段公司訂單量并沒有達到日均幾千萬單的級別，系統(tǒng)的承載力在可接受范圍內(nèi)，如何承載更大的流量，是今后的一個重要研究課題.

5)當前上報的訂單數(shù)據(jù)是通過ETL工具從訂單數(shù)據(jù)庫實時導(dǎo)入到上報數(shù)據(jù)庫，采用第3方工具，會存在不可控的因素，比如工具出現(xiàn)不工作的場景，導(dǎo)入數(shù)據(jù)過慢等現(xiàn)象. 后續(xù)系統(tǒng)設(shè)計中，考慮加入第3方工具的監(jiān)控，如果出現(xiàn)異常及時發(fā)出告警進行排查和解決.

對于上報監(jiān)管平臺系統(tǒng)的進一步優(yōu)化需要一個持續(xù)迭代集成的過程，不可能畢其功于一役，也要結(jié)合實際的業(yè)務(wù)需求，不能為了優(yōu)化而優(yōu)化.