李智慧 · 高并发架构实战课
李智慧
同程艺龙交通首席架构师,前 Intel & 阿里架构师,《大型网站技术架构》作者
23286 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 26 讲
李智慧 · 高并发架构实战课
15
15
1.0x
00:00/00:00
登录|注册

20 | 网约车系统设计:怎样设计一个日赚 5 亿的网约车系统?

动态派单优化算法
用户反馈系统
实时交通数据分析
地理系统集成
司机的服务评价
路况信息
乘客的等待时间
司机的空闲状态
司机和乘客的距离
网约车业务
金融业务
电商业务
分布式缓存
消息队列
编程框架
编程语言
已取消
已完成
待支付
行程中
已派单
派单中
创单
整体时间最小化原则
订单聚合池和聚合桶
地理系统路径规划
行驶距离代替空间距离
城市和城区作为基本单位
Redis的GeoHash命令
GeoHash算法
Redis集群
ZooKeeper服务器
TCP管理服务器集群
TCP协议
消息推送服务
派单引擎
分单子系统
地理位置服务
TCP连接服务器集群
消息队列
微服务
网关集群
负载均衡服务器集群
司机App:接单
乘客App:叫车
实现方法
派单时考虑的因素
业务相关技术
通用技术
订单状态模型
派单算法
距离计算
长连接管理
系统架构
两个App应用
日活司机:2千万
注册司机:5千万
平台日收益:5.4亿元
平台分成比例:3:7
平台日营收:18亿元
客单价:30元
日订单量:6千万
日活用户:5千万
注册乘客:5亿
思考题
小结
详细设计
概要设计
需求分析
网约车系统设计

该思维导图由 AI 生成,仅供参考

你好,我是李智慧。
网约车的官方定义是:“以互联网技术为依托,构建服务平台,整合供需信息,使用符合条件的车辆和驾驶员,提供非巡游的预约出租汽车服务的经营活动。”通俗地说就是:利用互联网技术平台,将乘客的乘车信息发送给合适的司机,由司机完成接送乘客的服务。网约车包含专车、快车、拼车等多种形式。
中国目前网约车用户规模约 5 亿,我们准备开发一个可支撑目前全部中国用户使用的网约车平台,应用名称为“Udi”。

需求分析

Udi 是一个网约车平台,核心功能是将乘客的叫车订单发送给附近的网约车司机,司机接单后,到上车点接乘客并送往目的地,到达后,乘客支付订单。根据平台的分成比例,司机提取一部分金额作为收益,用例图如下:
Udi 平台预计注册乘客 5 亿,日活用户 5 千万,平均每个乘客 1.2 个订单,日订单量 6 千万。平均客单价 30 元,平台每日总营收 18 亿元。平台和司机按 3:7 的比例进行分成,那么平台每天可赚 5.4 亿元。
另外,平台预计注册司机 5 千万,日活司机 2 千万。

概要设计

网约车平台是共享经济的一种,目的就是要将乘客和司机撮合起来,所以需要开发两个 App 应用,一个是给乘客的,用来叫车;一个是给司机的,用来接单。Udi 整体架构如下图:
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

