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

来自地面运营的舰队的近乎实时信号有助于 以多种方式发展业务。例如，商家可以使用这些信息来：

  • 监控设备群的性能并及早发现潜在问题 已开启
  • 提供准确的预计到达时间和跟踪信息，改善客户服务
  • 通过发现并解决效率低下问题来降低成本
  • 监控驾驶员的行为并发现潜在作用，提高安全性 危险
  • 优化司机路线和时刻表，提高效率
  • 跟踪车辆位置和服务时间，以遵守相关法规

本文档说明了开发者如何才能从 Google 地图中转变信号 平台的“移动性 服务” （“最后一英里舰队） 解决方案” (LMFS) 或“按需乘车和送货 解决方案” 转换为可操作的自定义事件。主要概念和设计决策 舰队事件参考 解决方案 GitHub 上提供的其他示例。

本文档与以下内容相关：

学完本文档后，您应该对 关键元素和注意事项，以及如何构建 构成舰队事件的 Google Maps Platform 和 Google Cloud 的屏蔽对象 参考信息 解决方案。

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

舰队事件参考解决方案是一种开源解决方案， 助力移动客户和合作伙伴在 Fleet Engine 上生成关键事件 和 Google Cloud 组件。如今，参考解决方案 使用支持按需叫车和配送的最后一公里舰队解决方案 。

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

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

参考解决方案的每个组件均可定制，以适应您的业务 需求。

逻辑组成要素

示意图：下图显示了 设置舰队事件参考解决方案

舰队事件概览和逻辑构建 方块

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

  • 事件来源：原始事件流的来源。“Last 里程车队 解决方案” 或“按需乘车和送货 解决方案” 与 Cloud Logging 集成，有助于转变 Fleet Engine RPC 调用 事件流这是 。
  • 处理：原始 RPC 通话记录会被转换为状态变化事件 用于对日志事件流进行计算。要检测此类 但该组件需要状态存储 可以与之前的应用进行比较，以检测变化。事件有时未必如此 包含所有感兴趣的信息。在这种情况下，此屏蔽设置可能会 可以根据需要查找对后端的调用。
    • 状态存储空间：一些处理框架提供中间数据 自身的持久性但如果不是，为了自行存储状态， 因为这些属性对于车辆和事件类型是唯一的，因此 K-V 类型 数据持久性服务是不错的选择
  • 接收器（自定义事件）：检测到的状态更改应可供以下对象使用 任何可从中受益的应用或服务因此， 将此自定义事件发布到事件传递系统的自然选择， 下游用量。
  • 下游服务：使用生成的事件并接收 应用场景特有的操作

服务选择

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

示意图：下图显示了用于实现 参考解决方案

舰队事件参考解决方案构建 方块

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：作为计算资源 初始版本的平台 (*) <ph type="x-smartling-placeholder">
      </ph>
    • 无服务器，可利用扩缩控制机制进行扩缩，从而管理费用
    • 考虑到有客户端可用，将 Java 作为编程语言 Fleet Engine 相关 API 的库，这有助于简化 实现
  • Cloud Firestore 作为状态存储区 <ph type="x-smartling-placeholder">
      </ph>
    • 无服务器键值对存储区
  • 使用 Cloud Pub/Sub 作为集成点 包括上游和下游组件 <ph type="x-smartling-placeholder">
      </ph>
    • 近乎实时的松散耦合式集成

这些函数可按默认设置原样使用，但也可以 重新配置。通过部署脚本和 相应的 Terraform 模块自述文件中对此进行了详细介绍。

*注意：本参考解决方案计划发布 可帮助满足不同的要求

部署

为了使参考解决方案部署过程可重复、可自定义、 由于源代码可控制且安全，因此选择 Terraform 作为 工具。Terraform 是一种被广泛采用的 IaC（基础设施即代码）工具，具有丰富的 。

Terraform 模块

您不必构建大型单体式参考解决方案部署模块， 可重复使用的自动化块以 Terraform 模块的形式实现， 独立使用。模块提供了各种各样的可配置变量，大多数 其中每个都有默认值，方便您快速上手 灵活地根据您的需求和偏好进行自定义。

参考解决方案中包含的模块：

  • Fleet Engine 日志记录配置：自动执行 Cloud Logging 相关操作 以便与 Fleet Engine 搭配使用。在参考解决方案中， 用于将 Fleet Engine 相关日志路由到指定的 Pub/Sub 主题。
  • 舰队事件 Cloud Functions 函数部署：包含示例函数 代码部署，并处理权限设置的自动化 是安全的跨项目集成所必需的。
  • 完整参考解决方案部署：调用前面的两个模块并 包含整个解决方案。

