運用 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 參考解決方案的建構元素

雲端專案版面配置

建議您預設為多專案部署。這樣一來，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 函式部署：包含函式程式碼部署範例，以及處理安全跨專案整合所需的權限設定自動化。
  • 整個參考解決方案部署作業：呼叫前面兩個模組，並包裝整個解決方案。

安全性

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

後續行動

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

附錄

收集需求

建議您在程序中盡早收集需求。

首先，請擷取詳細資料，瞭解您想瞭解或需要使用近乎即時事件的原因。以下問題可協助你釐清自己的需求。

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

設計原則

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

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

串流概念

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

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

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

貢獻者

本文件由 Google 維護。下列提供者原本可以撰寫您的簽名。

主要作者：