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

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

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

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

Этот документ актуален для:

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

Обзор эталонного решения для мероприятий флота

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

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

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

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

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

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

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

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

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

Выбор услуги

Когда дело доходит до внедрения эталонного решения для « Решения для парка последней мили» или « Решения для поездок и доставки по требованию» (выйдет в конце третьего квартала 2023 г.), выбор технологий для «Источника» и «Получателя» не вызывает затруднений. стороны, «Обработка» имеет широкий спектр возможностей. Эталонное решение выбрало следующие службы Google.

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

Создание эталонного решения Fleet Events блоки

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

Мы рекомендуем по умолчанию использовать многопроектное развертывание. Это сделано для того, чтобы потребление платформы Google Maps и 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 как хранилище состояния
    • Бессерверное хранилище ключей-значений
  • 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%.
  • Порядок : события не обязательно достигают системы в том порядке, в котором они были созданы. Особенно для случаев использования, связанных с связью через мобильные сети, что приводит к задержке и сложным путям маршрутизации. Вам необходимо знать разницу между «временем события» (когда событие действительно произошло) и «временем процесса» (когда событие достигло системы) и обрабатывать события соответствующим образом. В общем, вы хотите обрабатывать события на основе «времени события».
  • Доставка сообщений — «По крайней мере один раз» или «Точно один раз» . Различные платформы событий имеют разную поддержку. В зависимости от вашего варианта использования вам необходимо рассмотреть стратегии повтора или дедупликации.
  • Полнота : как и при изменении порядка, существует вероятность потери сообщений. Это может быть связано с завершением работы приложения и устройства из-за разрядки аккумулятора устройства, непреднамеренного повреждения телефона, потери соединения в туннеле или сообщения, которое было получено, но только за пределами допустимого окна. Как неполнота повлияет на ваши результаты?

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

Авторы

Google поддерживает этот документ. Первоначально его написали следующие участники.

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