導讀

本地生活物流配送場景下，騎手室內即配狀態的識別一直是一個難點，室內場景識別比室外場景識別更加複雜。但室內環境卻是一個可以通過鋪設物聯網信標設備的方式，從一個維度很好的表徵騎手在室內的某些行為和狀態。

除此之外，物聯網信標可以為本地生活近場交互提供線下抓手，針對騎手、商家、用戶、其他設備之間的交互，提供個性化服務。

術語

• 近場交互：近距離的設備和設備之間的一種交互方式。
• beacon：蘋果公司提出的一種低功耗藍牙協議，這裡指承載beacon協議的藍牙設備。

• • UUID：規定為ISO/IEC11578:1996標準的128位標識符。
  • Major和Minor：由iBeacon發佈者自行設定，都是16位的標識符。
  • Measured Power：iBeacon模塊與接收器之間相距1m時的參考接收信號強度。

• 實體beacon：離線的beacon設備，無法與服務器取得聯繫，廣播協議按照約定算法完成，符合預期即可。
• 虛擬beacon：在線的beacon設備，可以與服務器取得聯繫，受服務器控制。
• 蜻蜓beacon：螞蟻的蜻蜓機具廣播的beacon。
• seed：beacon加密的種子，64位長度16進制數字。
• beacon加密算法：一個無法逆向的算法，支持seed計算成為majorminor信息的算法。

一、項目背景

1.1. 業務痛點體感

餓了麼在物流配送過程中一直存在一個無法解決的業務痛點：商家大量投訴騎手提前點到店、延後點取餐，但是常規的GPS判責騎手與商戶距離的方案，無法解決這一問題。

1.2. 歷史方案

騎手履約的常規流程包含：接單、到店、取餐、送達，除了接單之外，其餘流程均需要騎手主動操作完成狀態之間的變更，如騎手真實到店後，需要主動在蜂鳥APP中點擊「騎手到店」。

蜂鳥app在騎手配送過程中採集gps信息，在騎手點擊到店時，如果騎手與商戶之間的gps距離小於 一定較長距離，那麼可以判斷騎手到店。

1.2.1. 既有問題

• 距離 一定較長距離 點擊到店並不是真實到店，缺乏判責依據
• 室內沒有GPS信號，室外GPS漂移較大，騎手精確定位一直以來都是業務痛點；
• 以上海近鐵廣場為例（採集近鐵廣場一週內的數據定位信息）：

• • 部分的GPS原始打點數據會出現漂移
  • 大量漂移GPS數據誤差較大
  • 只提供二維經緯度，高度信息不可用，無法確定與商戶之間的準確距離

1.3. 物流痛點表現

• 騎手調度的質量和效率大打折扣
• 問責缺乏裁決依據
• 風控缺乏監督機制
• 騎手缺乏評判

二、項目方案簡介

2.1. 基於物聯網信標技術的解決方案

利用基於物聯網信標近場通訊的解決方案，讓商家與騎手雙方的設備產生交互，縮短交互產生的距離，識別真實到店場景。

2.1.1. 信標技術選型

主流的物聯網信標主要分為藍牙iBeacon與Wi-Fi兩類信標。信標設備標記並廣播自己，掃描者掃描到約定的信標信息後，即可認為與信標設備發生了近場交互。

由於Wi-Fi輻射範圍廣，半徑長，空曠地帶可達200米；基於藍牙的iBeacon協議可能更佔優勢，由於藍牙設備主要靠手動鋪設，可以控制iBeacon設備的信號強度，控制設備發生近場交互的最遠距離（<30米），達到騎手與商戶近場交互距離可控的目的。

2.1.2. 技術方案runtime圖

beacon發射端：發射beacon信號的設備，包含實體beacon與虛擬beacon sdk

實體beacon按照與後端約定好的變更規律與算法，發射beacon信標廣播

虛擬beacon sdk主要植入商戶app，由商戶app發射beacon信標廣播，具體信息由後端控制

