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

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

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

本文档说明了开发者如何将 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 调用日志将在此区块中转换为状态更改事件，该区块将对日志事件流进行计算。如需检测此类更改，此组件需要状态存储区，以便将新的传入事件与之前的事件进行比较以检测更改。事件可能并不总是包含所有感兴趣的信息。在这种情况下，此块可能会根据需要向后端发出查找调用。
    • 状态存储区：某些处理框架会自行提供中间数据 持久性。但如果没有，为了自行存储状态，由于这些状态对于车辆和事件类型应该是唯一的，因此 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 以供下游使用。

处理

以下组件在事件处理中发挥作用。与其他构建块一样，处理组件完全是无服务器的，并且可以很好地向上和向下扩缩。

这些函数可以按原样使用默认设置，也可以重新配置。配置参数通过部署脚本设置，并在相应的 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，以计算资源受限时的表现。）
  • 您为什么对基于事件的模型感兴趣，而不是批量模型？这是为了降低延迟时间（采取行动的时间），还是为了实现松散耦合的集成（敏捷性）？
    • 如果是为了降低延迟时间，请定义“低”。分钟？秒？亚秒级？延迟时间是多少？
  • 您是否已投资于技术堆栈，并让团队掌握了相关技能？如果是，它是什么？它提供哪些集成点？
    • 您的当前系统在处理来自车队的事件时，是否存在无法满足或可能难以满足的要求？

设计原则

始终遵循一些思考过程是有用的。这有助于做出一致的设计决策，尤其是在有多种选择的情况下。

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

流式传输概念

如果您对基于事件或流式传输相对较新，则需要了解一些关键概念，其中一些概念可能与批处理非常不同。

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

这并非完整列表，而只是一个简介。以下是一些强烈推荐的读物，可帮助您进一步加深对每个概念的理解。

贡献者

Google 负责维护本文档。以下贡献者最初编写了本文档。

主要作者：