同城外卖系统：地图定位、配送范围与骑手调度实现方案

很多团队在进行同城外卖系统开发时，前期容易把注意力放在首页、商品展示、购物车这些用户能直接看到的页面。真正进入研发阶段后才会发现，一个外卖订单能否顺利送到用户手中，背后依赖的是地图定位、配送范围计算以及骑手调度三套能力协同工作。

对于同城外卖业务平台而言，这几部分往往比页面开发更考验整体架构设计。

一、地图定位不仅是获取坐标

无论是同城外卖APP还是小程序，定位通常都会接入高德或腾讯地图SDK，但获取经纬度只是第一步。

研发过程中，更重要的是把定位数据转换成业务数据。例如用户当前地址是否属于商家配送区域、骑手距离门店还有多远、预计多久能够送达等，都需要通过地图服务进一步计算。

实际项目中，一般会保存用户收货地址的经纬度，同时将商家位置、骑手实时位置统一采用WGS84坐标系存储，减少不同地图坐标转换带来的误差。

为了降低接口调用次数，热门商家附近的地理数据通常会缓存到Redis，减少重复计算带来的性能压力。

二、配送范围如何设计更灵活

不少刚开始接触外卖业务系统的团队，会采用固定配送半径，例如“5公里以内可配送”。

这种方案实现简单，但实际运营并不灵活。

实际应用中，通常支持多种配送策略，例如：

• 按配送半径计算；
• 按行政区域划分；
• 按地图多边形电子围栏配置；
• 根据不同时间段动态调整配送范围。

例如午高峰可以缩小配送区域，提高履约效率；夜间则适当扩大范围，满足用户下单需求。

如果业务覆盖多个城市，还可以把配送规则抽象成独立配置模块，不同门店读取各自策略，无需修改业务代码。

三、骑手调度不是“谁近派给谁”

很多人理解骑手调度，就是寻找距离最近的配送员。

实际上，一个订单是否派给某位骑手，需要综合多个维度。

例如：

• 当前实时位置；
• 是否在线接单；
• 手中订单数量；
• 配送方向是否顺路；
• 预计送达时间；
• 配送能力等级。

在外卖业务系统中，一般会建立骑手状态中心，骑手APP通过WebSocket持续上传位置，基于Redis Geo快速检索附近骑手，再结合接单状态、配送方向等条件完成匹配。

若每次都直接访问数据库，查询耗时会增加，并发订单较多时也容易形成数据库压力。

四、订单调度采用异步架构更合理

支付成功后，可将订单投递到消息队列，由调度服务异步完成骑手匹配，避免下单接口承担全部业务流程。

常见流程如下：

订单生成 → 写入消息队列 → 调度服务消费订单 → 匹配骑手 → 推送接单通知。

借助RabbitMQ或Kafka，可以把订单创建与调度解耦，即使瞬间产生大量订单，也不会阻塞用户支付流程。

如果首次派单失败，还可以结合延迟队列自动重新分配，减少人工介入。

五、数据同步同样值得关注

一个订单会同时出现在用户端、商家端、骑手端以及管理后台。

如果状态同步不及时，就容易出现商家已经出餐，而用户页面仍显示待接单，或者骑手已经送达，后台数据还没有更新的问题。

因此在外卖业务平台中，可采用事件驱动方式同步订单状态，每次状态变化统一发布消息，各业务模块分别消费更新数据，避免多个系统直接相互调用造成耦合。

六、总结

地图定位决定配送是否可达，配送规则影响运营效率，骑手调度则直接关系到订单履约速度。这三部分虽然属于后台能力，却决定了一套外卖业务系统的整体运行质量。

对于关注相关业务架构设计的开发者来说，相比页面交互，地图服务、配送策略、实时定位以及调度架构更值得提前规划。当这些底层能力设计合理后，面对跑腿、生鲜配送、社区团购等业务场景时，也更容易实现能力共享，并降低后续调整带来的维护压力。