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

来自在地面运行的车队的近乎实时的信号在很多方面对企业都很有用。例如，商家可以使用这些信息来：

  • 监控舰队的性能并尽早发现潜在问题
  • 通过提供准确的预计到达时间和跟踪信息来改善客户服务
  • 找出效率低下的问题并予以解决，从而降低成本
  • 通过监控驾驶员行为和识别潜在危险来提升安全性
  • 优化司机路线和时间表，提高效率
  • 跟踪车辆位置和保养时间，以遵守相关法规

本文档说明了开发者如何将来自 Google Maps Platform 的移动服务（“最后一公里车队解决方案”(LMFS) 或按需乘车和送货解决方案 (ODRD) 的信号）转换为可操作的自定义事件。此外，还介绍了 GitHub 上提供的舰队事件参考解决方案的主要概念和设计决策。

本文档涉及以下主题：

  • 熟悉 Google Maps Platform 的“移动服务”及其核心组件“Fleet Engine”的架构师。如果您刚开始接触“移动服务”，我们建议您根据您的需求熟悉最后一公里车队解决方案和/或按需乘车和送货解决方案。
  • 熟悉 Google Cloud 的架构师。如果您刚开始接触 Google Cloud，建议您先阅读在 Google Cloud 上构建流式数据流水线。
  • 如果您以其他环境或软件堆栈为目标平台，请专注于了解 Fleet Engine 的集成点和关键注意事项（这些因素仍适用）。
  • 一般有兴趣探索如何生成和利用来自舰队的事件的用户。

读完本文档后，您应该对流式传输系统的关键元素和注意事项以及构成舰队事件参考解决方案的 Google Maps Platform 和 Google Cloud 的构建块有基本的了解。

舰队事件参考解决方案概览

舰队事件参考解决方案是一种开源解决方案，使 Mobility 客户和合作伙伴能够在 Fleet Engine 和 Google Cloud 组件上生成关键事件。如今，参考解决方案支持使用最后一公里车队解决方案的客户，并且之后支持按需乘车和送货。

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

  • 任务到达时间发生变化
  • 任务到达时的相对预计到达时间变化
  • 任务到达剩余时间
  • 任务到达的剩余距离
  • TaskOutcome 状态更改

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

逻辑组成要素

示意图：下图显示了构成舰队事件参考解决方案的高级基础组件

舰队事件概览和逻辑组成要素

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

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

服务选择

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

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

舰队事件参考解决方案基础组件

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 作为初始版本的计算平台 (*)
    • 无服务器，通过扩缩控制来管理成本
    • 考虑到 Fleet Engine 相关 API 的客户端库可用性，将 Java 作为编程语言，这些客户端库有助于简化实现
  • 使用 Cloud Firestore 作为状态存储
    • 无服务器键值对存储区
  • Cloud Pub/Sub 作为与上游和下游组件的集成点
    • 松散耦合的近实时集成

这些函数可以在默认设置下按原样使用，但也可以重新配置。配置参数通过部署脚本设置，详情记录在相应的 Terraform 模块自述文件。

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

部署

为了使参考解决方案部署过程可重复、可自定义、源代码可控制且安全无虞，我们选择 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 服务中捕获或生成的数据？或者，是否需要通过集成的外部系统来丰富数据？如果是，这些系统有哪些？提供哪些集成接口？
    • 您希望作为商家衡量哪些指标？它们是如何定义的？
    • 如果您需要跨事件计算指标，则需要哪种汇总？尽量合理安排逻辑步骤的布局。（例如在高峰时段比较舰队各子部分的 ETA/ATA 与 SLO，以便在资源限制下计算性能。）
  • 您为什么对基于事件的模型或批量模型感兴趣？这是为了缩短延迟时间（操作时间）还是松散耦合的集成（敏捷性）？
    • 如果延迟时间较短，请定义“低”。分钟？秒？亚秒级？延迟有多高？
  • 作为团队，您是否已经投资于技术栈和相关技能？如果是，它是什么？提供哪些集成点？
    • 在处理来自舰队的事件时，是否有任何要求无法满足或无法满足？

设计原则

遵循一些思维过程总是很有帮助的。这有助于做出一致的设计决策，尤其是当您有多种选项可供选择时。

  • 默认使用更简单的选项。
  • 默认为缩短价值实现时间。代码更少，学习曲线更低。
  • 在延迟时间和性能方面，应力求达到您设置的标准，而不是最大限度的优化。此外，还应避免过度优化，因为这样通常会导致复杂性。
  • 在费用方面也是如此。确保费用合理。您可能还无法承诺使用高价值但相对更昂贵的服务。
  • 在实验阶段，纵向缩容与纵向扩容一样重要。设想一个平台既可灵活扩容，同时设置上限和缩容（理想情况下为零），这样您什么也不用，不用花钱。在旅程的后期，当您确信其需求时，可以考虑使用始终开启的高性能基础架构。
  • 观察和衡量，以便日后确定有待进一步改进的地方。
  • 使服务松散耦合。这样更便于以后逐段交换。
  • 最后但同样重要的一点是，安全性不容忽视。作为一项在公有云环境中运行的服务，连接系统必不可少。

流式传输概念

如果您对基于事件的或流式传输不太熟悉，则有一些关键概念值得注意，其中一些概念与批处理可能截然不同。

  • 扩缩：与批处理（通常您对要处理的数据量有一个很好的想法，但在流式处理中却无法做到）不同。城市中的交通拥堵可能会突然从特定区域引发大量事件，您仍需能够对其进行处理。
  • 数据选取：通常，您希望将时间轴上的事件划分为较小的“窗口”作为计算单元，而不是逐个处理事件。有多种窗口策略可供选择，如“固定窗口（例如每个日历日）”“滑动窗口（过去 5 分钟”）和“会话窗口（此行程期间）”。这个时段越长，生成结果的延迟时间就越长。选择符合您需求的合适模型和配置。
  • 触发：除了相对较长的窗口之外，您别无选择。您还是不想等待窗口结束时生成事件，而是要在两者之间发出中间结果。该概念可以用于以下用例：先返回快速结果，然后再更正结果。假设在交付完成 25%、50%、75% 时发出“中等”状态。
  • 排序：事件不一定会按生成顺序到达系统。尤其是涉及通过移动网络通信会增加延迟和复杂路由路径的用例。您需要注意“事件时间”（事件实际发生时间）与“处理时间”（事件到达系统时）之间的差异，并相应地处理事件。一般来说，您需要根据“事件时间”处理事件。
  • 消息传送 - 至少一次与仅一次：不同的事件平台对这方面的支持有所不同。根据您的使用场景，您需要考虑重试或删除重复策略。
  • 完整性：与更改顺序一样，消息也可能会丢失。这可能是由于以下原因导致的应用和设备关闭：设备的电池续航时间、手机意外损坏、在隧道中失去连接，或者仅在可接受的窗口范围外接收的消息。不完整对结果有何影响？

以上并未列出所有情况，只是简单介绍一下。下面是一些备受推荐的读物，可帮助您进一步加深对每一种的理解。

贡献者

此文档由 Google 维护。该博文最初由以下贡献者编写。

主要作者：