Fleet Engine 即時事件

車隊在地面營運時，近乎即時的信號對企業有多種用途。舉例來說，商家可以運用這些功能：

  • 監控機群效能，及早找出潛在問題
  • 提供準確的預計到達時間和追蹤資訊，提升客戶服務品質
  • 找出並解決效率不彰的問題，降低成本
  • 監控駕駛行為並找出潛在危險，提升安全性
  • 最佳化駕駛路線和時間表，提高效率
  • 追蹤車輛位置和服務時數，遵守法規

本文說明開發人員如何將 Google Maps Platform「Mobility 服務」(「Last Mile Fleet Solution」(LMFS) 或「隨選行程與外送服務解決方案」(ODRD)) 的信號，轉換為可做為行動依據的自訂事件。此外，我們也會介紹 GitHub 上的車隊事件參考解決方案，說明其重要概念和設計決策。

本文件適用於：

  • 熟悉 Google Maps Platform 的「Mobility 服務」及其核心元件之一「Fleet Engine」的架構師。如果您是「接送服務」的新手，建議您根據需求，熟悉Last Mile Fleet Solution 和/或隨選行程與配送解決方案。
  • 熟悉 Google Cloud 的架構師。如果您是 Google Cloud 新手，建議先閱讀「在 Google Cloud 建立串流資料管道」。
  • 如果指定其他環境或軟體堆疊，請著重於瞭解 Fleet Engine 的整合點和考量重點，這些仍應適用。
  • 有興趣瞭解如何產生及運用機群事件的人。

閱讀完本文件後，您應該會對串流系統的重要元素和考量事項有基本瞭解，並熟悉 Google Maps Platform 和 Google Cloud 的建構模塊，這些模塊構成了車隊事件參考解決方案。

Fleet Events 參考解決方案總覽

車隊事件參考解決方案是開放原始碼解決方案，可讓 Mobility 客戶和合作夥伴在 Fleet Engine 和 Google Cloud 元件上產生重要事件。目前，參考解決方案支援使用 Last Mile Fleet Solution 的客戶，並支援隨選行程和配送。

這項解決方案會根據與工作或行程相關的特定資料變更，自動產生事件。您可以使用這些事件，向利害關係人傳送通知 (例如以下通知)，或觸發車隊的其他動作。

  • 抵達工作地點的預計到達時間有變
  • 任務抵達時間的相對預計到達時間變化
  • 距離任務開始的剩餘時間
  • 距離抵達任務地點還有多遠
  • TaskOutcome 狀態變更

您可以根據業務需求，自訂參考解決方案的各個元件。

邏輯構成元素

圖表：下圖顯示構成車隊事件參考解決方案的高階建構模塊

Fleet Events 總覽和邏輯建構模塊

參考解決方案包含下列元件：

  • 事件來源：原始事件串流的來源。「Last Mile Fleet Solution」和「On-demand Rides and Deliveries Solution」都與 Cloud Logging 整合，可將 Fleet Engine RPC 呼叫記錄轉換為開發人員可用的事件串流。這是要使用的核心來源。
  • 處理：原始 RPC 呼叫記錄會在這個區塊中轉換為狀態變更事件，該區塊會計算記錄事件串流。為偵測這類變更，這個元件需要狀態儲存庫，以便將新傳入的事件與先前的事件進行比較，進而偵測變更。事件不一定會包含所有相關資訊。在這種情況下，這個區塊可能會視需要對後端進行查詢呼叫。
    • 狀態儲存庫：部分處理架構會自行提供中繼資料持久性。如果沒有，則需要自行儲存狀態。由於這些狀態應是車輛和事件類型專屬，因此 K-V 類型的資料持續性服務會是合適的選擇。
  • 接收器 (自訂事件)：偵測到的狀態變更應提供給任何可從中受益的應用程式或服務。因此，將這項自訂事件發布至事件傳遞系統，供下游使用，是自然而然的選擇。
  • 下游服務：取用產生的事件，並根據您的用途採取特定動作的程式碼。

選取服務

