開發者小聚:LINE TAXI 技術長黃佩恩回顧「從 0 到 1」歷程

從 TaxiGo 走到 LINE TAXI,技術長 Hayden 黃佩恩在 LINE 開發者小聚直播裡分享了創業至今的開發歷程。
評論
▲LINE TAXI 技術長黃沛恩。INSIDE/Mia
評論

從 TaxiGo 走到 LINE TAXI,技術長 Hayden 黃佩恩在 LINE 開發者小聚直播裡分享了創業至今的開發歷程。

一開始,TaxiGo 時期就相對罕見地選擇使用聊天機器人叫車為主,對消費者端沒有 app 的形式,只有為司機端為持續更新地點定位提供 app 。Hayden 比較了 chatbot 和 app 應用上的優缺點,舉出 chatbot 導入用戶快速低成本、回應直覺等優勢,但另一方面,缺點就是介面相對受限、不易追蹤用戶來源,且對使用者來說需要重新建立使用習慣。

Hayden 也分享了 LINE TAXI 是如何一步步克服這些問題。

活用 API 與 WebView,UI 更多變

LINE TAXI 在早期就是 LINE Protostar 新星計畫的一員,有時可以搶先運用尚未對外開放的 API,在開發過程中也可玩出更多應用,而經過調整後,這些 API 現在也大都已經開放大眾使用。

追蹤使用者來源

因為透過行銷、廣告點擊進到 LINE TAXI 服務的使用者,會先進到 LINE app 內,再加入 LINE TAXI 官方帳號,所以產生了斷層,無法得知使用者的來源,就少了一塊重要資訊。因此 Hayden 分享團隊在「立即註冊」對話按鈕的空白處,埋了一個透明的 Pixel,透過 API 傳到伺服器,用類似 email 偵測信件開啟率的方法,因為讀取圖片是透過一組專屬網址,點擊連結就可以比對使用者。

另外推薦優惠的部分,原本因為無法追蹤來源,必須要手動輸入推薦碼,後來透過上述方法,讓新註冊的使用者點擊推薦者專屬連結,就可以自動比對。

改進了使用者體驗:派車邏輯、Number Masking、評分與叫車質化條件

再來就是隨著營運擴大(最新司機數已經來到 6300 位,先前有公開的使用者數則是 70 萬)改進的系統規劃,例如派車邏輯一開始是直接找距乘客最近的司機,但可能產生派單過於集中一輛車的狀況,後來就改成在一定距離內的車都平均分配一段時間內的單,也優化司機位置更新的頻率。派遣邏輯加上雲端資料庫架構改進分流,瞬間流量負擔減少了約 1/8,而且流量大的時候還可以 autoscale。

現在 LINE TAXI 也會用一些外部服務來輔助,比如 Datadog 監控與分析雲端資料,以及Vault 來管理金鑰。

另外 LINE TAXI 也已新增 Number Masking 功能,取代直接讓司機打電話給乘客 ,現在乘客或司機要用電話聯繫時,會先透過 LINE TAXI 的電話中心轉接,所以雙方都無法直接獲得電話號碼,可以保護使用者的隱私。而播打電話聯繫的功能 2 小時內都有效,若是物品遺失就能方便聯繫。

根據 Hayden,目前 LINE TAXI 會分析叫車的供需,找出熱門時段與地點來優化服務,不過沒有針對行車路線來分析。

未來:改進派車邏輯、multi-cloud 防意外

Hayden 分享,LINE TAXI 加入 LINE 以後已經過不少調整,本身沒有發生大當機,不過像金流端還是有發生過當機無法完成收款的狀況,所以未來目標之一就是在每個環節都做好備援方案,比如做好其他金流方案、後端部署 multi-cloud。

派車邏輯也還有改進空間,因為路線方向和定位誤差,Hayden 說目前有載客在對向的情形,會耗費比較多時間才載到客人。另外因為 LINE TAXI 是派計程車,算是路邊攔車邏輯,載到客人前司機可以棄單不接,所以必須派多輛車,派車邏輯也會跟司機回饋改善。還有在雙北以外地區車輛較少,比較依賴預約單,這方面也會照熱門時段加強在地化調整。

