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

從地上作業的車隊具有近乎即時的信號，對商家來說有很多好處。舉例來說，商家可以用這些資訊來：

  • 監控機群的效能，及早發現潛在問題
  • 提供準確的預計到達時間和追蹤資訊，提升客戶服務品質
  • 找出並解決效率低落的問題，藉此降低成本
  • 監控駕駛行為並找出潛在危害，進而改善安全性
  • 設定最佳駕駛路線和時刻表，以提升駕駛效率
  • 追蹤車輛位置和服務時間，以符合法規

本文說明開發人員如何將 Google 地圖平台的「行動性服務」的信號 (「Last Mile Fleet Solution" (LMFS) 或「隨選乘車和配送解決方案」(ODRD) 信號轉換為可採取行動的自訂事件)。本文也會介紹 GitHub 上機群事件參考資料解決方案的重要概念和設計決策。

這份文件與以下主題相關：

閱讀本文件內容後，您應有基本的瞭解串流系統的關鍵元素和注意事項，以及構成機群事件參考資料解決方案的 Google 地圖平台和 Google Cloud 構成元素。

機群事件參考資料解決方案總覽

「機群事件參考資料」解決方案是一項開放原始碼解決方案，可讓行動客戶和合作夥伴在 Fleet Engine 和 Google Cloud 元件上產生重要事件。目前，參考解決方案支援使用 Last Mile Fleet Solution 的客戶，並支援隨選乘車和外送服務。

解決方案會根據工作或行程相關特定資料的變化自動產生事件。您可以使用這些事件傳送通知 (例如以下內容) 給相關人員，或觸發機群的其他動作。

  • 工作抵達時間的預計到達時間變更
  • 到達工作抵達時間的相對預計到達時間變化
  • 距離工作抵達所剩時間
  • 距離工作抵達所剩的距離
  • TaskOutcome 狀態變更

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

邏輯構成元素

圖表：下圖顯示構成機群事件參考解決方案的高階建構區塊

機群事件總覽與邏輯建構模塊

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

  • 事件來源：原始事件串流的來源。「Last Mile Fleet Solution」或「On-Demand Rides and Deliveries 解決方案」與 Cloud Logging 皆整合 Cloud Logging，能協助將 Fleet Engine RPC 呼叫記錄檔轉換成可供開發人員使用的事件串流。這是要使用的核心來源。
  • 處理：原始遠端程序呼叫 (RPC) 記錄會轉換為這個區塊內的狀態變更事件，透過一連串的記錄事件進行計算。如要偵測這類變更，這個元件需要狀態儲存區，以便與先前的傳入事件進行比較，以偵測變更。事件不一定每次都會包含所有感興趣的資訊。在這種情況下，這個區塊可能會視需要查詢對後端的呼叫。
    • 狀態儲存庫：部分處理架構會自行提供中繼資料。但如果不是的話，為了自行儲存狀態，由於車輛和事件類型不得重複，K-V 類型資料持續性服務會是不錯的選擇。
  • 接收器 (自訂事件)：偵測到狀態變更時，應針對任何可獲益的應用程式或服務提供偵測狀態變更。因此，您可以將這個自訂事件發布至事件傳送系統，以便下游使用。
  • 下游服務：使用產生的事件，並採取特定用途動作的程式碼。

選擇服務

當您要實作「Last Mile Fleet Solutions」或「On-Demand Rides and Deliveries Solutions」的參考解決方案 (將於 2023 年第 3 季下旬推出)，「來源」和「接收器」技術選擇是相當簡單明瞭的。另一方面，「處理中」則有許多選項。參考解決方案選擇了下列 Google 服務。

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

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

Cloud 專案版面配置

建議您預設採用多專案部署作業。這樣一來，Google 地圖平台和 Google Cloud 的用量就能明確分隔，並與您選擇的計費方式相互關聯。

事件來源

「Last Mile Fleet Solutions」和「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 做為初始版本 (*) 的運算平台
    • 採用無伺服器技術，可透過資源調度控制項調度資源，藉此控管成本
    • 考量到 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 主題。
  • 機群事件雲端函式部署：包含範例函式程式碼部署，並處理安全跨專案整合所需的權限設定自動化。
  • 整個參考解決方案部署：呼叫前兩個模組，並包裝整個解決方案。

安全性

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

後續行動

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

附錄

蒐集需求

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

首先，請找出您感興趣或需要使用近乎即時事件的詳細資料。以下幾個問題可協助你將自身需求納入考量。

  • 事件串流需要哪些資訊？
    • 結果可以純粹從 Google 服務中擷取或產生的資料產生嗎？或者，是否需要搭配整合式外部系統 強化資料？如果是，這些系統為何？它們提供哪些整合介面？
    • 你想為商家評估哪些指標？其定義為何？
    • 如果您需要計算跨事件的指標，則需要哪種匯總？嘗試安排邏輯步驟的版面配置。(例如：在尖峰時段，將整個機群子部分的預計到達/ATA 與服務等級目標比較，以便在資源限制下運算效能。)
  • 您為什麼想瞭解以事件為基礎的模型，還是不想進行批次處理？這是用於縮短延遲時間 (操作時間) 還是鬆耦合的整合 (靈活性)？
    • 如果是低延遲時間，請定義「低」。分鐘數？幾秒？時間不到一秒？到底是怎麼辦到的？
  • 您是否已經/團隊投入技術堆疊和相關技能？如果有的話，服務內容為何？整合點提供哪些整合點？
    • 處理機群的事件時，目前系統是否有任何無法達到或難以解決的要求？

設計原則

請務必按部就班地思考。這有助於做出一致的設計決策，特別是當您有許多選項可以選擇時。

  • 預設為較簡單的選項。
  • 預設為較短的時間值。程式碼較少，學習曲線較少。
  • 至於延遲時間和效能，請力求達到您設定的標準，而非最佳化。此外，請避免過度最佳化，因為這麼做通常會增加複雜度。
  • 費用也是如此。維持合理成本。您可能尚未處於您可以承諾使用高價值但價格較高的服務的狀態。
  • 在實驗階段，縮減資源與擴充一樣重要。假設採用這個平台，透過上限彈性向上擴充，也能縮減資源數量 (最好是零)，以免您不採取任何行動。若您對基礎架構的需求很有信心，可以在該流程的後續階段考慮採用持續待機的基礎架構來維持高效能。
  • 觀察及測量指標，以便稍後找出需要進一步改善的地方。
  • 保持服務的鬆耦合狀態。這樣之後，就能更輕鬆地為不同的片段進行切換。
  • 最後要提醒您，安全性不能太久。由於服務是在公用雲端環境中運作，因此系統上不會有不安全的門。

串流概念

如果您相對較不熟悉事件或串流，有一些重要概念值得注意，其中一些概念可能會與批次處理大不相同。

  • 規模：與批次處理不同，通常您有足夠的概念可處理的資料量，以串流方式執行。城市中的交通壅塞時，可能從特定區域突然發生大量事件，而您仍需要能夠處理這類事件。
  • 區間設定：您通常不會逐一處理事件，而是將時間軸上的事件分成較小的「時段」做為運算單位。市面上有許多不同的區間策略，例如「固定區間 (例如每天)」、「滑動區間 (過去 5 分鐘)」、「工作階段期 (這趟行程期間)」等，並視需求選用。回溯期越長，產生結果的延遲時間就越長。 選擇符合您需求的模型和設定。
  • 觸發條件：某些情況下，您沒有其他選擇，但相對的回溯期較長。儘管如此，您可能不想等到視窗的最末端產生事件，而應在這兩個時間點之間發出中繼結果。針對此概念，如果其值先傳回快速結果，稍後再修正，則可採用此概念。假設在完成進度
  • 排序：事件不一定會按照產生順序傳送至系統。尤其是在涉及透過行動網路通訊，而增加延遲和複雜轉送路徑的使用案例。您必須瞭解「事件時間」(事件實際發生時) 和「處理時間」(事件到達系統時) 之間的差異，並據此處理事件。一般來說，您想要根據「事件時間」處理事件。
  • 訊息傳送 - 至少一次與僅一次：不同事件平台對這些功能的支援不盡相同。視用途而定，您需要考慮重試或簡化策略。
  • 完整性：如同變更排序，訊息可能會遺失。可能的原因包括應用程式和裝置的電池續航力資訊不完整會對你的結果造成什麼影響？

此處僅列舉部分示例，並未包含所有可能情況。以下列出一些高度推薦的閱讀，有助於您進一步理解每個建議。

貢獻者

Google 負責維護這份文件。以下著作人最初編寫過這個草稿。

主體作者：