如要導入「Last Mile Fleet Solution」或「On-demand Rides and Deliveries Solution」(2023 年第 3 季末推出) 的參考解決方案，選擇「來源」和「接收器」的技術相當簡單。另一方面，「處理」則有許多選項。參考解決方案已選擇下列 Google 服務。

圖表：下圖顯示用於實作參考解決方案的 Google Cloud 服務

Fleet Events 參考解決方案建構模塊

雲端專案版面配置

建議您預設採用多專案部署。這樣一來，Google Maps Platform 和 Google Cloud 的用量就能清楚區分，並與您選擇的帳單安排連結。

事件來源

「Last Mile Fleet Solution」和「隨選乘車和外送解決方案」會將 API 要求和回應酬載寫入 Cloud Logging。Cloud Logging 會將記錄檔傳送至一或多項所選服務。此時，轉送至 Cloud Pub/Sub 是最佳選擇，可將記錄轉換為事件串流，不需編寫程式碼。

接收器

在 Google Cloud 中，Cloud Pub/Sub 是首選的近乎即時訊息傳遞系統。就像來源事件會傳送至 Pub/Sub 一樣，自訂事件也會發布至 Pub/Sub，供下游使用。

處理中

下列元件會參與事件處理。與其他建構模塊一樣，處理元件完全無伺服器，且可向上和向下擴充。

  • Cloud Functions 做為初始版本的運算平台 (*)
    • 無伺服器，可透過資源調度控制項擴充及縮減資源，以便管理成本
    • Java：Fleet Engine 相關 API 提供用戶端程式庫，因此我們選擇 Java 做為程式設計語言，以便輕鬆實作
  • Cloud Firestore 做為狀態儲存庫
    • 無伺服器鍵/值儲存庫
  • Cloud Pub/Sub：與上游和下游元件的整合點
    • 鬆耦合的近乎即時整合

這些函式可直接使用預設設定，但也可以重新設定。設定參數是透過部署指令碼設定，並在對應的 Terraform 模組 README 中詳細記錄。

*注意：這項參考解決方案預計會發布替代實作，協助滿足不同需求。

部署作業

為了讓參考解決方案部署程序可重複、可自訂、可控管原始碼且安全，我們選擇 Terraform 做為自動化工具。Terraform 是廣泛採用的 IaC (基礎架構即程式碼) 工具，對 Google Cloud 提供豐富支援。

Terraform 模組

我們並未建立一個大型的單一參考解決方案部署模組，而是將可重複使用的自動化區塊實作為 Terraform 模組，可獨立使用。模組提供多種可設定的變數，其中大部分都有預設值，方便您快速上手，同時也能根據需求和偏好彈性自訂。

參考解決方案包含的模組：

  • Fleet Engine 記錄設定：自動設定 Cloud Logging 相關設定，以便與 Fleet Engine 搭配使用。在參考解決方案中，這個外掛程式用於將 Fleet Engine 相關記錄轉送至指定的 Pub/Sub 主題。
  • 車隊事件 Cloud 函式部署：包含範例函式程式碼部署，並處理安全跨專案整合所需的權限設定自動化作業。
  • 完整參考解決方案部署作業：呼叫前兩個模組，並包裝整個解決方案。

安全性

IAM 採用最小權限原則，並遵循 Google Cloud 的安全性最佳做法，例如服務帳戶模擬。請參閱下列文章，進一步瞭解 Google Cloud 如何協助您更有效地控管安全性。

後續行動

現在可以存取並進一步探索車隊事件參考解決方案。前往 GitHub 即可開始使用。

附錄

收集需求

建議您在程序初期就收集需求。

