使用 Fleet Engine 和舰队事件参考解决方案生成近乎实时的事件

来自地面运营车队的近乎实时信号可从多个方面帮助企业。例如，商家可以使用这些功能来执行以下操作：

  • 监控车队的性能，并尽早发现潜在问题
  • 通过提供准确的预计到达时间和物流跟踪信息来改善客户服务
  • 通过发现并解决效率低下的问题来降低费用
  • 通过监控驾驶员行为和识别潜在危险来提高安全性
  • 优化司机路线和行程安排，以提高效率
  • 通过跟踪车辆位置和服务时间来遵守法规

本文档说明了开发者如何将 Google Maps Platform 的“出行服务”（“最后一英里车队解决方案”(LMFS) 或“按需乘车和送货解决方案”(ODRD)）中的信号转化为可操作的自定义事件。此外，本文档还介绍了 GitHub 上提供的 Fleet Events Reference Solution 的关键概念和设计决策。

本文档适用于：

  • 熟悉 Google Maps Platform 的“移动服务”及其核心组件“Fleet Engine”的架构师。如果您是“出行服务”的新手，我们建议您根据自己的需求，先熟悉最后一公里舰队解决方案和/或按需乘车和送货解决方案。
  • 熟悉 Google Cloud 的架构师。对于刚开始使用 Google Cloud 的用户，建议先阅读在 Google Cloud 上构建流式数据流水线。
  • 如果您面向其他环境或软件堆栈，请重点了解 Fleet Engine 的集成点和关键注意事项，这些内容应该仍然适用。
  • 对探索如何生成和利用车队事件有一般兴趣的人员。

阅读完本文档后，您应该对流式传输系统的关键要素和注意事项有基本的了解，并且知道 Google Maps Platform 和 Google Cloud 的哪些构建块构成了车队事件参考解决方案。

Fleet Events 参考解决方案概览

Fleet Events 参考解决方案是一种开源解决方案，可让出行客户和合作伙伴基于 Fleet Engine 和 Google Cloud 组件生成关键事件。目前，该参考解决方案支持使用最后一公里车队解决方案的客户，后续还将支持按需驾车和送货。

该解决方案会根据与任务或行程关联的特定数据的变化自动生成事件。您可以使用这些事件向利益相关者发送如下通知，或为车队触发其他操作。

  • 任务到达的 ETA 变更
  • 任务到达的相对 ETA 变化
  • 任务到达前的剩余时间
  • 到达任务地点的剩余距离
  • TaskOutcome 状态更改

参考解决方案的每个组成部分都可以自定义，以满足您的业务需求。

逻辑构建块

图表：下图展示了构成 Fleet Events 参考解决方案的高级构建块

Fleet Events 概览和逻辑构建块

参考解决方案包含以下组件：

  • 事件源：原始事件流的来源。“最后一公里车队解决方案”或“按需乘车和送货解决方案”均与 Cloud Logging 集成，可帮助将 Fleet Engine RPC 调用日志转换为可供开发者使用的事件流。这是要使用的核心来源。
  • 处理：原始 RPC 调用日志将在此块中转换为状态更改事件，该块可针对日志事件流进行计算。为了检测此类变化，此组件需要一个状态存储区，以便将新的传入事件与之前的事件进行比较，从而检测变化。事件可能并不总是包含所有感兴趣的信息。在这种情况下，此块可能会根据需要向后端发出查找调用。
    • 状态存储区：某些处理框架会自行提供中间数据的持久性。但如果不是，为了自行存储状态，由于这些状态应是车辆和事件类型独有的，因此 K-V 类型的数据持久性服务非常适合。
  • 接收器（自定义事件）：检测到的状态变化应提供给任何可以从中受益的应用或服务。因此，将此自定义事件发布到事件传送系统以供下游使用是一个自然的选择。
  • 下游服务：使用生成的事件并根据您的使用情形采取独特行动的代码。

服务选择

在实现“最后一公里车队解决方案”或“按需乘车和送货解决方案”（将于 2023 年第 3 季度末推出）的参考解决方案时，“源”和“接收器”的技术选择非常简单。另一方面，“处理”有多种选项。 参考解决方案选择了以下 Google 服务。

图表：下图显示了用于实现参考解决方案的 Google Cloud 服务

Fleet Events 参考解决方案构建块

Cloud 项目布局

我们建议您默认采用多项目部署。这样一来，Google Maps Platform 和 Google Cloud 的用量就可以清晰地分开，并与您选择的结算安排相关联。

事件来源

“最后一公里车队解决方案”和“按需驾车和送货解决方案”将 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 模块自述文件中详细记录。

*注意：此参考解决方案计划发布可帮助满足不同要求的替代实现。

部署

为了使参考解决方案部署流程可重复、可自定义、源代码可控且安全，我们选择 Terraform 作为自动化工具。Terraform 是一种广泛使用的 IaC（基础设施即代码）工具，可为 Google Cloud 提供丰富的支持。

Terraform 模块

我们没有制作一个大型的单体参考解决方案部署模块，而是将可重用的自动化块实现为可独立使用的 Terraform 模块。模块提供了各种可配置的变量，其中大多数变量都有默认值，因此您可以快速上手，同时也可以根据自己的需求和偏好灵活地进行自定义。

