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

從實際運作的車隊取得近乎即時的信號，可為企業帶來多種好處。舉例來說，商家可以使用這些功能來：

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

本文說明開發人員如何將 Google 地圖平台的「Mobility 服務」(「Last Mile Fleet 解決方案」(LMFS) 或「On-demand Rides and Deliveries 解決方案」(ODRD)) 信號轉換為可採取行動的自訂事件。這篇文章也將介紹 GitHub 上提供的車隊事件參考解決方案的關鍵概念和設計決策。

本文件適用於：

  • 熟悉 Google 地圖平台「行動服務」和其中一個核心元件「車隊引擎」的架構師。如果您是「移動服務」的新手，建議您根據需求熟悉最後一里車隊解決方案和/或隨選行程和配送解決方案。
  • 熟悉 Google Cloud 的架構師。如果您是 Google Cloud 的新手，建議先閱讀「在 Google Cloud 上建構串流資料管道」一文。
  • 如果您指定的是其他環境或軟體堆疊，請專注於瞭解 Fleet Engine 的整合點和重要考量事項，這些內容仍適用於您的情況。
  • 對探索車隊事件產生方式和用途有興趣的一般使用者。

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

車輛事件參考資料解決方案總覽

車隊事件參考解決方案是開放原始碼解決方案，可讓 Mobility 客戶和合作夥伴在 Fleet Engine 和 Google Cloud 元件上產生重要事件。目前，參考解決方案支援使用 Last Mile Fleet Solution 的客戶，後續也會支援叫車和外送服務。

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

  • 工作抵達時間的預估到達時間變更
  • 工作到達時間的相對預估到達時間變更
  • 工作到達時間剩餘時間
  • 到達工作地點的剩餘距離
  • TaskOutcome 狀態變更

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

邏輯建構模塊

圖表：下圖顯示組成車隊活動參考解決方案的整體構件

車隊事件總覽和邏輯建構區塊

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

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

服務選項

如要為「Last Mile Fleet Solution」或「On-demand Rides and Deliveries Solution」(將於 2023 年第 3 季推出) 導入參考解決方案，則可直接選擇「Source」和「Sink」的技術。另一方面，「處理」則有許多選項。參考解決方案已選擇下列 Google 服務。

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

Fleet Events 參考解決方案的建構元素

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 主題。
  • 車隊事件雲端函式部署作業：包含範例函式程式碼部署作業，並處理安全跨專案整合作業所需的自動化權限設定。
  • 整個參考解決方案部署作業：呼叫前面兩個模組，並包裝整個解決方案。

安全性

我們採用 IAM 來落實最低權限原則，並遵循 Google Cloud 的安全性最佳做法，例如服務帳戶冒用。請參閱下列文章，進一步瞭解 Google Cloud 提供的功能，以便進一步控管安全性。

後續行動

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

附錄

收集需求

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

首先，請詳細說明您為何有興趣或需要使用近乎即時事件。以下提供一些問題，協助您明確瞭解需求。

  • 事件串流需要哪些資訊才能發揮效用？
    • 結果是否可以完全由 Google 服務中擷取或產生的資料產生？或者，是否需要透過整合的外部系統來強化資料？如果是，請問這些系統是什麼，以及提供哪些整合介面？
    • 貴商家想評估哪些指標？如何定義？
    • 如果您需要跨事件計算指標，需要哪種匯總？請嘗試排列邏輯步驟。(例如：在尖峰時段比較車隊子集的 ETA/ATA 與 SLO，以便在資源受限的情況下計算效能。)
  • 您為何對事件為基礎的模型感興趣，而不是批次？這是否適用於降低延遲 (行動時間) 或鬆散整合 (靈活性)？
    • 如果是為了降低延遲時間，請定義為「low」。分鐘？秒？是否為毫秒？延遲時間為何？
  • 您是否已在團隊中投入技術堆疊和相關技能？如果有的話，請問是什麼，以及提供哪些整合點？
    • 目前的系統是否無法滿足特定需求，或是在處理來自車隊的事件時可能會遇到困難？

設計原則

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

  • 預設為簡易選項。
  • 預設為縮短創造價值的時間。程式碼較少，學習曲線較短。
  • 針對延遲和效能，請設法達到您設定的標準，而非達到最佳化。此外，請避免過度最佳化，因為這通常會導致增加複雜度。
  • 費用也是如此。維持合理的成本。您可能還不願意使用價值高但相對較昂貴的服務。
  • 在實驗階段，縮小規模的必要性與擴大規模一樣重要。建議您考慮採用彈性平台，以便在有上限的情況下向上擴充，並在必要時降至零，避免在無事可做時付費。在您確實需要時，可以考慮在後續階段採用高效能與隨時可用的基礎架構。
  • 觀察及評估，以便日後找出需要進一步改善的部分。
  • 讓服務保持鬆散耦合。這樣之後就能更輕鬆地逐一替換。
  • 最後，安全性不能鬆懈。由於服務是在公用雲端環境中執行，因此系統中不得有任何未受保護的門。

串流概念

如果您是事件或串流處理的新手，請注意以下幾個重要概念，其中有些可能與批次處理截然不同。

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

以下僅列舉部分例子，並未包含所有可能情況。以下是一些極力推薦的閱讀材料，有助於您進一步加深對各項內容的瞭解。

貢獻者

本文件由 Google 維護。以下是原始撰寫者。

主要作者：