Очень просто нажать кнопку на мобильном телефоне, и такси будет готово в течение нескольких минут в любое время и в любом месте.
Uber/Ola /Lyft… использовать эти приложения и получить беспроблемную транспортную услугу действительно просто, но так же просто создавать эти гигантские приложения, над которыми сотни инженеров-программистов работают уже десять лет? …? точно нет. Эти системы имеют гораздо более сложную архитектуру, и в них есть множество компонентов, объединенных внутри, чтобы предоставлять услуги верховой езды по всему миру. Давайте обсудим это…

Архитектура системы Uber

Мы все знакомы с услугами Uber. Пользователь может заказать поездку через приложение, и через несколько минут рядом с ним прибудет водитель, чтобы отвезти его к месту назначения. Ранее Uber был построен на модели «монолитной» архитектуры программного обеспечения. У них была внутренняя служба, внешняя служба и единая база данных. Они использовали Python и его фреймворки, а также SQLAlchemy в качестве слоя ORM для базы данных. Эта архитектура подходила для небольшого количества поездок в нескольких городах, но когда сервис начал расширяться в других городах, команда Uber столкнулась с проблемой с приложением. После 2014 года команда Uber решила перейти на «сервисно-ориентированную архитектуру», и теперь Uber также занимается доставкой еды и грузов.

1. Расскажите о проблемах

Одна из основных задач в сервисе Uber — сопоставить водителя с такси, а это значит, что нам нужны два разных сервиса в нашей архитектуре, т.е.

  • Служба снабжения (для такси)
  • Услуга по требованию (для пассажиров)

У Uber есть система диспетчеризации (оптимизация диспетчеризации/DISCO) в своей архитектуре, чтобы обеспечить соответствие предложения спросу. Эта диспетчерская система использует мобильные телефоны и берет на себя ответственность за соответствие водителей пассажирам (предложение спросу).

2. Как работает диспетчерская система?

DISCO должна преследовать эти цели…

  • Сократите лишнее вождение.
  • Минимальное время ожидания
  • Минимальное общее ожидаемое время прибытия

Система диспетчеризации полностью работает с картами и данными о местоположении/GPS, поэтому первое, что важно, — это смоделировать наши карты и данные о местоположении.

  • Земля имеет сферическую форму, поэтому сложно сделать обобщение и приближение, используя широту и долготу. Для решения этой проблемы Uber использует библиотеку Google S2. Эта библиотека делит данные карты на крошечные ячейки (например, 3 км) и присваивает каждой ячейке уникальный идентификатор. Это простой способ распространять данные в распределенной системе и легко их хранить.
  • Библиотека S2 легко обеспечивает охват любой заданной формы. Предположим, вы хотите выяснить все ресурсы, доступные в радиусе 3 км от города. Используя библиотеки S2, вы можете нарисовать круг радиусом 3 км, и он отфильтрует все ячейки с идентификаторами, которые лежат в этом конкретном круге. Таким образом, вы можете легко сопоставить гонщика с водителем и легко узнать количество автомобилей (предложение), доступных в конкретном регионе.

3. Служба снабжения и как она работает?

  • В нашем случае такси — это службы снабжения, и они будут отслеживаться по геолокации (широте и долготе). Все активные кабины продолжают отправлять местоположение на сервер каждые 4 секунды через брандмауэр веб-приложения и балансировщик нагрузки. Точное местоположение GPS отправляется в центр обработки данных через API-интерфейсы Kafka Rest после того, как оно проходит через балансировщик нагрузки. Здесь мы используем Apache Kafka в качестве центра данных.
  • Как только Kafka обновляет последнее местоположение, оно медленно проходит через основную память соответствующих рабочих заметок.
  • Также копия местоположения (конечный автомат/последнее местоположение такси) будет отправлена ​​в базу данных и в оптимизацию отправки, чтобы обновлять последнее местоположение.
  • Нам также нужно отслеживать еще несколько вещей, таких как количество мест, наличие автокресла для детей, тип транспортного средства, подходит ли инвалидное кресло и распределение (например, в такси может быть четыре места, но два из них заняты). .)

4. Спрос на обслуживание и как это работает?

  • Служба Demand получает запрос кабины через веб-сокет и отслеживает местоположение пользователя по GPS. Он также получает различные требования, такие как количество мест, тип автомобиля или пул-кар.
  • Спрос указывает местоположение (идентификатор ячейки) и требования пользователя для предоставления и выполнения запросов на такси.