beacon接收端：掃描與接收beacon的設備，主要為嵌入

雲端：餓了麼雲端Service

2.1.3. 騎手判責產品方案

2.1.3.1. 事中到店

騎手在配送過程中，如果 該店部署beacon，如果 gps 漂移 但監聽到beacon信號，那麼自動到店；如未自動到店，騎手點擊到店時 未掃描到beacon信號，那麼騎手沒有可能到店，需要拍照舉證。

2.1.3.2. 事後判責

騎手配送完成後，如點擊到店前後一定時間範圍內未監聽到該店beacon，但是在這之後監聽到beacon，那麼未提前點擊到店，業務可判罰。

如下圖所示，如採用信標判責方案，

• • 如AB區間掃描到信標，那麼可視為騎手合規到店
  • 如AB區間未掃描信標，C區間掃描到信標，那麼可視為騎手違規

2.2. 項目收益

2.2.1. 物流業務收益

• 為騎手判責提供更精確的依據，改變騎手違規行為
• 減少騎手手機操作次數
• 支持風控對異常單的監控
• 提高基於室內位置的送單、取單分配效率
• 騎手根據beacon進行軌跡打點

2.2.2. 其他收益

信標技術可以作為本地生活近場交互的線下抓手，不侷限於騎手到店。

最終可以將設備抽象為兩類：

信標發送者，發送自身標記，可能夾帶其他信息

信標接收者，可能預存儲需要掃描的信標信息，掃描周圍信息，根據掃描到的信息觸發業務

2.2.2.1. BD到店拜訪

BD端app嵌入 beacon接收端sdk。

BD到店拜訪時，如GPS漂移但掃描到beacon信號，可以認為BD到店，無需舉證。

BD到店拜訪時，可根據採集beacon信號時長，作為拜訪質量做評估依據。

2.2.2.2. 物流調度

基礎數據沉澱後提供給物流調度使用，相較於GPS，覆蓋到的訂單幫助 餐廳等待時間（ETS） 取餐誤差修正 幾十秒。

2.2.2.3. 商戶端感知小程序

向商家提供可感知的商戶端小程序，商家可感知自己購買的實體設備的綁定情況以及本店設備監控下騎手歷史違規情況。

2.2.2.4. xxx項目測溫設備

餓了麼物流配送支持 xxx項目配送。其中，在該項目的物流配送過程中，需採集配送餐箱溫度，追蹤餐品質量。這裡測溫設備採用beacon協議，發送beacon信標，其中一部分信息標記自己，一部分信息標記溫度與電量等信息，騎手採集後上傳雲端，由雲端存儲數據並處理業務邏輯。

2.2.2.5. 助力老人找回

提供給老人beacon設備，由老人作為beacon協議的載體，如騎手監聽到信息，可以記錄騎手在具體的時間段與老人設備發生近場交互，如老人走失，可作為跟蹤信息，助力老人找回。

2.2.2.6. 專利產出

共產出5篇專利，已交局，正在審批。

三、技術架構

信標系統歷經最初僅為解決物流痛點，到後來向各業務賦能的過程中。

• 移動端/邊緣計算部分抽象成為生產者與消費者的模式

• • 信標能力生產者，如商戶端，提供信標能力，發射廣播信號
  • 信標能力消費者，如騎手app，掃描信標消費

• 後端逐漸發展出以下模塊，並在最上面封裝一層薄薄的業務域

• • 管理系統模塊
  • 租戶系統模塊
  • 設備管理模塊
  • 信標基礎能力
  • 消息中心

3.1. 設備管理模塊

在設計之初，由於該項目屬於物聯網項目，我們調研了阿里雲以及其IOT平臺，期望可以借用其 設備管理能力，但是由於其設備管理能力僅支持嵌入式設備與安卓設備，無法支持ios等設備，並且由於固定的三元組信息等無法完美的支持該項目業務，我們在這裡自研一個簡單的設備管理模塊。

3.2. 消息中心

