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

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

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

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

Данный документ относится к следующим категориям лиц:

  • Архитекторы знакомы с « мобильными сервисами » платформы Google Maps и одним из ее основных компонентов — «движком автопарка». Тем, кто только начинает знакомиться с «мобильными сервисами», мы рекомендуем ознакомиться с решением «Автопарк последней мили» и/или решением «Поездки и доставка по запросу» , в зависимости от ваших потребностей.
  • Архитекторам, знакомым с Google Cloud. Тем, кто только начинает работать с Google Cloud, рекомендуется предварительно ознакомиться с книгой «Создание конвейеров потоковой обработки данных в Google Cloud» .
  • Если вы ориентируетесь на другие среды или программные стеки, сосредоточьтесь на понимании точек интеграции Fleet Engine и ключевых моментов, которые, по всей видимости, также будут актуальны.
  • Тем, кто в целом интересуется изучением способов генерации и использования событий, происходящих во флоте.

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

Обзор решения для организации мероприятий на автопарке

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

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

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

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

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

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

Обзор мероприятий флота и их логическая структура блоки

Эталонное решение включает следующие компоненты:

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

Выбор услуги

Что касается внедрения эталонного решения для " Решения по организации "последней мили"" или " Решения для заказа поездок и доставки по требованию" (появление в конце 3 квартала 2023 года), выбор технологий для "Источника" и "Приемника" довольно прост. С другой стороны, для "Обработки" существует широкий спектр вариантов. В эталонном решении были выбраны следующие сервисы Google.

Диаграмма : На следующей диаграмме показан сервис 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 как вычислительная платформа для первоначального выпуска (*)
    • Бессерверная архитектура, масштабируемость вверх и вниз с помощью средств управления масштабированием для контроля затрат.
    • В качестве языка программирования выбран Java, учитывая наличие клиентских библиотек для API, связанных с Fleet Engine, что упрощает реализацию.
  • Cloud Firestore как хранилище состояний
    • Бессерверное хранилище ключ-значение
  • Облачная система публикации/подписки как точка интеграции с компонентами, работающими с исходящим и нисходящим потоками данных.
    • Слабосвязанная интеграция в режиме, близком к реальному времени

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

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

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

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

Модули Terraform

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

Модули, входящие в состав эталонного решения:

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

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

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

Следующие действия

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

Приложение

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

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

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

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

Принципы проектирования

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

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

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

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

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

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

Авторы

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

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