导读

本地生活物流配送场景下，骑手室内即配状态的识别一直是一个难点，室内场景识别比室外场景识别更加复杂。但室内环境却是一个可以通过铺设物联网信标设备的方式，从一个维度很好的表征骑手在室内的某些行为和状态。

除此之外，物联网信标可以为本地生活近场交互提供线下抓手，针对骑手、商家、用户、其他设备之间的交互，提供个性化服务。

术语

• 近场交互：近距离的设备和设备之间的一种交互方式。
• 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. 联合信标

背景：单个信标覆盖率较低，对于事中骑手到店判责而言较为严苛，联合信标的建立，有利于提高骑手合规检测率，减少事中误提醒。

方案：基于骑手在配送过程中采集的信标数据，清洗并沉淀，建立信标网络模型，骑手到店时，只需要扫描到信标网络中的任一信标，即可判断为到店；降低骑手到店误判率，减轻骑手负担。