5. Как диспетчерская система сопоставляет пассажиров с водителями?

  • Мы обсуждали, что DISCO делит карту на крошечные ячейки с уникальным идентификатором. Этот идентификатор используется в качестве ключа сегментирования в DISCO. Когда предложение получает запрос от спроса, местоположение обновляется с использованием идентификатора ячейки в качестве ключа сегмента. Обязанности этих крошечных ячеек будут разделены на разные серверы, расположенные в нескольких регионах (согласованное хеширование). Например, мы можем распределить ответственность за 12 крошечных ячеек на 6 разных серверов (по 2 ячейки на каждый сервер) в 6 разных регионах.

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

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

6. Как масштабировать диспетчерскую систему?

  • Система диспетчеризации (включая предложение, спрос и веб-сокеты) построена на NodeJS. NodeJS — это асинхронная платформа, основанная на событиях, которая позволяет отправлять и получать сообщения через веб-сокеты в любое время.
  • Uber использует RingPop с открытым исходным кодом, чтобы сделать приложение совместимым и масштабируемым для интенсивного трафика. Ring pop состоит в основном из трех частей и выполняет описанную ниже операцию для масштабирования системы диспетчеризации.
  1. Он поддерживает непротиворечивое хэширование для распределения работы между рабочими процессами. Это помогает сегментировать приложение таким образом, чтобы оно было масштабируемым и отказоустойчивым.
  2. Ringpop использует протокол RPC (удаленный вызов процедур) для совершения вызовов с одного сервера на другой.
  3. Ringpop также использует протокол членства SWIM/протокол сплетен, который позволяет независимым работникам узнавать об обязанностях друг друга. Таким образом, каждый сервер/узел знает ответственность и работу других узлов.
  4. Ringpop обнаруживает новые узлы, добавленные в кластер, и узел, удаленный из кластера. Он равномерно распределяет нагрузки при добавлении или удалении узла.

7. Как Uber определяет регион карты?

Перед запуском новой операции в новой области Uber добавляет новый регион в стек картографических технологий. В этой области карты мы определяем различные субрегионы, помеченные оценками A, B, AB и C.

Уровень A: этот субрегион отвечает за покрытие городских центров и пригородных районов. Около 90% трафика Uber приходится на этот субрегион, поэтому важно построить карту самого высокого качества для субрегиона А.

Уровень B. Этот субрегион охватывает сельские и пригородные районы, менее населенные и менее посещаемые клиентами Uber.

Уровень AB: объединение субрегионов уровня A и B.

Уровень C: охватывает набор коридоров шоссе, соединяющих различные территории Uber.

8. Как Uber строит карту?

Uber использует стороннего поставщика картографических услуг для создания карты в своем приложении. Ранее Uber использовал сервисы Mapbox, но позже Uber перешел на API Google Maps для отслеживания местоположения и расчета ETA.

1. Покрытие трассировки: покрытие трассировки определяет отсутствующие сегменты дороги или неправильную геометрию дороги. Расчет охвата отслеживания основан на двух входных данных: тестируемых картографических данных и исторических GPS-треках всех поездок Uber, совершенных за определенный период времени. Он наносит эти следы GPS на карту, сравнивая и сопоставляя их с сегментами дороги. Если мы находим отсутствующие сегменты дороги (дорога не отображается) на трассах GPS, мы предпринимаем некоторые шаги для устранения недостатка.

2. Предпочтительная точность точки доступа (посадки): мы получаем точку посадки в нашем приложении, когда заказываем такси в Uber. Пункты выдачи — очень важная метрика в Uber, особенно для крупных объектов, таких как аэропорты, университетские городки, стадионы, фабрики или компании. Мы рассчитываем расстояние между фактическим местоположением и всеми точками посадки и высадки, используемыми водителями.

Затем вычисляется кратчайшее расстояние (ближайшая точка посадки), и мы устанавливаем булавку на это место в качестве предпочтительной точки доступа на карте. Когда водитель запрашивает место, указанное булавкой на карте, карта направляет водителя к предпочтительной точке доступа. Расчет продолжается с последними фактическими местами посадки и высадки, чтобы обеспечить актуальность и точность предлагаемых предпочтительных точек доступа. Uber использует машинное обучение и различные алгоритмы, чтобы определить предпочтительную точку доступа.

