打車APP技術(shù)解決方案

打車APP解決方案須要定制開發(fā)一個(gè)打車APP，本文檔則分別從功能與技術(shù)兩個(gè)方面介紹了該項(xiàng)目的解決方案。預(yù)期目標(biāo)該項(xiàng)目的想要實(shí)現(xiàn)的預(yù)期目標(biāo)其實(shí)說起來特別簡潔，只要通過APP能夠完成叫車服務(wù)即可，圖1描述了該項(xiàng)目的本質(zhì)需求。圖1 項(xiàng)目需求從圖1中可以看出，本項(xiàng)目的本質(zhì)需求從大的方面來說其實(shí)就三個(gè)方面：首先滿意用戶的打車需求，讓用戶可以剛好獲得出行服務(wù)，并且可以享受到一些實(shí)惠活動(dòng)。其次要滿意司機(jī)的載客需求，降低出租車的空載率，增加司機(jī)的收入。最終，假如可以，最終在線上完成支出操作，使得可以更好的管理出租車司機(jī)。這里可以通過與第三方支付進(jìn)行合作達(dá)到目的。為了可以更好達(dá)成以上需求，通過這三個(gè)本質(zhì)的需求可以引申出來一些周邊的協(xié)助需求，主要有一下幾點(diǎn)：在匹配用戶和司機(jī)雙方的供需信息時(shí)，可以增加一些語音功能，不僅使得用戶操作更便利，也使得司機(jī)可以在不影響開車的狀況下或許信息。增加加價(jià)功能，在用戶與司機(jī)雙方認(rèn)可的前提下，假如遇到比較極端的出行服務(wù)，可以適當(dāng)?shù)摹?17·進(jìn)行加價(jià)，這樣可以更高的調(diào)動(dòng)司機(jī)的主動(dòng)性，并且對用戶來說也不失公允。在運(yùn)用完訂車服務(wù)后，可以增加評價(jià)功能，完成評價(jià)體系，可以讓更好的司機(jī)以及更好的乘客脫穎而出，也為出租車公司供應(yīng)了更好的考核依據(jù)。提示：以上這些功能只是筆者本短暫想到的，假如還有其他須要改動(dòng)的需求，可以隨時(shí)增加或修改。以上這些全部的需求點(diǎn)，在移動(dòng)互聯(lián)網(wǎng)時(shí)代，通過打車APP的定位功能可以特別高效的滿意以上全部的需求。功能框架通過對預(yù)期目標(biāo)的需求分析，可以很簡潔的得出本項(xiàng)目的須要實(shí)現(xiàn)的功能，圖2給出了本項(xiàng)目全部功能點(diǎn)的框架圖。圖2 本項(xiàng)目功能框架圖2具體給出了本項(xiàng)目的功能框架，從大的方面來說可以分為三個(gè)端口，分別是司機(jī)端、用戶端以及企業(yè)管理端。提示：以上功能點(diǎn)只是短暫建議的功能點(diǎn)，除了幾個(gè)核心的功能點(diǎn)之外，其余全部的協(xié)助功能點(diǎn)都是選購的，例如運(yùn)營功能，可以后期依據(jù)托付方具體的運(yùn)營需求再進(jìn)行確定。2.1 司機(jī)端司機(jī)端是出租車司機(jī)操作的平臺(tái)，主要用來滿意司機(jī)載客的需求，使得出租車的空車率得到降低。司機(jī)端主要包含以下幾個(gè)功能點(diǎn)：一鍵搶單：當(dāng)用戶發(fā)布叫車需求后，接近的可以滿意服務(wù)的出租車司機(jī)可以進(jìn)行搶單操作，有且只會(huì)有1個(gè)司機(jī)搶到訂單。該功能是司機(jī)端的核心功能之一語音讀單：出租車司機(jī)大部分時(shí)間是無法去閱讀訂單內(nèi)容的，也無法操作手機(jī)的，語音讀單可以幫助司機(jī)更剛好便利的了解叫單的內(nèi)容?！?18·管理功能：其中包括我的訂單，我的賬務(wù)，我的消息以及司機(jī)服務(wù)排名，這些功能可以幫助司機(jī)更好的維護(hù)自己的服務(wù)歷史記錄。2.2 用戶端用戶端是出租車公司以及司機(jī)為用戶供應(yīng)服務(wù)的主要窗口，用戶對服務(wù)體驗(yàn)的好壞也干脆影響了本軟件的運(yùn)用率以及公司整體的業(yè)績。用戶端主要包含一下幾個(gè)功能點(diǎn)：叫車功能：其中有即時(shí)叫車功能與語音叫車功能。用戶運(yùn)用該APP的主要目的就是滿意其能夠剛好叫到車的需求，因此本功能是用戶端的核心功能之一。在叫車的同時(shí)可以附帶是否可以拼車，是否給加價(jià)等協(xié)助功能。預(yù)約功能：用戶用車有時(shí)候會(huì)提前預(yù)約訂車，例如預(yù)約幾點(diǎn)去機(jī)場等需求，該需求也是用戶端核心功能之一。代駕功能：有許多狀況用戶因?yàn)橐?guī)定無法駕駛自己的汽車，因此通過APP也可以公布自己須要代駕的服務(wù)需求。管理功能：其中包括我的訂單，我的賬務(wù)，我的消息等管理功能，便利用戶隨時(shí)查看自己的用車歷史記錄，除此之外，在每次運(yùn)用完叫車服務(wù)后，還可以對司機(jī)進(jìn)行評價(jià)回復(fù)。2.3 企業(yè)管理端這部分主要是讓服務(wù)供應(yīng)企業(yè)便利的在后臺(tái)進(jìn)行運(yùn)營維護(hù)，便利的了解各種數(shù)據(jù)，為企業(yè)的決策供應(yīng)數(shù)據(jù)支持，企業(yè)管理端主要包含以下幾個(gè)方面的管理：企業(yè)日常管理：該部分主要是可以便利的管理車輛、司機(jī)、訂單、用戶、賬務(wù)、評價(jià)等信息。除此之外，還可以對出租車進(jìn)行全局監(jiān)控。企業(yè)運(yùn)營管理：這里主要是為企業(yè)運(yùn)營供應(yīng)幫助的功能，其中包括公告，實(shí)惠政策、統(tǒng)計(jì)報(bào)表等功能，通過這些功能不僅便利企業(yè)剛好做出決策，也可以便利企業(yè)做一些線上的活動(dòng)，刺激用戶運(yùn)用。平安權(quán)限：因?yàn)槿康臄?shù)據(jù)都在企業(yè)管理后臺(tái)這里，因此這里的數(shù)據(jù)平安，以及權(quán)限管理則特別有必要。提示：除了以上兩個(gè)核心管理功能之外，企業(yè)管理者還可以便利監(jiān)控本系統(tǒng)與第三方平臺(tái)對接的狀況。技術(shù)體系為了滿意以上的功能需求，須要強(qiáng)而有力的技術(shù)體系作為支撐才行，因此技術(shù)體系就顯得特別重要了。依據(jù)本系統(tǒng)的特點(diǎn)，筆者舉薦運(yùn)用RESTful風(fēng)格來架構(gòu)整個(gè)技術(shù)體系，該風(fēng)格可使得后臺(tái)全部的功能是以服務(wù)的形式統(tǒng)一為前端供應(yīng)功能支持。圖3給出了該項(xiàng)目技術(shù)體系?！?19·圖3 本項(xiàng)目技術(shù)體系圖通過圖3可以看到，本項(xiàng)目的整體技術(shù)體系主要氛圍三層，分別是前端呈現(xiàn)層、API服務(wù)層以及物理數(shù)據(jù)層，下面給出了這三個(gè)層主要用途：前段呈現(xiàn)層：主要是為用戶進(jìn)行呈現(xiàn)信息的，這里的用戶包括司機(jī)、客戶以及企業(yè)管理者，這些用戶分別通過手機(jī)或者閱讀器來訪問本系統(tǒng)的各種服務(wù)，其中手機(jī)端適配當(dāng)前量大主流的操作系統(tǒng)：Android與IOS。API服務(wù)層：該層呈現(xiàn)了RESTful架構(gòu)風(fēng)格，可以看到全部的功能都以服務(wù)的形式獨(dú)立開來，而這些全部的服務(wù)都已API的形式對外呈現(xiàn)，這樣前端不管是Android、IOS還是Web都可以依據(jù)統(tǒng)一的標(biāo)準(zhǔn)進(jìn)行訪問。物理數(shù)據(jù)層：這里主要是用來存儲(chǔ)數(shù)據(jù)的地方了，這里供應(yīng)各種存儲(chǔ)數(shù)據(jù)的方式，其中MySQL主要用來存儲(chǔ)業(yè)務(wù)數(shù)據(jù)，redis主要用來存儲(chǔ)位置坐標(biāo)數(shù)據(jù)，而OS主要用來存儲(chǔ)大型二進(jìn)制數(shù)據(jù)。提示：除了以上這些功能以外，還有一些服務(wù)中間件，這些中間件雖然不是干脆體現(xiàn)在某個(gè)功能上，但是可以用來來協(xié)調(diào)各個(gè)服務(wù)之間，以及服務(wù)層與數(shù)據(jù)層之間的關(guān)系。例如上面提到的MQ服務(wù)可以供應(yīng)消息廣播服務(wù)，而Cache則可以供應(yīng)緩存方案，以提高系統(tǒng)的性能。架構(gòu)體系依據(jù)以上的技術(shù)體系結(jié)構(gòu)，這里給出了4種架構(gòu)體系，這4種架構(gòu)分別應(yīng)對不同量級的需求，下面則分別來介紹下這幾種架構(gòu)方案。4.1 架構(gòu)方案A方案A是比較簡潔的一種方案，由于該方案成本低廉，運(yùn)維成本則幾乎為0，因此該方案是項(xiàng)目初·220·期舉薦選擇的方案。圖4給出了該方案的架構(gòu)圖。圖4 架構(gòu)方案A示意圖通過圖4可以看出本方案是特別簡潔的方案，因?yàn)榧軜?gòu)簡潔，使得該方案特別簡潔維護(hù)，成本也特別低廉，但同時(shí)，該方案也無法支撐高并發(fā)的需求。下面給出了該方案的一些參數(shù)：支撐流量上限100W機(jī)房可以選擇公有云服務(wù)，例如阿里云。也可以自購主機(jī)、自選IDC機(jī)房。存在的問題：IDC網(wǎng)絡(luò)故障、IDC供應(yīng)商響應(yīng)不剛好?？梢詢?yōu)化方案：搭建配置服務(wù)器，運(yùn)用IP直聯(lián)的形式會(huì)肯定程度上削減域名帶來的問題。綜上所訴，在項(xiàng)目剛起先階段，用戶流量不是很大的狀況下，該方式還是比較好用的，性價(jià)比比較高的。4.2 架構(gòu)方案B隨著業(yè)務(wù)的發(fā)展，流量逐步達(dá)到了單機(jī)的極限，假如并發(fā)流量超過100W的時(shí)候，方案A就無法滿意需求，而方案B則在A的基礎(chǔ)上進(jìn)行了擴(kuò)充，運(yùn)用集群來處理高并發(fā)的業(yè)務(wù)需求。圖5給出了方案B的架構(gòu)圖。圖5 架構(gòu)方案B示意圖·221·可以看出，方案B在方案A的基礎(chǔ)之上得到了有效的改善，也由以前單機(jī)nginx改為LVS供應(yīng)負(fù)載均衡服務(wù)，而服務(wù)層則是以集群的形式供應(yīng)強(qiáng)勁的性能，數(shù)據(jù)庫也做了主從模式的集群化架構(gòu)方案。該方案主要有以下特點(diǎn)：支撐并發(fā)流量3000W~2億機(jī)房最好自購主機(jī)、自選IDC機(jī)房，并搭建LNMP集群環(huán)境。引入MongoDB解決空間索引問題。訂單安排系統(tǒng)，則是將LBS服務(wù)，分單服務(wù)以及redis坐標(biāo)數(shù)據(jù)獨(dú)立出來，形成訂單安排系統(tǒng)獨(dú)立維護(hù)。增加基于nagios的監(jiān)控系統(tǒng)，可以監(jiān)控系統(tǒng)的運(yùn)行狀況，其中包括，基礎(chǔ)信息（cpu，內(nèi)存等）、Nginx、MySQL、Cache、MongoDB等成本在方案A基礎(chǔ)上有了增加，并且日常須要2運(yùn)維工程師來維護(hù)系統(tǒng)。4.3 架構(gòu)方案C隨著業(yè)務(wù)量的接著上漲，各種活動(dòng)的綻開，用戶流量會(huì)越來越多，假如達(dá)到全國范圍的用戶級別的時(shí)候，方案B就會(huì)顯得有些力不從心了，此時(shí)可以有一下三種方法來應(yīng)對這個(gè)問題：優(yōu)化：API邏輯優(yōu)化、LVS性能瓶頸可以嘗試搭建LVS集群+DNS輪詢，內(nèi)網(wǎng)帶寬極限可以嘗試壓縮cache中的數(shù)據(jù)，分單系統(tǒng)會(huì)導(dǎo)致DB壓力過大，這個(gè)時(shí)候可以適當(dāng)?shù)倪M(jìn)行調(diào)整來消去峰值。柔性：對系統(tǒng)重新進(jìn)行分析，看清業(yè)務(wù)與系統(tǒng)開銷的對應(yīng)關(guān)系。不常用的二級服務(wù)選擇性的進(jìn)行停用。對服務(wù)分級，對某些一級服務(wù)可以進(jìn)行降級。擴(kuò)容：數(shù)據(jù)庫硬件升級，Push服務(wù)集群化改造，開發(fā)定制化LBS服務(wù)算法替代Redis以及MongoDB。然而以上這些應(yīng)對方法，也只是治標(biāo)不治本，無法根治方案B所呈現(xiàn)出來的各種問題，而這個(gè)時(shí)候方案C就孕育而生了。圖6給出了方案C的架構(gòu)圖、提示：方案C的改造成本以及建立會(huì)特別高，但是可以根本上解決問題，因此一般狀況下不會(huì)選擇方案C，除非做到了滴滴這樣全國性出行服務(wù)規(guī)模。圖6 架構(gòu)方案C示意圖·222·6只是給出了方案C的總覽圖，其中每一個(gè)虛線塊都可以成立一個(gè)項(xiàng)目組單拉出來進(jìn)行研發(fā)，例如圖6左下方的數(shù)據(jù)同步系統(tǒng)，其中包括了DB集群、KV集群等。下面給出了方案C的參數(shù)特點(diǎn)。支撐并發(fā)流量在5億左右架構(gòu)服務(wù)化，并且分城市部署，每個(gè)重要城市自選IDC機(jī)房。成本則須要50+的研發(fā)團(tuán)隊(duì)以及7個(gè)人左右的運(yùn)維團(tuán)隊(duì)。支持SPDY協(xié)議，SPDY協(xié)議是Google提出的基于傳輸限制協(xié)議(TCP)的應(yīng)用層協(xié)議，通過壓縮、多路復(fù)用和優(yōu)先級來縮短加載時(shí)間。該協(xié)議是一種更加快速的內(nèi)容傳輸協(xié)議