События Fleet Engine в реальном времени

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

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

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

Этот документ предназначен для:

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

Обзор справочного решения Fleet Events

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

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

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

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

Логические блоки

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

Обзор Fleet Events и логические блоки

Референтное решение содержит следующие компоненты:

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

Выбор сервиса

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

Диаграмма. На диаграмме ниже показан сервис Google Cloud, который реализует эталонное решение.

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

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

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

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

Last Mile Fleet Solution и On-demand Rides and Deliveries Solution записывают полезную нагрузку запросов и ответов API в Cloud Logging. Cloud Logging доставляет журналы в один или несколько выбранных сервисов. Маршрутизация в Cloud Pub/Sub – идеальный выбор в этом случае. Она позволяет преобразовывать журналы в поток событий без программирования.

Раковина

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

В обработке

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

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

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

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

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

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

Модули Terraform

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

Модули, включенные в эталонное решение:

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

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

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

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

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

Приложение

Сбор требований

Рекомендуем собрать требования на раннем этапе.

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

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

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

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

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

Основные понятия

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

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

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

Авторы

Этот документ поддерживается Google. The following contributors originally wrote it.

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