9. Как рассчитывается ожидаемое время прибытия?

Расчетное время прибытия — чрезвычайно важная метрика в Uber, поскольку она напрямую влияет на количество поездок и прибыль. ETA рассчитывается на основе дорожной системы (а не географической), и при расчете ETA учитывается множество факторов (например, интенсивное движение или строительство дорог). Когда водитель запрашивает такси из места, приложение не только идентифицирует свободные / незанятые такси, но также включает такси, которые вот-вот закончат поездку. Возможно, что одна из кабин, которые вот-вот закончат поездку, более близка к спросу, чем кабина, которая находится далеко от пользователя. Так много автомобилей Uber на дороге отправляют данные GPS о местоположении каждые 4 секунды, поэтому для прогнозирования трафика мы можем использовать данные GPS о местоположении приложения водителя.

Мы можем представить всю дорожную сеть на графике для расчета ETA. Мы можем использовать смоделированные алгоритмы ИИ или простой алгоритм Дейкстры, чтобы найти лучший маршрут на этом графике. На этом графике узлы представляют перекрестки (доступные такси), а ребра — сегменты дороги. Мы представляем расстояние сегмента дороги или время в пути через вес края. Мы также представляем и моделируем некоторые дополнительные факторы на нашем графике, такие как улицы с односторонним движением, стоимость поворотов, ограничения поворотов и ограничения скорости.

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

10. Базы данных

Uber пришлось учитывать некоторые требования к базе данных для лучшего обслуживания клиентов. Эти требования…

  • База данных должна быть горизонтально масштабируемой. Вы можете линейно увеличивать емкость, добавляя больше серверов.
  • Он должен иметь возможность обрабатывать большое количество операций чтения и записи, потому что каждые 4 секунды такси будут отправлять местоположение GPS, и это местоположение будет обновляться в базе данных.
  • Система никогда не должна давать простоя для какой-либо операции. Он должен быть высокодоступным независимо от того, какую операцию вы выполняете (расширение хранилища, резервное копирование, добавление новых узлов и т. д.).

Ранее Uber использовал базу данных RDBMS PostgreSQL, но из-за проблем с масштабируемостью Uber переключился на другие базы данных. Uber использует базу данных NoSQL (без схемы), созданную поверх базы данных MySQL.

  • Redis для кэширования и организации очередей. Некоторые стоят за Twemproxy (который обеспечивает масштабируемость слоя кэширования). Некоторые из них находятся за пользовательской системой кластеризации.
  • Uber использует schemaless (собственно встроенный поверх MySQL), Riak и Cassandra. Schemaless предназначен для долгосрочного хранения данных. Riak и Cassandra отвечают требованиям высокой доступности и малой задержки.
  • База данных MySQL.
  • Uber создает собственное распределенное хранилище колонок, которое управляет набором экземпляров MySQL.

11. Аналитика

Чтобы оптимизировать систему, минимизировать эксплуатационные расходы и повысить качество обслуживания клиентов, Uber собирает и анализирует журналы. Uber использует разные инструменты и фреймворки для аналитики. Для анализа журналов Uber использует несколько кластеров Kafka. Kafka использует исторические данные вместе с данными в реальном времени. Данные архивируются в Hadoop до истечения срока их действия в Kafka. Данные также индексируются в стек эластичного поиска для поиска и визуализации. Elastic search выполняет некоторый анализ журналов с использованием Kibana/Graphana. Некоторые из анализов, выполненных Uber с использованием различных инструментов и платформ,…

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

12. Как справиться с отказом центра обработки данных?

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

Тогда как Uber справится со сбоем в центре обработки данных?

Он фактически использует телефоны водителей в качестве источника данных о поездках, чтобы решить проблему отказа центра обработки данных.
Когда приложение телефона водителя связывается с системой диспетчеризации или между ними происходит вызов API, система диспетчеризации отправляет зашифрованный дайджест состояния (для отслеживания последней информации/данных) в приложение телефона водителя. Каждый раз этот дайджест состояния будет приниматься телефонным приложением водителя. В случае сбоя центра обработки данных резервный центр обработки данных (резервный DISCO) ничего не знает о поездке, поэтому он запросит дайджест состояния из приложения телефона водителя и обновит себя с помощью дайджеста состояния, полученного водителем. приложение для телефона.