打车APP技术解决方案Word格式.docx

打车APP技术解决方案Word格式.docx

《打车APP技术解决方案Word格式.docx》由会员分享，可在线阅读，更多相关《打车APP技术解决方案Word格式.docx（7页珍藏版）》请在冰豆网上搜索。

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

在匹配用户和司机双方的供需信息时，可以增加一些语音功能，不仅使得用户操作更方便，也使得司机可以在不影响开车的情况下或许信息。

增加加价功能，在用户与司机双方认可的前提下，如果遇到比较极端的出行服务，可以适当的进行加价，这样可以更高的调动司机的积极性，并且对用户来说也不失公允。

在使用完订车服务后，可以增加评价功能，完成评价体系，可以让更好的司机以及更好的乘客脱颖而出，也为出租车公司提供了更好的考核依据。

提示：

以上这些功能只是笔者本暂时想到的，如果还有其他需要改动的需求，可以随时增加或修改。

以上这些所有的需求点，在移动互联网时代，通过打车的定位功能可以非常高效的满足以上所有的需求。

功能框架

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

图本项目功能框架图

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

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

司机端

司机端是出租车司机操作的平台，主要用来满足司机载客的需求，使得出租车的空车率得到降低。

司机端主要包含以下几个功能点：

一键抢单：

当用户发布叫车需求后，临近的可以满足服务的出租车司机可以进行抢单操作，有且只会有个司机抢到订单。

该功能是司机端的核心功能之一

语音读单：

出租车司机大部分时间是无法去阅读订单内容的，也无法操作手机的，语音读单可以帮助司机更及时方便的了解叫单的内容。

管理功能：

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

用户端

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

用户端主要包含一下几个功能点：

叫车功能：

其中有即时叫车功能与语音叫车功能。

用户使用该的主要目的就是满足其能够及时叫到车的需求，因此本功能是用户端的核心功能之一。

在叫车的同时可以附带是否可以拼车，是否给加价等辅助功能。

预约功能：

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

代驾功能：

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

其中包括我的订单，我的账务，我的消息等管理功能，方便用户随时查看自己的用车历史记录，除此之外，在每次使用完叫车服务后，还可以对司机进行评价回复。

企业管理端

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

企业日常管理：

该部分主要是可以方便的管理车辆、司机、订单、用户、账务、评价等信息。

除此之外，还可以对出租车进行全局监控。

企业运营管理：

这里主要是为企业运营提供帮助的功能，其中包括公告，优惠政策、统计报表等功能，通过这些功能不仅方便企业及时做出决策，也可以方便企业做一些线上的活动，刺激用户使用。

安全权限：

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

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

技术体系

为了满足以上的功能需求，需要强而有力的技术体系作为支撑才行，因此技术体系就显得非常重要了。

根据本系统的特点，笔者推荐使用风格来架构整个技术体系，该风格可使得后台所有的功能是以服务的形式统一为前端提供功能支持。

图给出了该项目技术体系。

图本项目技术体系图

通过图可以看到，本项目的整体技术体系主要氛围三层，分别是前端展现层、服务层以及物理数据层，下面给出了这三个层主要用途：

前段展现层：

主要是为用户进行呈现信息的，这里的用户包括司机、客户以及企业管理者，这些用户分别通过手机或者浏览器来访问本系统的各种服务，其中手机端适配当前量大主流的操作系统：

与。

服务层：

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

物理数据层：

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

除了以上这些功能以外，还有一些服务中间件，这些中间件虽然不是直接体现在某个功能上，但是可以用来来协调各个服务之间，以及服务层与数据层之间的关系。

例如上面提到的服务可以提供消息广播服务，而则可以提供缓存方案，以提高系统的性能。

架构体系

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

架构方案

方案是比较简单的一种方案，由于该方案成本低廉，运维成本则几乎为，因此该方案是项目初期推荐选择的方案。

图给出了该方案的架构图。

图架构方案示意图

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

下面给出了该方案的一些参数：

支撑流量上限

机房可以选择公有云服务，例如阿里云。

也可以自购主机、自选机房。

存在的问题：

网络故障、提供商响应不及时。

可以优化方案：

搭建配置服务器，使用直联的形式会一定程度上减少域名带来的问题。

综上所诉，在项目刚开始阶段，用户流量不是很大的情况下，该方式还是比较实用的，性价比比较高的。

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

图给出了方案的架构图。

可以看出，方案在方案的基础之上得到了有效的改善，也由以前单机改为提供负载均衡服务，而服务层则是以集群的形式提供强劲的性能，数据库也做了主从模式的集群化架构方案。

该方案主要有以下特点：

支撑并发流量亿

机房最好自购主机、自选机房，并搭建集群环境。

引入解决空间索引问题。

订单分配系统，则是将服务，分单服务以及坐标数据独立出来，形成订单分配系统独立维护。

增加基于的监控系统，可以监控系统的运行情况，其中包括，基础信息（，内存等）、、、、等

成本在方案基础上有了增加，并且日常需要运维工程师来维护系统。

随着业务量的继续上涨，各种活动的展开，用户流量会越来越多，如果达到全国范围的用户级别的时候，方案就会显得有些力不从心了，此时可以有一下三种办法来应对这个问题：

优化：

逻辑优化、性能瓶颈可以尝试搭建集群轮询，内网带宽极限可以尝试压缩中的数据，分单系统会导致压力过大，这个时候可以适当的进行调整来消去峰值。

柔性：

对系统重新进行分析，看清业务与系统开销的对应关系。

不常用的二级服务选择性的进行停用。

对服务分级，对某些一级服务可以进行降级。

扩容：

数据库硬件升级，服务集群化改造，开发定制化服务算法替代以及。

然而以上这些应对办法，也只是治标不治本，无法根治方案所展现出来的各种问题，而这个时候方案就孕育而生了。

图给出了方案的架构图、

方案的改造成本以及建造会非常高，但是可以根本上解决问题，因此一般情况下不会选择方案，除非做到了滴滴这样全国性出行服务规模。

图只是给出了方案的总览图，其中每一个虚线块都可以成立一个项目组单拉出来进行研发，例如图左下方的数据同步系统，其中包括了集群、集群等。

下面给出了方案的参数特点。

支撑并发流量在亿左右

架构服务化，并且分城市部署，每个重要城市自选机房。

成本则需要的研发团队以及个人左右的运维团队。

支持协议，协议是提出的基于传输控制协议的应用层协议，通过压缩、多路复用和优先级来缩短加载时间。

该协议是一种更加快速的内容传输协议。

使用开发运营模式，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

尝试建立内部私有云，通过云技术、大数据的优势解决一些复杂的问题。

总结

本文档分别从预期目标、功能框架、技术体系以及架构体系这个方面对打车的解决方案进行了系统的描述，让所有人在项目动工之前对项目的总体情况有了大致的了解。

其中架构方案这里也从简单到复杂给出了三套架构方案，以适合企业不同时期的发展，并满足了软件的可扩展性。