首先，請記下您對近乎即時事件感興趣或需要使用的原因。以下問題可協助你釐清需求。

  • 事件串流需要哪些資訊才能發揮作用？
    • 結果是否能完全從 Google 服務中擷取或產生的資料推導出來？還是需要透過整合的外部系統充實資料？如果是，這些系統是什麼？提供哪些整合介面？
    • 貴商家想評估哪些指標？如何定義？
    • 如要計算跨事件的指標，需要哪種匯總方式？請試著規劃邏輯步驟。(例如：在尖峰時段，比較機群子集的 ETA/ATA 與服務等級目標，計算資源受限時的效能。
  • 為什麼您對事件導向模型感興趣，而不是批次模型？是為了降低延遲 (採取行動所需時間)，還是為了鬆耦合整合 (靈活度)？
    • 如果是低延遲，請定義「低」。分鐘？幾秒鐘？不到一秒？延遲時間為何？
  • 團隊是否已投資技術堆疊和相關技能？If so, what is it and what integration points does it provide?
    • 在處理車隊事件時，是否有任何需求是現有系統無法滿足或難以達成的？

設計原則

遵循一些思考過程，對您總是有幫助。這有助於做出一致的設計決策，尤其是在有多種選項可供選擇時。

  • 預設為較簡單的選項。
  • 預設為縮短創造價值的時間。程式碼較少，學習曲線較低。
  • 在延遲時間和效能方面，請以達到設定的標準為目標，而非追求最大程度的最佳化。此外，也請避免過度最佳化，因為這通常會增加複雜度。
  • 費用也是如此。維持合理費用。您可能尚未達到可以承諾使用高價值但相對昂貴服務的狀態。
  • 在實驗階段，縮減資源與擴充資源同樣重要。建議您選擇可彈性擴充 (設有上限) 和縮減 (最好能縮減至零) 的平台，這樣就不會在閒置時產生費用。等到您確定有需要時，再考慮採用全天候運作的高效能基礎架構。
  • 觀察並評估，以便日後找出需要進一步處理的部分。
  • 讓服務保持鬆耦合狀態。這樣一來，日後就能更輕鬆地逐一更換。
  • 最後，安全性不容忽視。由於這項服務是在公有雲環境中執行，因此系統不能有任何不安全的入口。

串流概念

如果您對事件型或串流處理相對陌生，請務必瞭解一些重要概念，其中有些概念可能與批次處理截然不同。

  • 規模：批次處理通常能準確預估要處理的資料量，但串流處理則無法。城市中的交通壅塞可能會突然從特定區域產生大量事件，而您仍須能夠處理這些事件。
  • 視窗化：您通常會希望將時間軸上的事件分組為較小的「視窗」，做為運算單位，而不是逐一處理事件。您可以選擇各種視窗策略，例如「固定視窗 (例如每個日曆日)」、「滑動視窗 (過去 5 分鐘)」、「工作階段視窗 (在這趟行程期間)」。時間範圍越長，產生結果的延遲時間就越長。請選擇符合需求的模型和設定。
  • 觸發：在某些情況下，您別無選擇，只能設定較長的回溯期。不過，您不希望等到視窗結束才產生事件，而是希望在中間發出中間結果。如果先傳回快速結果，再進行修正，對用途有價值，則可採用這個概念。想像一下，在運送進度達到 25%、50%、75% 時，發出中間狀態。
  • 排序：事件不一定會按照生成順序傳送至系統。尤其是涉及透過行動網路通訊的用途，會增加延遲時間和複雜的轉送路徑。您必須瞭解「事件時間」(事件實際發生的時間) 和「處理時間」(事件到達系統的時間) 之間的差異，並據此處理事件。一般來說，您會希望根據「事件時間」處理事件。
  • 訊息傳遞 - 至少一次與僅一次：不同的事件平台對這些模式的支援程度不同。視用途而定，您可能需要考慮重試或簡化策略。
  • 完整性：就像順序變更一樣，訊息也有可能遺失。這可能是因為裝置電池續航力不足，導致應用程式和裝置關機、手機意外損壞、在隧道中失去連線能力，或是在可接受的時間範圍外才收到訊息。不完整性會對結果造成什麼影響？

這份清單僅供參考，並未列出所有可能情況。以下推薦幾篇優質文章，有助於你進一步瞭解各項概念。

貢獻者

這份文件由 Google 維護。以下是原始作者。

主要作者：