運用 Fleet Engine 和機群事件參考解決方案，產生近乎即時的事件

企業可透過多種方式，運用車隊在地面上運作時近乎即時的信號。舉例來說，商家可以利用這些功能：

  • 監控車隊的運作狀況，及早找出潛在問題
  • 提供準確的預計抵達時間和追蹤資訊，提升客戶服務品質
  • 找出並解決效率不彰的問題，進而降低成本
  • 監控駕駛行為並找出潛在危險，進而提升安全性
  • 調整駕駛員路線和時間表，提高效率
  • 追蹤車輛位置和服務時數，確保符合法規

本文說明開發人員如何將 Google 地圖平台「行動服務」(「最後一哩車隊解決方案」(LMFS) 或「隨選乘車和外送解決方案」(ODRD)) 的信號，轉換為可執行的自訂事件。此外，我們也會介紹 GitHub 上的 Fleet Events Reference Solution 的重要概念和設計決策。

這份文件適用於：

  • 熟悉 Google 地圖平台「行動服務」和其中一個核心元件「Fleet Engine」的架構師。如果您是「行動服務」的新手，建議您先瞭解最後一里車隊解決方案和/或隨選乘車和外送解決方案，再決定要使用哪項服務。
  • 熟悉 Google Cloud 的架構師。如果您是 Google Cloud 新手，建議先閱讀在 Google Cloud 上建構串流資料管道。
  • 如果您是以其他環境或軟體堆疊為目標，請著重瞭解 Fleet Engine 的整合點和重要考量事項，這些內容應該還是適用。
  • 對如何產生及運用車隊事件感興趣的一般使用者。

讀完本文後，您應該會對串流系統的主要元素和考量因素有基本瞭解，並認識 Google 地圖平台和 Google Cloud 的建構區塊，這些區塊組成了車隊事件參考解決方案。

車隊事件參考解決方案總覽

車隊事件參考解決方案是開放原始碼解決方案，可讓行動裝置客戶和合作夥伴在 Fleet Engine 和 Google Cloud 元件上產生重要事件。目前，參考解決方案支援使用 Last Mile Fleet Solution 的客戶，並支援 On-demand Rides and Delivery。

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

  • 工作抵達時間預估異動
  • 工作抵達時間的相對預計抵達時間變化
  • 工作抵達前的剩餘時間
  • 抵達工作地點的剩餘距離
  • TaskOutcome 狀態變更

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

邏輯建構模塊

圖表：下圖顯示構成 Fleet Events 參考解決方案的高階建構區塊

機群事件總覽和邏輯建構區塊

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

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

選取服務

實作「最後一里車隊解決方案」或「隨選乘車和外送解決方案」(2023 年第 3 季末推出) 的參考解決方案時，「來源」和「接收器」的技術選擇很簡單。另一方面，「處理」則有許多選項。參考解決方案已選擇下列 Google 服務。

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

機群事件參考解決方案建構區塊

Cloud 專案配置

建議您預設採用多專案部署作業。這樣一來，Google 地圖平台和 Google Cloud 的用量就能清楚區隔，並與您選擇的帳單方案連結。

事件來源

「Last Mile Fleet Solution」和「On-demand Rides and Deliveries Solution」會將 API 要求和回應酬載寫入 Cloud Logging。Cloud Logging 會將記錄檔傳送至一或多個所選服務。因此，將記錄檔傳送至 Cloud Pub/Sub 是絕佳選擇，可讓您將記錄檔轉換為事件串流，不必編寫程式碼。

接收器

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

處理中

下列元件在事件處理程序中扮演重要角色。與其他建構區塊一樣，處理元件完全無伺服器，且可向上和向下擴充。

  • Cloud Functions 做為初始版本的運算平台 (*)
    • 無伺服器，可透過擴充控制項擴充和縮減規模，以控管成本
    • Java 程式設計語言，因為 Fleet Engine 相關 API 提供用戶端程式庫，有助於簡化實作程序
  • 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 Functions 部署作業：包含範例函式程式碼部署作業，並處理安全跨專案整合所需的權限設定自動化作業。
  • 部署整個參照解決方案：呼叫前兩個模組，並包裝整個解決方案。

安全性

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

後續行動

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

附錄

匯集相關規定

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

首先，請擷取您對近乎即時事件感興趣或需要使用這類事件的詳細原因。以下幾個問題有助於釐清需求。

  • 事件串流需要哪些資訊才能發揮效用？
    • 結果是否完全根據 Google 服務擷取或產生的資料得出？或者，是否需要透過整合的外部系統擴充資料？如果是，這些系統為何？提供哪些整合介面？
    • 您想評估哪些業務指標？如何定義？
    • 如要計算跨事件的指標，需要哪種彙整？請嘗試列出邏輯步驟。(例如：在尖峰時段，比較車隊子集的預計抵達時間/實際抵達時間與服務等級目標，計算資源受限時的成效。
  • 您為何對以事件為基礎的模型感興趣，而非批次模型？這是為了降低延遲 (採取行動所需的時間)，還是為了鬆散耦合的整合 (靈活度)？
    • 如為低延遲，請定義「low」。分鐘？秒？不到一秒？延遲時間為何？
  • 您是否已投資技術堆疊和相關技能？如果是，該服務為何？提供哪些整合點？
    • 您目前的系統是否無法滿足任何需求，或在處理來自整批裝置的事件時可能遇到困難？

設計原則

有思考流程可遵循總是很有幫助。這有助於做出一致的設計決策，特別是在有多種選項可供選擇時。

  • 預設為較簡單的選項。
  • 預設為縮短創造價值的時間。程式碼較少，學習曲線較平緩。
  • 就延遲時間和效能而言，請以達到您設定的標準為目標，而非盡可能最佳化。此外，也請避免過度最佳化，因為這通常會導致複雜度增加。
  • 費用也是如此。確保成本合理。您可能還無法承諾使用高價值但相對較昂貴的服務。
  • 在實驗階段，縮減規模與擴大規模同樣重要。 建議您選擇可彈性擴充的平台，並設定上限，同時也能縮減規模 (最好是縮減至零)，這樣在沒有任何工作時就不會產生費用。等到您確信需要高成效的基礎架構時，再考慮採用這類基礎架構。
  • 觀察及評估，以便日後找出需要進一步改善的地方。
  • 保持服務鬆耦合。方便日後逐一更換。
  • 最後，安全性絕不能鬆懈。由於服務是在公有雲環境中執行，系統不得有任何不安全的入口。

串流概念

如果您是事件或串流處理的新手，建議先瞭解一些重要概念，其中有些概念與批次處理大相逕庭。

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

以下僅為簡介，並未包含所有情況。以下是我們極力推薦的讀物，有助於您進一步瞭解各項主題。

貢獻者

Google 會維護這份文件。以下是這篇文章的原始撰稿人。

主要作者：