参考解决方案中包含的模块：

  • Fleet Engine 日志记录配置：自动执行与 Cloud Logging 相关的配置，以便与 Fleet Engine 搭配使用。在参考解决方案中，它用于将 Fleet Engine 相关日志路由到指定的 Pub/Sub 主题。
  • Fleet Events Cloud Functions 部署：包含示例函数代码部署，还可自动处理安全跨项目集成所需的权限设置。
  • 整个参考解决方案部署：调用前两个模块并封装整个解决方案。

安全

采用 IAM 来应用最小权限原则，并遵循 Google Cloud 的安全最佳实践，例如服务账号模拟。请参阅以下文章，以便更好地了解 Google Cloud 提供的功能，从而更好地掌控安全性。

后续操作

现在，您可以访问并进一步探索车队活动参考解决方案了。 前往 GitHub 即可开始使用。

附录

收集要求

我们建议您在流程的早期阶段收集需求。

首先，请详细说明您为何对近乎实时的事件感兴趣或需要使用此类事件。以下问题有助于您明确自己的需求。

  • 哪些信息对于事件流来说是必需的？
    • 结果是否完全可以从 Google 服务中捕获或生成的数据中得出？或者，是否需要通过集成外部系统来丰富数据？如果有，这些系统是什么，它们提供哪些集成接口？
    • 您希望衡量哪些业务指标？如何定义？
    • 如果您需要跨事件计算指标，需要进行哪种类型的汇总？尝试列出逻辑步骤。（例如 在高峰时段比较部分车队的 ETA/ATA 与 SLO，以计算资源受限时的性能。）
  • 您为什么对基于事件的模型感兴趣，而不是批处理？是为了缩短延迟时间（从操作到响应的时间）还是为了实现松散耦合的集成（灵活性）？
    • 如果为低延迟，则定义为“low”。分钟？秒？亚秒级？延迟时间是多少？
  • 您是否已投资于技术堆栈和相关技能？如果有，请说明该平台是什么以及它提供了哪些集成点？
    • 您当前的系统在处理来自车队的事件时，是否无法满足任何要求或可能遇到困难？

设计原则

始终遵循一定的思考过程会很有用。这有助于做出一致的设计决策，尤其是在有多种选项可供选择时。

  • 默认采用更简单的选项。
  • 默认缩短价值实现时间。代码更少，学习曲线更平缓。
  • 对于延迟时间和性能，请力求达到您设置的最低标准，而不是实现最大程度的优化。此外，还要避免过度优化，因为这往往会导致复杂性增加。
  • 费用也是如此。保持合理的费用。您可能尚未达到可以承诺使用高价值但相对更昂贵的服务状态。
  • 在实验阶段，缩减与扩容同样重要。考虑使用可灵活扩容（有上限）和缩容（最好是缩减至零）的平台，这样您在不执行任何操作时就不会产生费用。当您确信自己需要高性能且始终处于开启状态的基础设施时，可以在稍后考虑。
  • 进行观察和测量，以便日后确定需要进一步改进的地方。
  • 保持服务松散耦合。这样一来，以后就可以更轻松地逐个替换组件。
  • 最后但同样重要的是，安全性不能放松。作为在公共云环境中运行的服务，系统不能有任何不安全的入口。

流式传输概念

如果您对基于事件或流式处理相对比较陌生，那么有一些关键概念值得了解，其中一些概念与批处理有很大不同。

  • 规模：与批处理（您通常可以很好地了解要处理的数据量）相比，在流处理中，您无法了解要处理的数据量。城市中的交通拥堵可能会突然导致特定区域产生大量事件，您仍然需要能够处理这些事件。
  • 窗口化：您通常不会逐个处理事件，而是希望将时间轴上的事件分组到较小的“窗口”中，以便进行计算。有多种开窗策略，例如“固定窗口（例如，每个日历日）”“滑动窗口（过去 5 分钟）”“会话窗口（本次行程期间）”，您可以从中进行选择。窗口越长，生成结果的延迟时间就越长。 选择符合您要求的合适型号和配置。
  • 触发：在某些情况下，您别无选择，只能使用相对较长的窗口期。不过，您并不希望等到窗口结束时才生成事件，而是希望在窗口期间发出中间结果。此概念可用于以下用例：先返回快速结果，然后再更正这些结果。假设在配送完成 25%、50%、75% 时发出中间状态。
  • 排序：事件到达系统的顺序不一定与生成顺序相同。尤其适用于涉及通过移动网络进行通信的用例，因为移动网络会增加延迟并导致路由路径复杂。您需要了解“事件时间”（事件实际发生的时间）和“处理时间”（事件到达系统的时间）之间的区别，并相应地处理事件。一般来说，您需要根据“事件时间”处理事件。
  • 消息传送 - 至少一次与恰好一次：不同的事件平台对此的支持程度各不相同。根据您的使用情形，您需要考虑重试或去重策略。
  • 完整性：与更改排序一样，消息可能会丢失。这可能是由于设备电池续航时间不足导致应用和设备关机、手机意外损坏、在隧道中时连接中断，或者收到的消息仅在可接受的时间范围之外。不完整性会对结果产生什么影响？

以下并未列出所有情况，只是简单介绍一下。以下是一些强烈推荐的读物，可帮助您进一步加深对每种类型的了解。

贡献者

Google 负责维护本文档。以下贡献者最初撰写了此内容。

主要作者：