當然除了技術面,營運上 LINE TAXI 也有更多的計畫,包括日日搭訂閱方案,還有接受司機與乘客回饋後的調整,就請使用者們期待囉。

核稿編輯:Chris 

延伸閱讀:







Akamai 服務上新,於邊緣處推動快速創新

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用 Akamai 提供的 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。
評論
評論

在雲計算技術還沒有大規模普及前,絕大部分企業和組織都需要自建數據中心,或通過託管的方式來部署自己的硬體基礎架構,並在此基礎上為員工和客戶提供服務。取決於業務或其他方面的諸多要求,此時需要部署的數據中心可能有很多個,並廣泛分佈在不同地區,藉此為客戶提供流暢的體驗,並透過多個數據中心保障連續性。在發展的過程中,隨著「雲端」的出現,讓各個組織的計算開始集中。

而當在線直播、無人駕駛、智能家電、物聯網等應用開始陸續深入我們的工作和生活,情況又不同了。以往透過雲平台集中運行和服務的模式,因為距離導致的網絡延遲已經對用戶的使用體驗產生極大影響。為了提供更敏捷、靈活、快速、可靠的體驗,企業需要從最貼近用戶的地方提供服務。因此,邊緣計算就成為最有效的解決方法。

透過將數據的收集、分析和處理等工作,由「雲中心」重新分散到最接近用戶的邊緣位置,企業可以就近為用戶提供服務,通過延遲更低的響應打造更出色的用戶體驗。

「無服務器」的出現,帶來計算方式的革新

以前,當組織需要上線一套業務系統時,首先需要採購並部署相應的服務器硬體,並且要負擔服務器日常運維過程中的管理、維護、補丁安裝、配置等繁瑣任務。

上雲前,組織需要在自己的數據中心,以硬體服務器的方式執行這一系列工作;上雲後雖然簡單許多,但依然需要面對雲服務商提供的虛擬服務器,從本質上來看相關負擔仍相當繁重。

無服務器(Serverless)技術的出現,讓組織可以在不需要考慮服務器的情況下,構建並運行由微服務構成的創新式應用程式與和服務。藉此不僅可以省略基礎架構管理任務,還能為幾乎任何類型的應用程式或後端服務構建無服務器應用程序,更方便、靈活地構建出具備極高可用性的應用。

Akamai EdgeWorkers :為創新賦能

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用Akamai 超過 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。

當開發團隊在邊緣開啟代碼時,他們會將數據、見解和邏輯推送到更靠近最終用戶的位置。Akamai 的高性能、可擴展式實施模型,可確保數據和計算不會被延遲問題困擾,進而避免對數字化體驗產生負面影響。

在該服務幫助下,開發者可直接在 Akamai 的全球分佈式平台上快速、迭代地創建和部署新服務,以解決問題和自定義交付。

長期以來,Akamai 在邊緣計算的創新和成功實施皆具有優勢。自 1998 年起,便開始為 Akamai 內容交付網絡(CDN)的客戶推出自定義交付邏輯,其他里程碑還包括 2001 年的 Edge Site Includes 、2002 年的 Edge Java 以及 2014 年的 cloudlet 應用程式。

目前, Akamai 在全球擁有超過 4100 個入網點,為 EdgeWorkers 用戶提供出色的邊緣基礎架構規模和範圍,開發人員可以在靠近最終用戶和他們的數字化接觸點的地方部署代碼,以實現盡可能低的延遲。EdgeWorkers 同樣獨立於雲,客戶可以選擇利用 CDN 供應商或雲供應商平台上的無服務器計算功能。在 Akamai 幫助下,客戶可以在整個混合雲或多雲環境中部署單一的無服務器計算平台。

更多相關資訊:https://www.akamai.com/solutions/edge

本文章內容由「猿聲串動」提供,經關鍵評論網媒體集團廣編企劃編審。