安全

采用 IAM 来应用最小权限原则以及 Google Cloud 的 安全最佳实践（例如服务账号模拟）。请参考 阅读以下文章，更好地了解 Google Cloud 可为您提供哪些功能 加强对安全性的控制

后续操作

现在，您可以访问并进一步探索舰队事件参考。 解决方案。 前往 GitHub 。

附录

收集您的要求

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

首先，详细说明您感兴趣或需要使用 近乎实时的事件。下面这些问题可帮助您明确自己的需求。

  • 事件流需要哪些信息才有用？
    • 结果能否完全根据 Google 服务？还是通过集成的外部系统丰富数据 吗？如果是，这些系统是什么，有哪些集成接口 提供哪些服务？
    • 作为一家企业，您希望衡量哪些指标？怎么样 ？
    • 如果您需要跨事件计算指标， 需要吗？尝试安排逻辑步骤。（例如比较 在高峰时段根据 SLO 的预计到达时间/ATA 计算性能）
  • 为什么您对基于事件的模型感兴趣，而不是对批量模型感兴趣？这是 缩短延迟时间（操作时间）或松散耦合的集成 （敏捷性）？
    • 如果要实现低延迟，请定义“低”。分钟？秒？亚秒？以及 延迟时间？
  • 作为一名技术人才，您是否在技术栈和相关技能方面进行了投资 团队？如果是，它是什么？它提供了哪些集成点？
    • 是否有任何要求是您当前的系统无法满足或可能满足的要求 为处理来自舰队的事件而苦恼？

设计原则

遵循一些思维流程是非常有用的。这有助于 做出一致的设计决策，尤其是当您 。

  • 默认为更简单的选项。
  • 默认为较短的价值实现时间。代码更少，学习曲线更短。
  • 在延迟时间和性能方面，尽量达到您设置的标准，而不是上限 优化。还要避免过度优化，因为这通常会导致 复杂性。
  • 费用也是如此。确保费用合理。您可能还没有到达 表明您可以承诺使用高价值但相对更高的 服务。
  • 在实验阶段，纵向缩容和纵向扩容可能同样重要。 考虑采用一个能够灵活扩容的平台，既能灵活控制上限，又能 缩小（最好为零），这样您就不会在无事可做的情况下花钱。 我们日后可以考虑 对它的需求更有信心时
  • 观察并衡量，以便日后确定需要进一步改进的地方。
  • 保持服务的松散耦合。这样就能更轻松地切换各个部分 。
  • 最后但同样重要的一点是，安全性不能松散。作为在 因此，系统不应存在任何不安全的门。

流式传输概念

如果您比较不熟悉基于事件或流式传输，不妨先了解一些重要概念， 其中一些方法与批处理有很大不同。

  • 扩展：与批处理相反，批量处理通常具有良好的 了解要处理的数据量，在流式传输中是不可能的。A 路 城市里的拥堵就可能突然之间 产生很多事件 而且你仍然需要能够进行处理
  • 数据选取：通常不是逐个处理事件，而是 您希望将时间轴上的事件分组到较小的“窗口”中为 一种计算单位。数据选取策略有很多种，例如 “固定窗口（例如每日历日）”、“滑动窗口（过去 5 天） 分钟）、“会话窗口（本次行程期间）”等，您应选择 。窗口越长，生成结果的延迟越长。 选择合适的模型和配置，以满足您的需求。
  • 触发：在某些情况下，您只能采取 相对较长的时间窗口尽管如此，您还是不想等到最后 窗口来生成事件，而是发出中间结果 中间。此概念可以用于 先返回快速结果，稍后再进行更正。 想象一下，当某个订单的完成度达到 25%、50%、75% 时， 。
  • 排序：事件不一定按事件先后顺序到达系统 。尤其是对于需要通过网络进行通信的用例， 增加延迟和复杂的路由路径。您需要 了解“事件时间”和（当该事件实际上 和“处理时间”（当事件到达系统时）并处理 事件。一般来说，您需要根据“事件” 。
  • 消息传送 - 至少一次与正好一次：事件不同 平台有不同的支持。根据您的使用场景 则需要考虑重试或重复信息删除策略。
  • 完整性：就像顺序更改一样，可能 消息会丢失。这可能是因为应用和设备关机，原因如下： 设备的电池续航时间, 手机意外损坏, 丢失 连接性的消息，或仅收到消息，但 排除在可接受的范围内信息不完整会如何影响您的结果？

此处并未列出所有情况，仅提供简介。以下是一些 这些推荐阅读内容有助于您进一步加深对每项内容的理解。

贡献者

本文档由 Google 维护。它最初是由以下贡献者编写的。

主要作者：