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 构建块。

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

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

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

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

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

逻辑构建块

图表：下图显示了构成车队事件参考解决方案的高级构建块

Fleet Events 概览和逻辑构建块

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

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

服务选择

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

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

Fleet Events 参考解决方案构建块

云项目布局

我们建议您默认采用多项目部署。这样，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 进行比较，以计算资源受限情况下的性能。）
  • 为什么您对基于事件的模型感兴趣，而不是对批量模型感兴趣？是为了缩短延迟时间（操作时间），还是为了实现松散耦合的集成（敏捷性）？
    • 如果延迟时间较短，请定义“短”。Minutes? 秒？亚秒级？延迟时间是多少？
  • 作为团队，您是否已经投资了技术栈和相关技能？如果有，请说明该系统是什么，以及它提供哪些集成点。
    • 在处理来自车队的事件时，您的当前系统是否无法满足或可能难以满足某些要求？

设计原则

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

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

流式传输概念

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

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

以下并未列出所有情况，仅作简要介绍。以下是一些强烈推荐的读物，可帮助您进一步加深对每个主题的理解。

贡献者

此文档由 Google 维护。以下贡献者是其最初的作者。

主要作者：