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

来自地面车队的近乎实时信号对企业有诸多用途。例如，商家可以使用这些功能来：

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

本文档介绍了开发者如何将 Google Maps Platform 的“出行服务”（“最后一公里车队解决方案”[LMFS] 或“按需叫车和配送解决方案”[ODRD]）中的信号转换为富有实用价值的自定义事件。此外，还介绍了 GitHub 上提供的车队事件参考解决方案的关键概念和设计决策。

本文档与以下内容相关：

  • 熟悉 Google Maps Platform 的“出行服务”及其核心组件之一“车队引擎”的架构师。对于刚接触“出行服务”的用户，我们建议您根据自己的需求熟悉最后一公里车队解决方案和/或按需叫车和配送解决方案。
  • 熟悉 Google Cloud 的架构师。对于刚接触 Google Cloud 的用户，建议先阅读在 Google Cloud 上构建流式数据流水线。
  • 如果您以其他环境或软件堆栈为目标平台，请重点了解车队引擎的集成点和关键注意事项，这些内容应该仍然适用。
  • 有兴趣探索如何生成和利用车队事件的人员。

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

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

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

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

  • 任务到达时间的 ETA 更改
  • 任务到达的相对 ETA 变化
  • 任务到达时间剩余
  • 距离任务到达还有多远
  • TaskOutcome 状态更改

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

逻辑构建块

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

车队事件概览和逻辑构建块

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

  • 事件来源：原始事件流的来源。“最后一公里车队解决方案”或“按需叫车和配送解决方案”都与 Cloud Logging 集成，可帮助将车队引擎 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 搭配使用。在参考解决方案中，它用于将车队引擎相关日志路由到指定的 Pub/Sub 主题。
  • 车队事件 Cloud Functions 函数部署：包含示例函数代码部署，还会处理安全跨项目集成所需的权限设置自动化。
  • 整个参考解决方案部署：调用前两个模块并封装整个解决方案。

安全

我们采用 IAM 来应用最小权限原则，并遵循 Google Cloud 的安全最佳实践（例如服务账号冒用）。请参阅以下文章，更好地了解 Google Cloud 提供哪些功能来帮助您更好地控制安全性。

后续操作

现在，您可以访问并进一步探索“车队事件”参考解决方案了。请前往 GitHub 开始使用。

附录

收集要求

我们建议您尽早收集要求。

首先，详细说明您为何有兴趣或需要使用近实时事件。以下是一些有助于您明确需求的问题。

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

设计原则

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

  • 默认使用更简单的选项。
  • 默认缩短价值实现时间。代码更少，学习曲线更短。
  • 对于延迟时间和性能，应以达到您设定的标准为目标，而不是最大限度地进行优化。此外，还应避免过度优化，因为这通常会增加复杂性。
  • 费用也是如此。将费用控制在合理范围内。您可能还没有达到可以承诺使用价值较高但相对较贵的服务的状态。
  • 在实验阶段，缩减规模与扩容一样重要。不妨考虑使用可灵活扩容（上限）和缩容（最好为零）的平台，以便在没有任何活动时不产生费用。在您确信需要时，可以考虑在后续阶段考虑采用高性能的始终开启型基础架构。
  • 观察和衡量，以便日后确定需要进一步改进的地方。
  • 使服务保持松散耦合。这样以后就可以更轻松地逐个交换。
  • 最后但同样重要的是，安全性不能松懈。作为在公共云环境中运行的服务，系统不得有任何不安全的入口。

流式传输概念

如果您对基于事件的报告或流式报告还不太熟悉，则有几个关键概念值得注意，其中一些概念可能与批量处理大不相同。

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

此处并未列出所有情况，只是说明最常见的账号停用原因。以下是一些强烈建议阅读的文章，可帮助您进一步加深对每种方法的理解。

贡献者

此文档由 Google 维护。以下贡献者最初撰写了这篇文章。

主要作者：