打车APP技术解决方案

打车APP解决方案须要定制开发一个打车APP，本文档则分别从功能与技术两个方面介绍了该项目的解决方案。预期目标该项目的想要实现的预期目标其实说起来特别简洁，只要通过APP能够完成叫车服务即可，图1描述了该项目的本质需求。图1 项目需求从图1中可以看出，本项目的本质需求从大的方面来说其实就三个方面：首先满意用户的打车需求，让用户可以刚好获得出行服务，并且可以享受到一些实惠活动。其次要满意司机的载客需求，降低出租车的空载率，增加司机的收入。最终，假如可以，最终在线上完成支出操作，使得可以更好的管理出租车司机。这里可以通过与第三方支付进行合作达到目的。为了可以更好达成以上需求，通过这三个本质的需求可以引申出来一些周边的协助需求，主要有一下几点：在匹配用户和司机双方的供需信息时，可以增加一些语音功能，不仅使得用户操作更便利，也使得司机可以在不影响开车的状况下或许信息。增加加价功能，在用户与司机双方认可的前提下，假如遇到比较极端的出行服务，可以适当的·217·进行加价，这样可以更高的调动司机的主动性，并且对用户来说也不失公允。在运用完订车服务后，可以增加评价功能，完成评价体系，可以让更好的司机以及更好的乘客脱颖而出，也为出租车公司供应了更好的考核依据。提示：以上这些功能只是笔者本短暂想到的，假如还有其他须要改动的需求，可以随时增加或修改。以上这些全部的需求点，在移动互联网时代，通过打车APP的定位功能可以特别高效的满意以上全部的需求。功能框架通过对预期目标的需求分析，可以很简洁的得出本项目的须要实现的功能，图2给出了本项目全部功能点的框架图。图2 本项目功能框架图2具体给出了本项目的功能框架，从大的方面来说可以分为三个端口，分别是司机端、用户端以及企业管理端。提示：以上功能点只是短暂建议的功能点，除了几个核心的功能点之外，其余全部的协助功能点都是选购的，例如运营功能，可以后期依据托付方具体的运营需求再进行确定。2.1 司机端司机端是出租车司机操作的平台，主要用来满意司机载客的需求，使得出租车的空车率得到降低。司机端主要包含以下几个功能点：一键抢单：当用户发布叫车需求后，接近的可以满意服务的出租车司机可以进行抢单操作，有且只会有1个司机抢到订单。该功能是司机端的核心功能之一语音读单：出租车司机大部分时间是无法去阅读订单内容的，也无法操作手机的，语音读单可以帮助司机更刚好便利的了解叫单的内容。·218·管理功能：其中包括我的订单，我的账务，我的消息以及司机服务排名，这些功能可以帮助司机更好的维护自己的服务历史记录。2.2 用户端用户端是出租车公司以及司机为用户供应服务的主要窗口，用户对服务体验的好坏也干脆影响了本软件的运用率以及公司整体的业绩。用户端主要包含一下几个功能点：叫车功能：其中有即时叫车功能与语音叫车功能。用户运用该APP的主要目的就是满意其能够刚好叫到车的需求，因此本功能是用户端的核心功能之一。在叫车的同时可以附带是否可以拼车，是否给加价等协助功能。预约功能：用户用车有时候会提前预约订车，例如预约几点去机场等需求，该需求也是用户端核心功能之一。代驾功能：有许多状况用户因为规定无法驾驶自己的汽车，因此通过APP也可以公布自己须要代驾的服务需求。管理功能：其中包括我的订单，我的账务，我的消息等管理功能，便利用户随时查看自己的用车历史记录，除此之外，在每次运用完叫车服务后，还可以对司机进行评价回复。2.3 企业管理端这部分主要是让服务供应企业便利的在后台进行运营维护，便利的了解各种数据，为企业的决策供应数据支持，企业管理端主要包含以下几个方面的管理：企业日常管理：该部分主要是可以便利的管理车辆、司机、订单、用户、账务、评价等信息。除此之外，还可以对出租车进行全局监控。企业运营管理：这里主要是为企业运营供应帮助的功能，其中包括公告，实惠政策、统计报表等功能，通过这些功能不仅便利企业刚好做出决策，也可以便利企业做一些线上的活动，刺激用户运用。平安权限：因为全部的数据都在企业管理后台这里，因此这里的数据平安，以及权限管理则特别有必要。提示：除了以上两个核心管理功能之外，企业管理者还可以便利监控本系统与第三方平台对接的状况。技术体系为了满意以上的功能需求，须要强而有力的技术体系作为支撑才行，因此技术体系就显得特别重要了。依据本系统的特点，笔者举荐运用RESTful风格来架构整个技术体系，该风格可使得后台全部的功能是以服务的形式统一为前端供应功能支持。图3给出了该项目技术体系。·219·图3 本项目技术体系图通过图3可以看到，本项目的整体技术体系主要氛围三层，分别是前端呈现层、API服务层以及物理数据层，下面给出了这三个层主要用途：前段呈现层：主要是为用户进行呈现信息的，这里的用户包括司机、客户以及企业管理者，这些用户分别通过手机或者阅读器来访问本系统的各种服务，其中手机端适配当前量大主流的操作系统：Android与IOS。API服务层：该层呈现了RESTful架构风格，可以看到全部的功能都以服务的形式独立开来，而这些全部的服务都已API的形式对外呈现，这样前端不管是Android、IOS还是Web都可以依据统一的标准进行访问。物理数据层：这里主要是用来存储数据的地方了，这里供应各种存储数据的方式，其中MySQL主要用来存储业务数据，redis主要用来存储位置坐标数据，而OS主要用来存储大型二进制数据。提示：除了以上这些功能以外，还有一些服务中间件，这些中间件虽然不是干脆体现在某个功能上，但是可以用来来协调各个服务之间，以及服务层与数据层之间的关系。例如上面提到的MQ服务可以供应消息广播服务，而Cache则可以供应缓存方案，以提高系统的性能。架构体系依据以上的技术体系结构，这里给出了4种架构体系，这4种架构分别应对不同量级的需求，下面则分别来介绍下这几种架构方案。4.1 架构方案A方案A是比较简洁的一种方案，由于该方案成本低廉，运维成本则几乎为0，因此该方案是项目初·220·期举荐选择的方案。图4给出了该方案的架构图。图4 架构方案A示意图通过图4可以看出本方案是特别简洁的方案，因为架构简洁，使得该方案特别简洁维护，成本也特别低廉，但同时，该方案也无法支撑高并发的需求。下面给出了该方案的一些参数：支撑流量上限100W机房可以选择公有云服务，例如阿里云。也可以自购主机、自选IDC机房。存在的问题：IDC网络故障、IDC供应商响应不刚好。可以优化方案：搭建配置服务器，运用IP直联的形式会肯定程度上削减域名带来的问题。综上所诉，在项目刚起先阶段，用户流量不是很大的状况下，该方式还是比较好用的，性价比比较高的。4.2 架构方案B随着业务的发展，流量逐步达到了单机的极限，假如并发流量超过100W的时候，方案A就无法满意需求，而方案B则在A的基础上进行了扩充，运用集群来处理高并发的业务需求。图5给出了方案B的架构图。图5 架构方案B示意图·221·可以看出，方案B在方案A的基础之上得到了有效的改善，也由以前单机nginx改为LVS供应负载均衡服务，而服务层则是以集群的形式供应强劲的性能，数据库也做了主从模式的集群化架构方案。该方案主要有以下特点：支撑并发流量3000W~2亿机房最好自购主机、自选IDC机房，并搭建LNMP集群环境。引入MongoDB解决空间索引问题。订单安排系统，则是将LBS服务，分单服务以及redis坐标数据独立出来，形成订单安排系统独立维护。增加基于nagios的监控系统，可以监控系统的运行状况，其中包括，基础信息（cpu，内存等）、Nginx、MySQL、Cache、MongoDB等成本在方案A基础上有了增加，并且日常须要2运维工程师来维护系统。4.3 架构方案C随着业务量的接着上涨，各种活动的绽开，用户流量会越来越多，假如达到全国范围的用户级别的时候，方案B就会显得有些力不从心了，此时可以有一下三种方法来应对这个问题：优化：API逻辑优化、LVS性能瓶颈可以尝试搭建LVS集群+DNS轮询，内网带宽极限可以尝试压缩cache中的数据，分单系统会导致DB压力过大，这个时候可以适当的进行调整来消去峰值。柔性：对系统重新进行分析，看清业务与系统开销的对应关系。不常用的二级服务选择性的进行停用。对服务分级，对某些一级服务可以进行降级。扩容：数据库硬件升级，Push服务集群化改造，开发定制化LBS服务算法替代Redis以及MongoDB。然而以上这些应对方法，也只是治标不治本，无法根治方案B所呈现出来的各种问题，而这个时候方案C就孕育而生了。图6给出了方案C的架构图、提示：方案C的改造成本以及建立会特别高，但是可以根本上解决问题，因此一般状况下不会选择方案C，除非做到了滴滴这样全国性出行服务规模。图6 架构方案C示意图·222·6只是给出了方案C的总览图，其中每一个虚线块都可以成立一个项目组单拉出来进行研发，例如图6左下方的数据同步系统，其中包括了DB集群、KV集群等。下面给出了方案C的参数特点。支撑并发流量在5亿左右架构服务化，并且分城市部署，每个重要城市自选IDC机房。成本则须要50+的研发团队以及7个人左右的运维团队。支持SPDY协议，SPDY协议是Google提出的基于传输限制协议(TCP)的应用层协议，通过压缩、多路复用和优先级来缩短加载时间。该协议是一种更加快速的内容传输协议