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

来自在地面运营的舰队的近乎实时信号对企业来说有很多帮助。例如，商家可以使用这些信息来：

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

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

本文档与以下内容相关：

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

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

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

舰队事件参考解决方案是一个开源解决方案，使移动客户和合作伙伴能够在 Fleet Engine 和 Google Cloud 组件之上生成关键事件。如今，参考解决方案为使用“Last Mile Fleet Solution”的客户提供支持，并支持随后的叫车和送货服务。

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

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

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

逻辑构建块

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

舰队事件概览和逻辑基础组件

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

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

服务选择

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

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

Fleet Events 参考解决方案构建块

Cloud 项目布局

我们建议您默认采用多项目部署。这样，Google Maps Platform 和 Google Cloud 的使用情况便可清晰地分开，并与您选择的结算方式相关联。

事件来源

“Last Mile Fleet Solution”和“On-demand Rides and Deliveries Solution”将 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 主题。
  • 车队事件 Cloud Functions 函数部署：包含示例函数代码部署，还会处理安全跨项目集成所需的自动化权限设置。
  • 整个参考解决方案部署：调用前两个模块并封装整个解决方案。

安全

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

后续操作

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

附录

收集您的要求

我们建议您在流程的早期收集要求。

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

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

设计原则

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

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

流式传输概念

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

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

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

贡献者

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

主要作者：