在臺有逾2千萬活躍月用戶數的Line,不斷擴大平臺功能,去年底,其把用自家聊天機器人來提供叫車服務的TaxiGo,也納入生態系,成為叫車平臺Line Taxi。

如今,Line Taxi上線逾半年,註冊會員數已突破80萬,並有超過6千位司機,提供載客服務。隨著用戶數逐漸成長,Line Taxi服務背後的架構現每日需處理超過千萬筆資料,Line Taxi技術長同時也是服務共同創辦人的黃佩恩,日前在一場技術分享會上,揭露服務至2017年上線以來,背後架構的轉變。

黃佩恩回顧服務架構最初的樣貌。剛上線時,服務架構僅由API伺服器、Bot伺服器和資料庫所組成,半年後,由於用戶數不斷的增長,進入系統主機的流量也連帶增加,架構缺乏擴展性和彈性的問題逐漸浮現。

龐大的資料庫流量,是Line Taxi首先面臨的架構瓶頸,而資料庫流量主要的來源,就屬派遣作業。網路叫車服務藉派遣作業,來配對司機和叫車用戶,需不斷將車輛所在地資訊記錄於資料庫。原先,車輛位置只要一有變動,就需回報資訊給系統,這雖能精準地掌握車輛位置,但每秒回傳數筆資料,卻帶給系統龐大的流量壓力。

於是,Line Taxi技術團隊調整了派遣邏輯,從掌握車輛定位點每一次的變化,一秒便回傳多筆資料,調整為,車輛若不在服務旅程期間,每12秒回報一次其所在地資訊即可,而若車輛處於服務旅程中,再提高資訊回報的頻率,以掌握車輛即時位置。經調整後,除大大減少了資料庫流量,且黃佩恩表示,資料庫成本更只剩原先的八分之一。

此外,Line Taxi也從單一資料庫的結構,走向多資料庫組成的應用資料儲存空間,分別是關聯性資料庫、開源記憶體資料庫Redis、NoSQL資料庫和儲存空間,來分散資料流量。黃佩恩表示,團隊依照資料類型,來選擇資料的儲存處,她舉例,像是NoSQL資料庫儲存的是電話記錄、行程路徑等,而關聯性資料庫儲存的則是維運面資料,如司機行駕照。

除了調整派遣邏輯,還有改變資料庫的結構設計,來減少資料庫流量帶給系統的負荷外,技術團隊也重新改造整體系統架構,以提升架構的穩定性和擴展性。考量架構的穩定性,Line Taxi增加了負載平衡機制的設計,流量現進入系統時,會先由負載平衡器進行分流。

另外,API伺服器、Bot伺服器和新增的Web伺服器,皆從單一臺伺服器支援服務的設計,調整為多臺伺服器架構,來滿足擴展性需求,且各類伺服器會依據服務的使用量,利用自動擴充功能來調整伺服器數量,以因應服務量。Line Taxi技術長黃佩恩直言,過去,一旦一臺伺服器故障,整個服務就會停擺,很恐怖。

用戶數增長除使系統面臨流量上的壓力,原先派遣邏輯的設計也遭受了挑戰。過去,派遣器依單筆叫車需求,分配鄰近所有車輛來與用戶做配對,因此,一旦有其他用戶同時或相隔不久叫車,而該地區卻沒有可受派遣的新車輛出現,就會發生無車可派的狀況。黃佩恩表示,尤其又以上下班尖峰時間,最常出現這個問題。

為解決叫車需求集中出現時,服務遭遇的無車可派情形,Line Taxi技術團隊修改了派遣邏輯,改以全局派遣機制來因應。現在,分派器在派遣車輛時,會同時掌握當下的叫車用戶數量,以及可受派遣車輛數量,來平均分配車輛給該期間內的所有叫車用戶,讓各用戶都有車輛可進行配對。黃佩恩表示,系統每2秒會掌握一次需配對的用戶數量。

不過,派遣邏輯仍還是有待優化的空間,那就是,如何依車輛的位置,還有用戶的行程路徑,來安排最相宜的兩者配對,因為僅只考量車輛與用戶間的相對位置,是不夠的。黃佩恩指出,車輛行駛方向、GPS定位誤差等,都會影響車輛抵達用戶所在地所需要的時間,她進一步表示,未來計畫納入圖資,來優化派遣邏輯。

Line Taxi前身Taxi Go在3年前上線時,便選擇以聊天機器人,來提供叫車服務,黃佩恩也分享了聊天機器人的優缺點。相較App,聊天機器人有導入用戶快速、成本低、回應人性化等優點,但,用戶需進入Line App並加入服務的官方帳號後,才能進行註冊,使Line Taxi無法追蹤用戶來源,掌握用戶是透過何則廣告接觸到服務。

黃佩恩與團隊經過多方嘗試,最後,他們在註冊對話訊息內加入了一個巧思,嵌入追蹤像素,相當於一個網址連結。當用戶點擊註冊按鈕,後端API伺服器會比對用戶點擊廣告時,於伺服器裡留下的記錄,前後比對,來掌握用戶的來源。黃佩恩表示,這個設計就像是發送電子郵件時,追蹤收件者是否有讀取信件的方式。

在不斷改善技術設計的同時,Line Taxi也在持續拓展新的商業模式。近日,Line Taxi通過了交通部多元化計程車的審核,將招募多元計程車司機,採系統計算里程並提前預告車資的方式,取代跳錶計費,提供叫車服務。Line Taxi計畫先在臺北市試行多元化計程車的服務,之後,再逐步擴展到新北市與其他縣市。文⊙黃郁芸


Advertisement

更多 iThome相關內容