Line Taxi上線逾半年，CTO首度對外分享叫車服務的技術挑戰，並揭露每日可處理千萬筆資料量的架構設計

在臺有逾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計畫先在臺北市試行多元化計程車的服務，之後，再逐步擴展到新北市與其他縣市。文⊙黃郁芸