1、-打車 APP 解決方案需要定制開發一個打車，本文檔則分別從功能與技術兩個方面介紹了該項目的解決方案。預期目標該項目的想要實現的預期目標其實說起來非常簡單，只要通過 AP能夠完成叫車服務即可，圖 1描述了該項目的本質需求.圖1項目需求從圖 1 中可以看出,本項目的本質需求從大的方面來說其實就三個方面：首先滿足用戶的打車需求，讓用戶可以及時獲取出行服務，并且可以享受到一些優惠活動。.最后,如果可以,最終在線上完成支出操作,三方支付進行合作達到目的。為了可以更好達成以上需求，通過這三個本質的需求可以引申出來一些周邊的輔助需求，主要有一下幾點：,.增加加價功能，在用戶與司機雙方認可的前提下，如果遇到

2、比較極端的出行服務，可以適當的-進行加價，這樣可以更高的調動司機的積極性，并且對用戶來說也不失公允。,而出.提示：以上這些功能只是筆者本暫時想到的，如果還有其他需要改動的需求，可以隨時增加或修改。以上這些所有的需求點，在移動互聯網時代,通過打車 AP的定位功能可以非常高效的滿足以上所有的需求。2功能框架2 功能點的框架圖。圖2本項目功能框架圖圖 2 .,.1司機端司機端是出租車司機操作的平臺，主要用來滿足司機載客的需求,使得出租車的空車率得到降低.:臨近的可以滿足服務的出租車司機可以進行搶單操作，有且只會有 1 個司機搶到訂單。該功能是司機端的核心功能之一語音讀單:出租車司機大部分時間是無法去

3、閱讀訂單內容的,也無法操作手機的,助司機更及時方便的了解叫單的內容。-,更好的維護自己的服務歷史記錄。用戶端軟件的使用率以及公司整體的業績。用戶端主要包含一下幾個功能點：:A的主要目的就是滿足其能夠及時叫到車的需求，因此本功能是用戶端的核心功能之一 .在叫車的同時可以附帶是否可以拼車，是否給加價等輔助功能。:用戶用車有時候會提前預約訂車，例如預約幾點去機場等需求，該需求也是用戶端核心功能之一。代駕功能：有很多情況用戶因為規定無法駕駛自己的汽車,因此通過P代駕的服務需求。管理功能:其中包括我的訂單,我的賬務,我的消息等管理功能，方便用戶隨時查看自己的用車歷史記錄,除此之外，在每次使用完叫車服務后

4、，還可以對司機進行評價回復。3企業管理端這部分主要是讓服務提供企業方便的在后臺進行運營維護,數據支持，企業管理端主要包含以下幾個方面的管理：:該部分主要是可以方便的管理車輛、司機、訂單、用戶、賬務、評價等信息。除此之外，還可以對出租車進行全局監控。企業運營管理:這里主要是為企業運營提供幫助的功能,其中包括公告,能,通過這些功能不僅方便企業及時做出決策,也可以方便企業做一些線上的活動，刺激用戶使 用。安全權限：因為所有的數據都在企業管理后臺這里，因此這里的數據安全，以及權限管理則非常有必要。提示：除了以上兩個核心管理功能之外，企業管理者還可以方便監控本系統與第三方平臺對接的情況.3技術體系筆者推

5、薦使用 RSTfl -圖3本項目技術體系圖通過圖 3 ,API ,:前段,當前量大主流的操作系統：Android 與 IOS.PI :該層展現了ESul ,這樣前端不管是AndridOS 還是Web 按照統一的標準進行訪問。,這里提供各種存儲數據的方式，其中 MySQL主要用來存儲業務數據，ri主要用來存儲位置坐標數據，而 O主要用來存儲大型二進制數據。提示:但是可以用來來協調各個服務之間,以及服務層與數據層之間的關系。例如上面提到的 M消息廣播服務，而Cae ,以提高系統的性能。4架構體系按照以上的技術體系結構,這里給出了 4 種架構體系，這 4 種架構分別應對不同量級的需求,下面則分別來介

6、紹下這幾種架構方案.。1架構方案A方案A 是比較簡單的一種方案，由于該方案成本低廉，運維成本則幾乎為0，因此該方案是項目初-期推薦選擇的方案。圖 4 給出了該方案的架構圖。圖4架構方案A示意圖通過圖 4 可以看出本方案是非常簡單的方案,因為架構簡單,使得該方案非常容易維護,成本也非常低廉，但同時,該方案也無法支撐高并發的需求。下面給出了該方案的一些參數：100W機房可以選擇公有云服務，例如阿里云。也可以自購主機、自選I機房。:IDIDC 提供商響應不及時。可以優化方案：搭建配置服務器，使用,在項目剛開始階段，用戶流量不是很大的情況下，該方式還是比較實用的,的。42架構方案如果并發流量超過 10

7、W 方案A 需求而方案則在A ,5 給出了方案B 圖。圖5架構方案B 示意圖-方案B 也由以前單機 改為LV,: 億機房最好自購主機、自選IDC 集群環境。引入ongoDB解決空間索引問題。則是將LBS 立維護。增加基于agios 其中包括，基礎信息)、Ninx、MSQ、ache、MongD等成本在方案A 2 運維工程師來維護系統。3架構方案隨著業務量的繼續上漲,各種活動的展開,用戶流量會越來越多,如果達到全國范圍的用戶級別的時候，方案就會顯得有些力不從心了,此時可以有一下三種辦法來應對這個問題:優化:API 性能瓶頸可以嘗試搭建 +NS 輪詢內網帶寬極限可以嘗試壓縮ah中的數據,分單系統會導致D壓力過大，這個時候可以適當的進行調整來消去峰值。柔性:對系統重新進行分析,看清業務與系統開銷的對應關系.不常用的二級服務選擇性的進行停用。對服務分級,對某些一級服務可以進行降級。Pu開發定制化edis以及MongDB。B 方案C 6 給出了方案C 的架構圖、提示：方案C 方案C，除非做到了滴滴這樣全國性出行服務規模。圖6架構方案C 示意圖-圖 6 只是給出了方案C 6 集群等。下面給出了方案C .5 億左右,每個重要城市自選ID機房。支持PY 支持PY 協議是 Ggle 該協議是一種更加快速的內容傳輸協議。