Яндекс Маршрутизация в общем виде отвечает на один вопрос: в каком порядке посетить точки и сколько времени займёт путь. Под этим названием встречаются сервисы Яндекса для планирования маршрутов, которые применяют в картографии, логистике и при распределении запросов между сервисами.
Архитектура таких систем строится по одной схеме: клиент обращается к API, API передаёт задачу ядру, ядро (маршрутизатор) запрашивает картографию, данные о трафике и справочники, после чего возвращает путь, время и расстояние. Различаются детали: набор методов, лимиты, форматы полей и источники данных.
Ниже разобраны компоненты, поток запроса, контексты термина «маршрутизация» и типовой сценарий для DevOps-инженеров, которым нужно понять место сервиса в инфраструктуре.
Границы материала: в подготовленных источниках нет описания API, тарифов и внутреннего устройства продуктов Яндекса. Имена эндпоинтов, квоты и форматы ответов сверяйте с официальной документацией того продукта, который подключаете.
Что такое Яндекс Маршрутизация и какие задачи она решает
Маршрутизация в контексте сервисов Яндекса означает расчёт пути между точками и распределение задач по исполнителям. Первый вариант ближе к картам и логистике, второй к инфраструктуре приложений. Общее у них одно: есть набор объектов и правила, по которым система выбирает порядок и способ их обработки.
Дальше речь идёт об архитектуре и принципах работы: какие слои входят в систему, как они обмениваются данными и что происходит с запросом от отправки до ответа.
Ключевые задачи сервиса
- Построение маршрутов по списку точек. Система принимает адреса или координаты и возвращает порядок объезда. Пример: курьеру нужно развезти 20 заказов, и сервис предлагает последовательность визитов, при которой пробег короче, чем при объезде в порядке поступления заявок.
- Распределение нагрузки между узлами. Слой маршрутизации решает, на какой экземпляр приложения или в какой регион отправить запрос. Пример: API-шлюз направляет операцию записи в ближайший к пользователю дата-центр.
- Связка с картографическими данными. Геометрия дорог, запреты поворотов, платные участки и перекрытия берутся из карт. Пример: маршрут грузовика строится с учётом габаритов и запрета проезда по центру города.
- Управление потоками заказов. Заявки распределяются по исполнителям с учётом зон, смен и приоритетов. Пример: заказ из зоны без свободных курьеров уходит в соседнюю зону по правилу перелива.
Место сервиса в инфраструктуре
Такой сервис работает либо как внешнее облако, либо как локальный кластер. В облаке вычислительные, дисковые и сетевые ресурсы распределены по нескольким физическим машинам и дата-центрам, а оплата привязана к фактическому потреблению, а не к фиксированной сумме за месяц (What is Cloud Hosting, Hostwinds). Для маршрутизации это значит, что при росте числа запросов вы платите за обработку и трафик, а не за простаивающий резерв.
Схема взаимодействия: клиент → API → маршрутизатор → источники данных → ответ. Между слоями ставят API-шлюз, балансировщик и кэш. Базы данных хранят заказы, справочники адресов и историю запросов, а очередь сглаживает пики нагрузки.
Архитектура Яндекс Маршрутизации: основные компоненты
Ядро системы маршрутизации собирается из трёх частей: интерфейса (API), ядра принятия решений (маршрутизатора) и поставщиков информации (источников данных). Они связаны конвейером: запрос проходит слои по очереди, и каждый слой масштабируется отдельно.
API: точка входа и интерфейс взаимодействия
Входная точка для интеграций - HTTP API. Запросы и ответы передаются в JSON. Аутентификация опирается на API-ключи, для пользовательских сценариев добавляют OAuth. Ключ передают в заголовке, реже в параметре строки запроса.
Запрос на построение маршрута содержит режим передвижения, точки вида «широта, долгота» и опции: учёт пробок, число альтернативных вариантов, тип транспортного средства. Ответ возвращает массив сегментов с длиной и временем, общую продолжительность и геометрию в виде набора координат. Имена полей отличаются между продуктами и версиями, поэтому фиксируйте их по документации конкретного API.
Поддерживаются синхронные и асинхронные вызовы. Синхронный режим подходит для маршрута из нескольких точек, асинхронный для пакетных задач на сотни адресов, когда результат забирают по идентификатору задачи. Чем REST отличается от gRPC и GraphQL по производительности и сложности поддержки, разобрано в статье про стратегии выбора API для масштабирования.
Маршрутизатор: ядро обработки запросов
Маршрутизатор получает нормализованный запрос и ищет путь по графу дорог. В основе лежат алгоритмы поиска кратчайшего пути: обход в ширину для простых случаев, алгоритм Дейкстры для графа с весами, A* с эвристикой для больших карт. Вес ребра складывается из длины, разрешённой скорости, истории трафика и текущих заторов.
Ядро удобно держать отдельным микросервисом: у него своя нагрузка, свои кэши и свой цикл релизов. При запросе маршрута оно обращается к источникам данных за актуальной информацией и кладёт результат в кэш по ключу из набора точек и параметров.
Источники данных: карты, трафик, заказы
Источники делятся на четыре группы:
- картография: дорожный граф, адреса, дома, запреты. Основа для построения пути;
- динамика: пробки, перекрытия, погода, данные о ДТП. Меняются каждую минуту, поэтому идут отдельным потоком обновлений;
- внутренние системы: базы заказов, справочники исполнителей, тарифные зоны, склады;
- внешние API: геокодеры, сервисы матриц расстояний, системы партнёров.
Карты Яндекса связаны с маршрутами напрямую: в рекламных инструментах есть продвижение маршрутов, звонков и переходов на сайт, а карточка организации влияет на то, увидят ли её пользователи в поиске по карте (Настройка рекламы на картах Яндекс и Google). Для логистики это означает, что данные точки и её видимость на карте определяют, к какому адресу построят маршрут.
Данные кэшируют на нескольких уровнях: горячий кэш в памяти маршрутизатора на секунды и минуты, тёплый кэш в Redis на часы, холодное хранилище для истории. Ключ вида «набор точек плюс параметры» снимает нагрузку при повторных запросах одинаковых пар адресов.
Принципы работы: как проходит запрос через систему
Обработка запроса: от API до ответа
- Клиент отправляет HTTP-запрос с ключом и телом задачи.
- API проверяет ключ, права и квоты, приводит координаты к единому формату, отбрасывает некорректные точки.
- Задача уходит в очередь при высокой нагрузке или сразу в маршрутизатор.
- Маршрутизатор берёт из кэша или источников актуальный трафик и граф дорог.
- Алгоритм строит путь, проверяет ограничения (габариты, временные окна, запреты), считает время и расстояние.
- API собирает ответ, записывает метрики и отдаёт JSON клиенту.
На каждом шаге нужны таймауты и повторные попытки. Таймаут на вызов источника держат меньше общего бюджета запроса, чтобы остался запас на повтор и возврат ответа. Повторы безопасны только для идемпотентных операций: чтение маршрута повторяют свободно, а создание заказа защищают ключом идемпотентности.
Масштабирование и отказоустойчивость
Слои растут по-разному. API и маршрутизатор масштабируются горизонтально: новые экземпляры встают за балансировщик, состояние держится в кэше и внешнем хранилище. Источники данных масштабируют репликацией: чтение уходит на реплики, запись остаётся на мастере. Кластер маршрутизатора делит граф дорог по регионам, и каждый узел работает со своим фрагментом.
Отказоустойчивость строится на избыточности: два и более экземпляра каждого слоя, health-check, автоматический вывод узла из балансировки, повтор запроса на соседний узел. Типовые ошибки при проектировании потоков, включая взаимные блокировки, потерю данных и неэффективные цепочки обработки, разобраны в материале про типичные ошибки маршрутизации процессов.
Ориентиры для SLO задавайте по замеру. Стартовая рамка для синхронного запроса из двух точек: 95-й процентиль в диапазоне 100-300 мс по внутреннему API и до 1 секунды по внешнему. Это проектные ориентиры, а не гарантированные показатели сервисов Яндекса. Как строить метрики, алерты и находить узкие места, описано в руководстве по архитектуре высоконагруженных систем.
Разграничение терминов: маршрутизация трафика, заказов и другие значения
Слово «маршрутизация» в IT означает минимум четыре разные вещи. Путаница начинается, когда один специалист говорит о пакетах, другой о курьерах, третий о запросах к микросервисам.
| Контекст | Что маршрутизируется | Кто принимает решение | Типовые инструменты |
|---|---|---|---|
| Сеть | IP-пакеты | Маршрутизатор и таблица маршрутов | BGP, OSPF, iproute2 |
| Логистика | Заказы и курьеры | Планировщик маршрутов | Сервис построения маршрутов, TMS |
| Микросервисы | HTTP-запросы | API-шлюз, service mesh | Nginx, Envoy, Istio |
| Очереди | Сообщения и задачи | Брокер и потребители | Kafka, RabbitMQ |
Маршрутизация трафика
Сетевая маршрутизация решает, через какой интерфейс отправить пакет. Решение принимает таблица маршрутов: статические записи задаёт администратор, динамические приходят по протоколам BGP или OSPF. В Linux маршрут по умолчанию добавляют командой ip route add default via 192.168.1.1, а отдельную подсеть направляют через свой шлюз. Ошибка в такой записи роняет связность сегмента, поэтому изменения проверяют на стенде.
Маршрутизация заказов
Логистическая маршрутизация строит порядок объезда точек с учётом времени доставки, окон, веса груза и режима работы склада. Сервис доставки отдаёт список адресов и получает последовательность визитов, время прибытия и суммарный пробег. Точность зависит от качества карт и свежести данных о трафике.
Маршрутизация запросов в микросервисах
Здесь маршрутизация означает выбор экземпляра сервиса для конкретного запроса: по пути, заголовку, версии или весу. Решение принимает шлюз или service mesh. Зависимости сервисов при этом держат явными: скрытые обращения к общему реестру усложняют отладку, и это одна из причин, по которой сервис-локатор в PHP относят к антипаттернам (Сервис-локатор в PHP).
Какой контекст у Яндекс Маршрутизации
Название встречается в нескольких продуктах Яндекса, и контекст задаёт продукт. В картографических сценариях речь идёт о построении маршрутов для поездок и доставки, в инфраструктурных о маршрутизации запросов между сервисами. Перед чтением документации определите, какой продукт вы подключаете: от этого зависят эндпоинты, квоты и модель оплаты.
Типовой сценарий использования с пошаговым пояснением
Сценарий: DevOps-инженеру нужно распределять запросы между двумя версиями сервиса и строить маршруты доставки для внутреннего приложения. Шаги идут в том порядке, в котором их обычно проходят. Имена команд и полей сверяйте с документацией своего продукта.
Подготовка и настройка
- Заведите аккаунт и получите ключ API. Храните ключ в секрет-хранилище (Vault, Kubernetes Secret), а не в репозитории.
- Проверьте требования окружения: версия рантайма, доступ по HTTPS, разрешённые исходящие адреса, лимит на размер тела запроса.
- Опишите конфигурацию маршрутов: список upstream-сервисов, веса, health-check, таймауты. Для Nginx это блок upstream и location, для Kubernetes - Ingress и Service.
- Подключите источники данных: картографию, справочник адресов, базу заказов. Убедитесь, что у сервиса есть права на чтение этих таблиц.
- Настройте кэш и лимиты: TTL для карт, отдельный TTL для трафика, ограничение числа запросов на ключ.
Запуск и проверка
- Отправьте тестовый запрос на построение маршрута из двух точек с заранее известным ответом.
- Сверьте результат: порядок точек, время, расстояние, геометрию. Расхождение с ручной проверкой укажет на неверные координаты или устаревший кэш.
- Проверьте распределение запросов: два экземпляра сервиса должны получать трафик по заданным весам.
- Включите логирование и метрики: код ответа, задержка по слоям, доля ошибок, попадания в кэш.
- Соберите дашборд и алерт на рост доли 5xx и на превышение задержки выше согласованного SLO.
Типовые сбои на старте: 401 из-за ключа в неверном заголовке, 429 при превышении квоты, 400 при координатах не в том порядке, пустой ответ при устаревшем кэше. Лечится проверкой заголовков, сбросом кэша и сверкой формата точек с документацией. Приёмы отладки таких ошибок в веб-приложениях и микросервисах, включая curl -v, логи Nginx и трассировку в Jaeger, собраны в статье про диагностику проблем маршрутизации.
Документация и ресурсы для дальнейшего изучения
Официальная документация продукта остаётся первым источником. Ищите раздел с описанием API, лимитами и примерами запросов; у сервисов Яндекса документация выходит на русском языке и частично на английском. Порядок изучения: аутентификация и один простой запрос, затем пакетные режимы, затем ограничения и тарифы.
Дополнительно смотрите публичные репозитории с примерами интеграций, форумы разработчиков и журнал изменений (changelog). Changelog показывает, какие поля и методы уже устарели, и снимает сомнение в актуальности инструкции.
Чеклист перед выводом в прод: ключ лежит в секрет-хранилище, лимиты и таймауты заданы, кэш настроен, метрики и алерты включены, тестовый стенд повторяет продовую конфигурацию. С этими пунктами сервис выходит в эксплуатацию предсказуемо, а разбор инцидентов занимает минуты, а не часы.