信標平臺設計之初並沒有消息中心的概念，僅為一個實時解析騎手上傳掃描beacon信息將其逆向並存儲至ODPS的模塊。

隨著業務的發展，及幾次非後端導致的故障出現，印象最深的兩次故障：

• • 數據重複上傳

• • • 接收端sdk一句數據庫語句的錯誤，導致其上傳掃描信息後，認為上傳失敗，但其實是上傳成功的，重複的數據會不停的上傳至後端服務。最終由於流量過高CPU報警。
    • 當時的go服務不支持限流。
    • 不管是否限流，移動端均會不停的上傳數據，後端與移動端均會存在隱患。
    • 臨時的解決方案是後端緊急擴容以及使用開關關閉 問題版本接收端sdk。

• • 接收端sdk規劃將歷史冗餘數據全部上傳雲端

• • • 接收端同事規劃並落實將歷史冗餘數據全部上傳雲端，但未通知後端同事；大家樂觀的估計冗餘數據存量，一致認為現有服務器完成能夠承受。最終，服務端又一次CPU報警。
    • 臨時的解決方案是，根據當前的設備數量以及未來的新版本設備數量建設容量模型，跟公司緊急申請足夠的機器，應對了此次危機。

在此同時，餓了麼由於上雲需求，所有後端服務均需要開展python/go->java服務的遷移，基於這樣的背景下，除了可以使用java框架提供的限流等功能，在重構過程中，參考阿里雲IOT、微軟azure等IOT平臺，設計了消息中心。提供數據上傳後，將消息緩存在blink/mq中間件做異步處理的能力，在儘量不做限流的同時，提高系統的魯棒性。

出於穩定性的考慮，我們優先選型blink作為消息中心的中間件。不過調研過程中，我們發現當時blink與餓了麼db還存在未打通無法直連的情況，於是將選型mq作為消息中心中間件，Runtime架構圖如下：

3.3. 軟件架構

3.3.1. 領域設計

這是一個粗略的領域設計

3.3.2. 邏輯架構

3.3.3. 系統架構

四、後記

4.1. 遇到過的問題

4.1.1. 技術問題

問題描述：

後端實時解析移動端掃描到的信標cpu開銷比較高，遇到過一些外界因素導致的故障，除了限流、擴容，是否還有別的方式去做？

解決方案：

• • 與移動端溝通可識別故障的降級方案，移動端發生故障時進行訪問降級。
  • 消息中心的建立，利用MQ中間件的能力，儘可能將高峰期無法處理的可異步響應數據請求進行異步處理，提高系統魯棒性。
  • 建設全鏈路監控，增加cpu異常、請求延時、qps異常等監控。

4.1.2. 產品問題

問題描述：

判責一期提供事中判責，騎手點擊到店時，如未接收到信號，需要強行拍照舉證，否則違規，在高峰期影響騎手配送效率的同時對騎手體驗很不好。

解決方案：

推動物流判責二期上線，取消beacon不能100%覆蓋對騎手帶來的拍照要求，對可能違規的騎手做弱警告提示，不再強行要求騎手拍照舉證。

4.2. 一些思考

4.2.1. 系統能力較耦合

現狀：信標平臺同時集成了業務系統、設備管理、消息採集等職能，整個系統耦合設備管理和消息採集的職能，這些職能不屬於領域能力。

解決方式：待信標系統發展壯大後，對能力進行區分、遷移與治理

• • 設備管理和消息採集下沉至本地生活AIOT平臺的基礎服務層 
  • 業務數據建模能力拆分至數據平臺

4.2.2. 聯合信標

背景：單個信標覆蓋率較低，對於事中騎手到店判責而言較為嚴苛，聯合信標的建立，有利於提高騎手合規檢測率，減少事中誤提醒。

方案：基於騎手在配送過程中採集的信標數據，清洗並沉澱，建立信標網絡模型，騎手到店時，只需要掃描到信標網絡中的任一信標，即可判斷為到店；降低騎手到店誤判率，減輕騎手負擔。