网约车系统设计是一个复杂的技术挑战,本文介绍了一个名为“Udi”的网约车平台的设计思路。该平台旨在支持5亿用户规模的网约车服务,涉及乘客叫车、司机接单、订单处理等多个方面。文章详细介绍了平台的需求分析、概要设计和详细设计,重点讨论了长连接管理、派单算法和距离计算等技术特点。其中,长连接管理涉及TCP连接服务器集群、ZooKeeper和Redis的使用,而距离计算则利用了Redis的GeoHash算法。这些技术特点展现了该网约车系统设计的复杂性和创新性,对于理解网约车系统的技术架构和挑战具有重要参考价值。 派单算法是网约车系统中的关键技术,需要考虑乘客上车点距离、司机到达时间等因素,以最小化整体时间为原则进行派单。订单状态模型则帮助总览核心业务流程,确保业务流程完备。文章还提到了技术人员在职业生涯中需要关注通用性技术和业务相关技术的重要性,以及如何在业务上获得更多沉淀。 总的来说,本文通过介绍Udi网约车平台的设计思路和关键技术,为读者展示了网约车系统设计的复杂性和创新性,以及技术人员在职业生涯中需要关注通用性技术和业务相关技术的重要性。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《李智慧 · 高并发架构实战课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(16)

  • 最新
  • 精选
  • 👽
    思考题: 我觉得,还需要考虑取消订单后判责与信用分问题,派单优先级问题,司机乘客沟通纪录留档问题。 订单是可以取消的,司机取消或者乘客取消。只要不是正常完成的订单。就需要系统进行判责,并影响整体信用分。并关联到派单优先级。 然后是派单优先级。要考虑被投诉次数,司机接单数量,乘客下单数量,等多维角度,决定订单的优先级。以合理杀熟。 网约车系统是一个法律风险敏感的系统。司机乘客在线沟通纪录必须保存之外。还需要一个语音电话中转的功能,并且留存语音通话记录一段时间备查。然后这里会涉及一个音频文件压缩与存储的设计。

    作者回复: 赞

    2022-04-06
    5
  • My
    1、这里不光有距离计算,像现在的dd司机端都线路计算,区域计算,还有顺风车等业务。(单纯的geo的计算是否过于简单?另外,如果像北京这种城市,假如跨区域后的路线,这个时候该怎么计算距离(redis跨key局限)) 2、这里面从架构师来讲应该做到哪一步 才算完事儿,因为单纯的详细设计上并没有真正能落地的事项呢?

    作者回复: 1 派单的距离计算和路线规划是不同的服务完成,派单时只需选择就近的司机。司机跨区的时候将司机放入不同的区的key即可。 2 设计要到工程师可以按照设计完成开发的地步,根据工程师技能水平,设计的细节程度会有很大差别

    2022-04-17
    4
  • peter
    请教老师几个问题: Q1:订单数量应该是整数,平均订单数怎么会是小数1.2呢? Q2:TCP长连接: A 司机日活2千万,TCP连接服务器需要多少台?(或者说,通常情况下一台服务器支持多少TCP连接?) B TCP连接有现成的框架吗? C TCP连接的实现,就是用Socket吗?(以Java为例,安卓APP端:new Socket; socket.connect(serverInitAddr); 服务器端:new ServerSocket(port),serverSocket.accept()) Q3:安卓客户端怎么能够获取车头方向? Q4:系统中的zookeeper是用Zookeeper的什么功能?可用什么替换?

    作者回复: 1 5个人下了6个订单~ 2 A linux缺省连接数上限是65535,不修改linux参数的话需要300台。B Netty C 是的 3 手机有指南针功能 4 这里主要用来做TCP连接服务器心跳检测,目前的作用有点鸡肋的,可以去掉的。

    2022-04-04
    2
    2
  • 感觉这个网约车结构跟我现在做的agv调度系统有很多相似之处,比如网约车的订单是以"桶"的形式将乘客与司机进行匹配,在agv调度系统中,也是以轮询的形式,每过多少秒收集一次未执行的任务,与agv的当前坐标进行计算,算出最合适的匹配方式;比如这个订单的状态模型,跟agv任务的状态模型不能说一模一样,简直就是完全一致,看来即便是业务系统,也是有很多相通之处; 至于为什么任务是成批次的下发,也很好理解,如果任务是单个下发的话,视角就会被限制在"订单视角"或者"司机视角",无法达到全局最优,就会遇到"给乘客分配距离最新的司机",还是"给司机分配距离最近的乘客"这样的问题,而如果改变成批处理的话,至少可以得到某一时刻的"全局最优"; 派单过程中的问题,在agv系统中,可能会有任务优先级,任务等待时间,任务要求的车型,agv电量,agv是否可通行等需要考虑的项,我想网约车系统中应该也类似。

    作者回复: 赞

    2023-06-12归属地:北京
    1
  • 老师,返回某台tcp连接服务器的IP地址和端口给到司机app客户端,这样暴露服务器IP和端口信息安全吗?如何保证安全?另外司机端app应该也需要登录注册吧,登录注册流程应该也是通过http交互的,那么我看上面的司机app流程图中一启动就创建长链接了,登录流程应该怎么实现?

    作者回复: TCP连接服务器类似负载均衡服务,只提供通信功能,没有业务逻辑,所以安全防护方面可以做的更强大一点。 是的,司机App也需要登录注册,应该通过HTTP和负载均衡服务器完成,图中为了简化省略了这条线。

    2022-05-29
    1
  • HappyHasson
    请教两个问题: 1. tcp管理服务集群,什么时候会去redis删除司机映射关系,架构图里好像看不出来? 2. 用户端app是htt链接,订单状态改变了,乘客怎么及时获取到,app定时的pull订单状态?

    作者回复: 1 司机app重新连接的时候,删除旧的映射,写入新的映射。文中有说明。 2 App在后台的时候通过消息推送通知订单状态,App打开状态定时轮询。

    2022-04-08
    3
    1
  • Steven
    回答问题: 场景1:乘客下单,没有司机接单。 方案:1扩大距离范围寻找合适的司机;2提高司机分成比例,以激励司机接单。 场景2:乘客下单,能接单的司机距离太远 方案:1用户端做好用户体验,时间长和感觉上时间长是两回事;2适当给用户抵值券。 btw,这节课与期中测试题很类似,是应编辑要求提供给大家抄作业的吗?哈哈,开玩笑的。

    作者回复: 赞。 哈哈,大家踊跃交作业啊,自己动手写一个文档,感觉会非常不一样的。

    2022-04-05
    2
    1
  • 王辉
    老师请教一个问题,希望帮忙解答下: 1.高并发下,如何保证两条订单不会匹配到同一个司机?

    作者回复: 高并发的订单最后都会进入到派单引擎,派单引擎做好司机状态管理就可以,应该没什么技术挑战的。

    2022-05-02
  • ABC
    其实还需要考虑,乘车安全,用户隐私保护(联系电话),排队问题,这些。 另外有个问题,比如像某导航软件,里面的打车应用聚合了上百家打车软件,他是怎么实现的呢?

    作者回复: 大部分网约车平台都有2B的供应商接口的,通过商务谈判调用接口就可以聚合各家打车服务的。

    2022-04-28
  • 逐风
    老师能加个餐拓展讲讲本文地理系统的设计吗

    作者回复: 电子地图也是一个比较大的应用类别了,后面有机会可以写一下,也欢迎有兴趣的同学写了发上来,大家一起交流学习。

    2022-04-04
收起评论
显示
设置
留言
16
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部