核心挑戰

按下叫車鍵的瞬間

乘客按下叫車鍵，看起來只是一次 API 呼叫。

實際上，後端要在短時間內完成位置接收、司機搜尋與派單。同一時間，還有大量司機正在持續上傳 GPS 位置。

注意乘客的單一請求與四周許多司機的位置訊號同時抵達後端，這就是高併發的由來。

所以叫車平台是一套高併發、低延遲的即時分散式系統。

你做過的一般 CRUD API 可以晚幾百毫秒回應，叫車的派單卻是在搶秒。

派單的關鍵路徑

從送出請求到派單，系統至少要走四步。

接收乘客位置、查詢附近可服務的司機、評估距離與預估到達時間（ETA），最後完成派單。

這四步都在同一條請求路徑上。任何一步變慢，乘客就得多等。

這條路徑就是你設計時最該盯住延遲的地方。

三股同時湧入的流量

派單請求只是其中一股流量。

位置更新：大量司機持續上傳 GPS，寫入又高頻又密集。

訂單狀態同步：乘客端、司機端與後端服務都必須看到同一個訂單狀態。

派單決策：查詢附近司機，並在短時間內完成選擇。

三者同時發生，會互相搶運算與資料庫資源。

會出錯的五種情境

真實環境不會照理想路徑走。

系統還要面對尖峰流量、網路不穩、重複請求、司機拒單與服務故障。尖峰時，請求量會瞬間暴增。

網路不穩會讓位置與狀態更新延遲，App 也可能重送請求。後端若沒處理，就會出現重複訂單。

司機拒單代表這次派單沒完成，需要重新媒合。服務故障若發生在單一大系統裡，整個平台都會受影響。

拆成獨立微服務

常見做法是把能力拆成獨立微服務：使用者、位置、媒合、行程、通知與計費。

位置與媒合扛住高頻 GPS 寫入與即時派單。

行程與通知負責訂單狀態流轉，並通知乘客與司機。使用者與計費管理帳戶與費用。

拆開後，各服務能依自己的負載擴展。一個服務故障，也不會拖垮全部。

讓系統撐得住的元件

拆完服務還不夠，通常還會搭配四種機制。

快取：讓司機位置這類熱資料快速讀取，降低延遲。

訊息佇列：把狀態變化非同步傳給其他服務，緩衝尖峰流量。

分散式資料庫：分散資料與寫入壓力，支撐擴展。可觀測性：追蹤延遲與錯誤，及早發現服務故障。

帶回你的專案

整套設計的目標有三個：可擴展、快速回應、服務體驗一致。

檢視自己的系統時，先找出關鍵路徑、高頻寫入與需要同步的狀態。

再問一句：哪個服務掛掉會拖垮全部？

答得出來，你就抓到高併發即時媒合的核心挑戰了。

叫車平台需要同時處理大量 GPS 位置更新與派單請求，因此屬於高併發、低延遲的即時分散式系統。

• 正確
• 錯誤

答案: 正確

正確。位置更新與派單會同時大量發生，而且派單需要在短時間內完成，因此系統必須兼顧高併發與低延遲。

在叫車平台中，負責高頻 GPS 寫入的是 _____；負責即時選擇司機的是 _____；負責訂單狀態流轉與通知的是 _____；負責帳戶與費用的是 _____。

答案: 在叫車平台中，負責高頻 GPS 寫入的是 位置服務；負責即時選擇司機的是 媒合服務；負責訂單狀態流轉與通知的是 行程與通知服務；負責帳戶與費用的是 使用者與計費服務。

不同微服務承擔不同責任：位置與媒合支援即時工作，行程與通知管理狀態及訊息，使用者與計費管理帳戶和費用。這種拆分有助於依負載獨立擴展。

若要降低附近司機位置這類熱資料的讀取延遲，最直接適合採用哪一種機制？

• 快取
• 訊息佇列
• 可觀測性
• 計費服務

答案: 快取

快取適合存放司機位置等經常讀取的熱資料，可避免每次查詢都直接存取較慢的主要資料來源，因而降低延遲。訊息佇列主要用於非同步傳遞與尖峰緩衝；可觀測性則用於追蹤延遲與錯誤。