Генерируйте события практически в реальном времени с помощью Fleet Engine и эталонного решения Fleet Events.

Сигналы, получаемые в режиме, близком к реальному времени от наземного парка, полезны для бизнеса по ряду причин. Например, они могут использоваться для:

  • Контролировать работу своего автопарка и выявлять потенциальные проблемы на ранней стадии
  • Улучшить обслуживание клиентов, предоставляя точные данные о времени прибытия и отслеживании прибытия
  • Сокращение затрат за счет выявления и устранения неэффективности
  • Повышение безопасности за счет мониторинга поведения водителя и выявления потенциальных опасностей
  • Оптимизируйте маршруты и графики движения водителей для повышения эффективности
  • Соблюдайте правила, отслеживая местоположение и часы работы транспортного средства.

В этом документе показано, как разработчики могут преобразовывать сигналы от « мобильных сервисов » платформы Google Карт (« решение для автопарка последней мили» (LMFS) или « решение для поездок и доставки по требованию» (ODRD) в настраиваемые события, которые можно использовать в конкретных действиях. Также рассматриваются основные концепции и проектные решения эталонного решения для автопарка, доступного на GitHub.

Настоящий документ касается:

  • Архитекторы, знакомые с сервисами мобильности платформы Google Карт и одним из её ключевых компонентов — Fleet Engine. Тем, кто только знакомится с сервисами мобильности, мы рекомендуем ознакомиться с решением Last Mile Fleet Solution и/или On-demand Rides and Deliveries Solution , в зависимости от ваших потребностей.
  • Архитекторам, знакомым с Google Cloud. Тем, кто только знакомится с Google Cloud, рекомендуется к прочтению книга «Создание конвейеров потоковых данных в Google Cloud» .
  • Если вы ориентируетесь на другие среды или программные стеки, сосредоточьтесь на понимании точек интеграции Fleet Engine и ключевых моментов, которые все равно должны быть применимы.
  • Тем, кто проявляет общий интерес к изучению того, как можно генерировать и использовать события из флотов.

К концу этого документа у вас должно быть базовое понимание ключевых элементов и особенностей потоковой системы, а также строительных блоков платформы Google Maps и Google Cloud, которые составляют справочное решение Fleet Events .

Обзор эталонного решения для событий автопарка

Эталонное решение Fleet Events — это решение с открытым исходным кодом, которое позволяет клиентам и партнерам Mobility генерировать ключевые события на основе Fleet Engine и компонентов Google Cloud. Сегодня это эталонное решение поддерживает клиентов, использующих Last Mile Fleet Solution, а в будущем — поездки по требованию и доставку.

Решение автоматически генерирует события на основе изменений определенных данных, связанных с задачами или поездками. Вы можете использовать эти события для отправки заинтересованных лиц уведомлений, например, следующих, или для запуска других действий для вашего автопарка.

  • Изменение расчетного времени прибытия задачи
  • Относительное изменение расчетного времени прибытия задачи
  • Оставшееся время до прибытия задачи
  • Расстояние, оставшееся до прибытия задачи
  • Изменение статуса TaskOutcome

Каждый компонент эталонного решения может быть настроен в соответствии с потребностями вашего бизнеса.

Логические строительные блоки

Диаграмма : На следующей диаграмме показаны основные структурные элементы, из которых состоит эталонное решение Fleet Events.

Обзор событий флота и логические структурные элементы

В состав эталонного раствора входят следующие компоненты:

  • Источник событий : источник исходного потока событий. Как « Last Mile Fleet Solution» , так и « On-demand Rides and Deliveries Solution» интегрированы с облачным журналированием, что позволяет преобразовывать журналы RPC-вызовов Fleet Engine в потоки событий, доступные разработчикам. Это основной источник для использования.
  • Обработка : необработанные журналы RPC-вызовов преобразуются в события изменения состояния в этом блоке, который обрабатывает поток событий журнала. Для обнаружения таких изменений этому компоненту требуется хранилище состояний, чтобы можно было сравнивать новые входящие события с предыдущими. События могут не всегда содержать всю необходимую информацию. В таких случаях этот блок может при необходимости выполнять поисковые вызовы к бэкендам.
    • Хранилище состояний : некоторые фреймворки обработки предоставляют промежуточные данные, сохраняемые самостоятельно. Но если нет, то для самостоятельного хранения состояния, поскольку оно должно быть уникальным для транспортного средства и типа события, хорошо подойдёт служба сохранения данных типа KV.
  • Приёмник (пользовательские события) : Обнаруженное изменение состояния должно быть доступно любому приложению или службе, которым оно может быть полезно. Поэтому естественным решением является публикация этого пользовательского события в системе доставки событий для последующего использования.
  • Нижестоящий сервис : код, который использует сгенерированные события и выполняет действия, уникальные для вашего варианта использования.

Выбор услуг

При внедрении эталонного решения для « Last Mile Fleet Solution» или « On-demand Rides and Deliveries Solution» (запланировано на конец третьего квартала 2023 года) выбор технологий для «Source» и «Sink» довольно прост. В то же время, для «Processing» доступен широкий спектр возможностей. В эталонном решении выбраны следующие сервисы Google.

Диаграмма : На следующей диаграмме показана служба Google Cloud для реализации эталонного решения.

Базовые блоки решения Fleet Events

Макет облачного проекта

Мы рекомендуем вам выбрать по умолчанию многопроектное развертывание. Это позволит чётко разделить потребление ресурсов платформы Google Карт и Google Cloud и привязать их к выбранному вами тарифному плану.

Источник события

«Решение для автопарка последней мили» и « Решение для поездок и доставки по требованию» записывают полезные данные запросов и ответов API в Cloud Logging . Cloud Logging доставляет журналы в один или несколько сервисов по вашему выбору. Маршрутизация в Cloud Pub/Sub — идеальный выбор для этого, позволяющий преобразовывать журналы в поток событий без программирования.

Раковина

В Google Cloud Cloud Pub/Sub — это предпочтительная система доставки сообщений в режиме, близком к реальному времени. Подобно тому, как события из источника доставлялись в Pub/Sub, пользовательские события также публикуются в Pub/Sub для последующего использования.

Обработка

Следующие компоненты играют роль в обработке событий. Как и другие компоненты, компоненты обработки полностью бессерверные и хорошо масштабируются как вверх, так и вниз.

  • Облачные функции как вычислительная платформа для первоначального выпуска (*)
    • Бессерверная архитектура, масштабирование вверх и вниз с помощью средств управления масштабированием для управления расходами
    • Java как язык программирования с учетом доступности клиентских библиотек для API, связанных с Fleet Engine, что способствует простоте реализации
  • Cloud Firestore как хранилище состояний
    • Бессерверное хранилище ключей и значений
  • Cloud Pub/Sub как точка интеграции с восходящими и нисходящими компонентами
    • Слабосвязанная интеграция в режиме, близком к реальному времени

Функции можно использовать «как есть» с настройками по умолчанию, но также можно перенастроить. Параметры конфигурации задаются с помощью скриптов развёртывания и подробно описаны в файлах README соответствующих модулей Terraform.

*Примечание: в рамках данного эталонного решения планируется выпуск альтернативных реализаций, которые помогут удовлетворить различные требования.

Развертывание

Чтобы сделать процесс развертывания эталонного решения повторяемым, настраиваемым, контролируемым и безопасным, в качестве инструмента автоматизации был выбран Terraform. Terraform — это широко распространённый инструмент IaC (инфраструктура как код) с расширенной поддержкой Google Cloud.

Модули Терраформа

Вместо создания одного большого монолитного модуля развертывания эталонного решения, многоразовые блоки автоматизации реализованы в виде модулей Terraform, которые можно использовать независимо. Модули предоставляют широкий спектр настраиваемых переменных, большинство из которых имеют значения по умолчанию, что позволяет быстро приступить к работе, но при этом обеспечивает гибкость настройки в соответствии с вашими потребностями и предпочтениями.

Модули, входящие в базовое решение:

  • Конфигурация журналирования Fleet Engine : автоматизируйте настройки, связанные с ведением журналов в облаке, для использования с Fleet Engine. В эталонном решении она используется для направления журналов Fleet Engine в указанную тему Pub/Sub.
  • Развертывание облачной функции Fleet Events : содержит пример развертывания кода функции, а также управляет автоматизацией настроек разрешений, необходимых для безопасной межпроектной интеграции.
  • Развертывание всего эталонного решения : вызывает два предыдущих модуля и охватывает все решение.

Безопасность

IAM используется для применения принципов наименьших привилегий и передовых практик безопасности Google Cloud, таких как имперсонация учётных записей служб. Ознакомьтесь со следующими статьями, чтобы лучше понять, какие возможности Google Cloud предлагает для обеспечения большего контроля безопасности.

Дальнейшие действия

Теперь вы готовы к использованию и дальнейшему изучению справочного решения Fleet Events . Перейдите на GitHub , чтобы начать.

Приложение

Соберите ваши требования

Мы рекомендуем вам собрать все необходимые требования на более раннем этапе процесса.

Сначала подробно объясните, почему вам интересно или необходимо использовать события, близкие к реальному времени. Вот несколько вопросов, которые помогут вам определить ваши потребности.

  • Какая информация необходима, чтобы поток событий был полезным?
    • Можно ли получить результат исключительно на основе данных, собранных или созданных в сервисах Google? Или требуется обогащение данных с помощью интегрированных внешних систем? Если да, то что это за системы и какие интерфейсы интеграции они предлагают?
    • Какие показатели вы хотели бы измерять в своей компании? Как они определяются?
    • Если вам нужно вычислить метрики по событиям, какой тип агрегации для этого потребуется? Попробуйте разбить процесс на логические этапы. (Например, сравните ETA/ATA с SLO для части парка в часы пик, чтобы рассчитать производительность в условиях ограниченных ресурсов.)
  • Почему вас интересует событийная модель, а не пакетная? Это связано с уменьшением задержки (времени до действия) или со слабой интеграцией (гибкостью)?
    • Если нужна низкая задержка, определите «низкую». Минуты? Секунды? Доли секунды? И какая задержка?
  • Вы уже инвестировали в технологический стек и соответствующие навыки всей командой? Если да, то что это такое и какие точки интеграции это даёт?
    • Существуют ли какие-либо требования, которым ваши текущие системы не могут соответствовать или с которыми могут возникнуть трудности при обработке событий, поступающих от вашего парка?

Принципы дизайна

Всегда полезно иметь некий ход мысли, которому можно следовать. Это помогает принимать последовательные решения в дизайне, особенно когда есть выбор из множества вариантов.

  • По умолчанию используются более простые параметры.
  • Ставьте перед собой цель сократить время окупаемости. Меньше кода, меньше времени на обучение.
  • В отношении задержки и производительности стремитесь к достижению заданной вами планки, а не к максимальной оптимизации. Также избегайте чрезмерной оптимизации, поскольку она часто приводит к усложнению кода.
  • То же самое касается и стоимости. Следите за разумными ценами. Возможно, вы ещё не готовы к использованию высококачественных, но относительно более дорогих услуг.
  • На экспериментальном этапе уменьшение масштаба может быть так же важно, как и увеличение. Рассмотрите платформу, которая обеспечивает гибкость как для увеличения масштаба с ограничением, так и для уменьшения (в идеале до нуля), чтобы не тратить деньги, когда вы не используете ресурсы. Высокопроизводительную инфраструктуру с постоянно доступной инфраструктурой можно рассмотреть на более поздних этапах, когда вы будете уверены в её потребностях.
  • Наблюдайте и измеряйте, чтобы позже определить, над чем следует работать дальше.
  • Поддерживайте слабую связанность сервисов. Это облегчит пошаговую замену в будущем.
  • И наконец, безопасность должна быть обеспечена. Поскольку сервис работает в публичной облачной среде, в системе не должно быть незащищённых дверей.

Концепции потоковой передачи

Если вы новичок в области событийной или потоковой обработки, вам стоит знать некоторые ключевые концепции, некоторые из которых могут существенно отличаться от пакетной обработки.

  • Масштаб : В отличие от пакетной обработки, где обычно есть четкое представление об объеме данных, подлежащих обработке, при потоковой передаче это невозможно. Дорожная пробка в городе может внезапно сгенерировать множество событий в определенном районе, и вам все равно нужно уметь их обрабатывать.
  • Окно : вместо того, чтобы обрабатывать события по одному, часто требуется сгруппировать события на временной шкале в более мелкие «окна» для вычисления в качестве единицы. Существуют различные стратегии оконного анализа, такие как «фиксированные окна (например, каждый календарный день)», «скользящие окна (последние 5 минут)», «окна сеанса (во время этой поездки)», из которых вы можете выбрать. Чем длиннее окно, тем больше задержка в получении результатов. Выберите подходящую модель и конфигурацию, соответствующие вашим требованиям.
  • Запуск : бывают случаи, когда у вас нет другого выбора, кроме как использовать относительно более длинные окна. Тем не менее, вы не хотите ждать самого конца окна для создания событий, а вместо этого выдавать промежуточные результаты между ними. Эту концепцию можно реализовать в случаях, когда важно сначала получить быстрые результаты, а затем скорректировать их позже. Представьте себе отправку промежуточных статусов при достижении 25%, 50% или 75% завершения доставки.
  • Порядок : события не обязательно поступают в систему в том порядке, в котором они были созданы. Особенно это касается случаев использования мобильных сетей, где связь приводит к задержке и усложнению маршрутизации. Необходимо понимать разницу между «временем события» (когда событие фактически произошло) и «временем обработки» (когда событие достигло системы) и обрабатывать события соответствующим образом. В общем случае, события следует обрабатывать на основе «времени события».
  • Доставка сообщений — Atleast-once и Exactly-once : разные платформы событий поддерживают разные варианты. В зависимости от вашего варианта использования вам следует рассмотреть стратегии повторных попыток или дедупликации.
  • Полнота : Как и при изменении порядка, существует вероятность потери сообщений. Это может быть связано с отключением приложения или устройства из-за разрядки аккумулятора, непреднамеренным повреждением телефона, потерей связи в туннеле или сообщением, полученным за пределами допустимого интервала. Как неполнота повлияет на ваши результаты?

Это не полный список, а лишь введение. Вот несколько настоятельно рекомендуемых к прочтению книг, которые помогут вам глубже понять каждую из них.

Авторы

Этот документ поддерживается компанией Google. Его авторами являются следующие участники:

Основные авторы: