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

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

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

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

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

  • Архитекторы, знакомые с " Mobility services " платформы Google Maps и одним из ее основных компонентов "Fleet Engine". Для тех, кто впервые сталкивается с "Mobility services", мы рекомендуем ознакомиться с Last Mile Fleet Solution и/или On-demand Rides and Deliveries Solution , в зависимости от ваших потребностей.
  • Архитекторы, знакомые с Google Cloud. Для новичков в Google Cloud рекомендуется предварительно прочитать Building streaming data pipelines on Google Cloud .
  • Если вы ориентируетесь на другие среды или программные стеки, сосредоточьтесь на понимании точек интеграции Fleet Engine и ключевых моментов, которые все равно должны быть применимы.
  • Те, кто интересуется изучением того, как можно генерировать и использовать события из флотов.

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

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

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

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

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

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

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

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

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

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

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

Выбор услуг

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

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

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

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

Мы рекомендуем вам по умолчанию использовать развертывание нескольких проектов. Это необходимо для того, чтобы потребление 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, Cloud Pub/Sub является системой доставки сообщений в режиме, близком к реальному времени. Так же, как события из источника были доставлены в Pub/Sub, пользовательские события также публикуются в Pub/Sub для последующего потребления.

Обработка

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

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

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

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

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

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

Модули терраформинга

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

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

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

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

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

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

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

Приложение

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

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

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

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

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

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

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

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

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

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

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

Участники

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

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