打车APP技术解决方案
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
打车APP解决方案
需要定制开发一个打车APP,本文档则分别从功能与技术两个方面介绍了该项目的解决方案。
1 预期目标
该项目的想要实现的预期目标其实说起来非常简单,只要通过APP能够完成叫车服务即可,图1描述了该项目的本质需求。
图1 项目需求
从图1中可以看出,本项目的本质需求从大的方面来说其实就三个方面:
❑首先满足用户的打车需求,让用户可以及时获取出行服务,并且可以享受到一些优惠活动。
❑其次要满足司机的载客需求,降低出租车的空载率,增加司机的收入。
❑最后,如果可以,最终在线上完成支出操作,使得可以更好的管理出租车司机。这里可以通过与第三方支付进行合作达到目的。
为了可以更好达成以上需求,通过这三个本质的需求可以引申出来一些周边的辅助需求,主要有一下几点:
❑在匹配用户和司机双方的供需信息时,可以增加一些语音功能,不仅使得用户操作更方便,也使得司机可以在不影响开车的情况下或许信息。
❑增加加价功能,在用户与司机双方认可的前提下,如果遇到比较极端的出行服务,可以适当的
·217·
进行加价,这样可以更高的调动司机的积极性,并且对用户来说也不失公允。
❑在使用完订车服务后,可以增加评价功能,完成评价体系,可以让更好的司机以及更好的乘客脱颖而出,也为出租车公司提供了更好的考核依据。
提示:以上这些功能只是笔者本暂时想到的,如果还有其他需要改动的需求,可以随时增加或修改。
以上这些所有的需求点,在移动互联网时代,通过打车APP的定位功能可以非常高效的满足以上所有的需求。
2 功能框架
通过对预期目标的需求分析,可以很容易的得出本项目的需要实现的功能,图2给出了本项目所有功能点的框架图。
图2 本项目功能框架图
图2详细给出了本项目的功能框架,从大的方面来说可以分为三个端口,分别是司机端、用户端以及企业管理端。
提示:以上功能点只是暂时建议的功能点,除了几个核心的功能点之外,其余所有的辅助功能点都是选购的,例如运营功能,可以后期根据委托方具体的运营需求再进行确定。
2.1 司机端
司机端是出租车司机操作的平台,主要用来满足司机载客的需求,使得出租车的空车率得到降低。司机端主要包含以下几个功能点:
❑一键抢单:当用户发布叫车需求后,临近的可以满足服务的出租车司机可以进行抢单操作,有且只会有1个司机抢到订单。该功能是司机端的核心功能之一
❑语音读单:出租车司机大部分时间是无法去阅读订单内容的,也无法操作手机的,语音读单可以帮助司机更及时方便的了解叫单的内容。
·218·
❑管理功能:其中包括我的订单,我的账务,我的消息以及司机服务排名,这些功能可以帮助司机更好的维护自己的服务历史记录。
2.2 用户端
用户端是出租车公司以及司机为用户提供服务的主要窗口,用户对服务体验的好坏也直接影响了本软件的使用率以及公司整体的业绩。用户端主要包含一下几个功能点:
❑叫车功能:其中有即时叫车功能与语音叫车功能。用户使用该APP的主要目的就是满足其能够及时叫到车的需求,因此本功能是用户端的核心功能之一。在叫车的同时可以附带是否可以拼车,是否给加价等辅助功能。
❑预约功能:用户用车有时候会提前预约订车,例如预约几点去机场等需求,该需求也是用户端核心功能之一。
❑代驾功能:有很多情况用户因为规定无法驾驶自己的汽车,因此通过APP也可以公布自己需要代驾的服务需求。
❑管理功能:其中包括我的订单,我的账务,我的消息等管理功能,方便用户随时查看自己的用车历史记录,除此之外,在每次使用完叫车服务后,还可以对司机进行评价回复。
2.3 企业管理端
这部分主要是让服务提供企业方便的在后台进行运营维护,方便的了解各种数据,为企业的决策提供数据支持,企业管理端主要包含以下几个方面的管理:
❑企业日常管理:该部分主要是可以方便的管理车辆、司机、订单、用户、账务、评价等信息。
除此之外,还可以对出租车进行全局监控。
❑企业运营管理:这里主要是为企业运营提供帮助的功能,其中包括公告,优惠政策、统计报表等功能,通过这些功能不仅方便企业及时做出决策,也可以方便企业做一些线上的活动,刺激用户使用。
❑安全权限:因为所有的数据都在企业管理后台这里,因此这里的数据安全,以及权限管理则非常有必要。
提示:除了以上两个核心管理功能之外,企业管理者还可以方便监控本系统与第三方平台对接的情况。
3 技术体系
为了满足以上的功能需求,需要强而有力的技术体系作为支撑才行,因此技术体系就显得非常重要了。根据本系统的特点,笔者推荐使用RESTful风格来架构整个技术体系,该风格可使得后台所有的功能是以服务的形式统一为前端提供功能支持。图3给出了该项目技术体系。
·219·
图3 本项目技术体系图
通过图3可以看到,本项目的整体技术体系主要氛围三层,分别是前端展现层、API服务层以及物理数据层,下面给出了这三个层主要用途:
❑前段
展现
层:
主要
是为
用户
进行
呈现
信息
的,
这里
的用
户包
括司
机、
客户以及企业管理者,这些用户分别通过手机或者浏览器来访问本系统的各种服务,其中手机端适配当前量大主流的操作系统:Android与IOS。
❑API服务层:该层展现了RESTful架构风格,可以看到所有的功能都以服务的形式独立开来,而这些所有的服务都已API的形式对外呈现,这样前端不管是Android、IOS还是Web都可以按照统一的标准进行访问。
❑物理数据层:这里主要是用来存储数据的地方了,这里提供各种存储数据的方式,其中MySQL 主要用来存储业务数据,redis主要用来存储位置坐标数据,而OS主要用来存储大型二进制数据。
提示:除了以上这些功能以外,还有一些服务中间件,这些中间件虽然不是直接体现在某个功能上,但是可以用来来协调各个服务之间,以及服务层与数据层之间的关系。例如上面提到的MQ服务可以提供消息广播服务,而Cache则可以提供缓存方案,以提高系统的性能。
4 架构体系
按照以上的技术体系结构,这里给出了4种架构体系,这4种架构分别应对不同量级的需求,下面则分别来介绍下这几种架构方案。
4.1 架构方案A
方案A是比较简单的一种方案,由于该方案成本低廉,运维成本则几乎为0,因此该方案是项目初