打车APP技术解决方案

打车APP 解决方案

需要定制开发一个打车APP，本文档则分别从功能与技术两个方面介绍了该项目的解决方案。

1 预期目标

该项目的想要实现的预期目标其实说起来非常简单，只要通过APP 能够完成叫车服务即可，图1 描述了该项目的本质需求。

图 1 项目需求

从图 1 中可以看出，本项目的本质需求从大的方面来说其实就三个方面： 首先满足用户的打车需求，让用户可以及时

获取出行服务，并且可以享受到一些优惠活动。 其次要满足司机的载客需求，降低出租车的空载率，增加司机的

收入。 最后，如果可以，最终在线上完成支出操作，使得可以更好的管理出租车司机。这里可以通过 与第三方支

付进行合作达到目的。

为了可以更好达成以上需求，通过这三个本质的需求可以引申出来一些周边的辅助需求，主要有一 下几点：

在匹配用户和司机双方的供需信息时，可以增加一些语音功能，不仅使得用户操作更方便，也 使得司机可以在不

影响开车的情况下或许信息。

增加加价功能，在用户与司机双方认可的前提下，如果遇到比较极端的出行服务，可以适当的 进行加价，这样可

以更高的调动司机的积极性，并且对用户来说也不失公允。

在使用完订车服务后，可以增加评价功能，完成评价体系，可以让更好的司机以及更好的乘客 脱颖而出，也为出

租车公司提供了更好的考核依据。

提示：以上这些功能只是笔者本暂时想到的， 如果还有其他需要改动的需求， 可以随时增加或修改。 以上这些所有的需求点，在移动互联网时代，通过打车 APP 的定位功能可以非常高效的满足以上 所有的需求。

2 功能框架

通过对预期目标的需求分析，可以很容易的得出本项目的需要实现的功能，图 功能点的框架

图。

图 2 本项目功能框架图

2 给出了本项目所有

图2 详细给出了本项目的功能框架，从大的方面来说可以分为三个端口，分别是司机端、用户端以及企业管理端。

提示：以上功能点只是暂时建议的功能点，除了几个核心的功能点之外，其余所有的辅助功能点都是选购的，例如运营功能，可以后期根据委托方具体的运营需求再进行确定。

2.1 司机端

司机端是出租车司机操作的平台，主要用来满足司机载客的需求，使得出租车的空车率得到降低。司机端主要包含以下几个功能点：

一键抢单：当用户发布叫车需求后，临近的可以满足服务的出租车司机可以进行抢单操作，有且只会有1 个司机抢到订单。该功能是司机端的核心功能之一语音读单：出租车司机大部分时间是无法去阅读订单内容的，也无法操作手机的，语音读单可以帮助司机更及时方便的了解叫单的内容。

管理功能：其中包括我的订单，我的账务，我的消息以及司机服务排名，这些功能可以帮助司机更好的维护自己的服务历史记录。

2.2 用户端

用户端是出租车公司以及司机为用户提供服务的主要窗口，用户对服务体验的好坏也直接影响了本软件的使用率以及公司整体的业绩。用户端主要包含一下几个功能点：

叫车功能：其中有即时叫车功能与语音叫车功能。用户使用该APP 的主要目的就是满足其能够及时叫到车的需求，因此本功能是用户端的核心功能之一。在叫车的同时可以附带是否可以拼车，是否给加价等辅助功能。

预约功能：用户用车有时候会提前预约订车，例如预约几点去机场等需求，该需求也是用户端核心功能之一。

代驾功能：有很多情况用户因为规定无法驾驶自己的汽车，因此通过APP 也可以公布自己需要

前段

展现

层：

主要

是为

用户

进行

呈现

信息

的，

这里

的用

户包

代驾的服务需求。

管理功能：其中包括我的订单，我的账务，我的消息等管理功能，方便用户随时查看自己的用 车历史记录，除此

之外，在每次使用完叫车服务后，还可以对司机进行评价回复。

2.3 企业管理端

这部分主要是让服务提供企业方便的在后台进行运营维护，方便的了解各种数据，为企业的决策提 供数据支持，企业管理端主要包含以下几个方面的管理：

企业日常管理：该部分主要是可以方便的管理车辆、司机、订单、用户、账务、评价等信息。 除此之外，还可以

对出租车进行全局监控。

企业运营管理：这里主要是为企业运营提供帮助的功能，其中包括公告，优惠政策、统计报表 等功能，通过这些

功能不仅方便企业及时做出决策，也可以方便企业做一些线上的活动，刺激 用户使用。

安全权限：因为所有的数据都在企业管理后台这里，因此这里的数据安全，以及权限管理则非 常有必要。

提示：除了以上两个核心管理功能之外，企业管理者还可以方便监控本系统与第三方平台对接的情 况。

3 技术体系

为了满足以上的功能需求，需要强而有力的技术体系作为支撑才行，因此技术体系就显得非常重要 了。根据本系统的特点，笔者推荐使用 RESTful 风格来架构整个技术体系，该风格可使得后台所有的功 能是以服务的形式统一为前端提供功能支持。图 3 给出了该项目技术体系。

图 3 本项目技术体系图

通过图 3 可以看到，本项目的整体技术体系主要氛围三层，分别是前端展现层、 理数据层，下

面给出了这三个层主要用途：

括司机、客户以及企业管理者，这些用户分别通过手机或者浏览器来访问本系统的各种服务， 其中手机端适配当

前量大主流的操作系统： Android 与 IOS 。

API 服务层以及物

API 服务层：该层展现了RESTful 架构风格，可以看到所有的功能都以服务的形式独立开来，而这些所有的服务都已API 的形式对外呈现，这样前端不管是Android 、IOS 还是Web 都可以按照统一的标准进行访问。

物理数据层：这里主要是用来存储数据的地方了，这里提供各种存储数据的方式，其中MySQL 主要用来存储业务数据，redis 主要用来存储位置坐标数据，而OS 主要用来存储大型二进制数据。

提示：除了以上这些功能以外，还有一些服务中间件，这些中间件虽然不是直接体现在某个功能上，但是可以用来来协调各个服务之间，以及服务层与数据层之间的关系。例如上面提到的MQ 服务可以提供消息广播服务，而Cache 则可以提供缓存方案，以提高系统的性能。

4 架构体系

按照以上的技术体系结构，这里给出了4 种架构体系，这4 种架构分别应对不同量级的需求，下面则分别来介绍下这几种架构方案。

4.1 架构方案A

方案A 是比较简单的一种方案，由于该方案成本低廉，运维成本则几乎为0，因此该方案是项目初

期推荐选择的方案。图4 给出了该方案的架构图。

图 4 架构方案 A 示意图

通过图4 可以看出本方案是非常简单的方案，因为架构简单，使得该方案非常容易维护，成本也非常低廉，但同时，该方案也无法支撑高并发的需求。下面给出了该方案的一些参数：

支撑流量上限100W 机房可以选择公有云服务，例如阿里云。也可以自购主机、自选IDC 机房。存在的问题：IDC 网络故障、IDC 提供商响应不及时。

可以优化方案：搭建配置服务器，使用IP 直联的形式会一定程度上减少域名带来的问题。综上所诉，在项目刚开始阶段，用户流量不是很大的情况下，该方式还是比较实用的，性价比比较高的。

4.2 架构方案B

随着业务的发展，流量逐步达到了单机的极限，如果并发流量超过100W 的时候，方案A 就无法满足需求，而方案B 则在A 的基础上进行了扩充，使用集群来处理高并发的业务需求。图5 给出了方案B 的架构图。