ГлавнаяБлогМасштабируемость Tracking API: как обрабатывать объемы в пиковый сезон, ограничения частоты запросов и массовую регистрацию

Масштабируемость Tracking API: как обрабатывать объемы в пиковый сезон, ограничения частоты запросов и массовую регистрацию

17TRACK

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

Масштабируемость Tracking API: как обрабатывать объем в пик сезона

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

Оценивайте нагрузку по отправлениям, запросам и обновлениям

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

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

Установите внутреннюю цель регистрации, например максимально допустимое время между получением трекинг-номера и подтверждением его регистрации. Отделяйте ее от актуальности отслеживания: успешная регистрация не означает, что сканирование перевозчиком уже доступно.

Рассчитайте эффективную пропускную способность регистрации

Для конечной точки регистрации с ограничением по запросам полезно использовать следующую расчетную зависимость:

Пропускная способность регистрации = разрешенное количество запросов в секунду × среднее количество записей в запросе × доля успешно обработанных записей

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

Только для иллюстрации предположим, что интеграции разрешено выполнять два запроса регистрации в секунду и в среднем отправлять по 30 записей в каждом запросе. Ее номинальная пропускная способность составляет 60 записей в секунду до учета сбоев и других ограничений. Если во время продолжительного всплеска входящие регистрации поступают со средней скоростью 80 записей в секунду, очередь увеличивается примерно на 20 записей в секунду. Эти цифры являются гипотетическими и не отражают ограничения 17TRACK.

Также рассчитайте пропускную способность восстановления. Если новые записи продолжают поступать со скоростью λ, а эффективная производительность обработки составляет μ, существующая очередь из B записей будет обрабатываться примерно B / (μ − λ) секунд при условии μ > λ. Если производительность обработки не превышает скорость поступления, очередь не будет устранена в этих условиях.

Уточните, что именно ограничивает провайдер

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

Прежде чем устанавливать количество рабочих процессов, проверьте по документации провайдера и условиям вашей учетной записи следующее:

  • Применяются ли ограничения к учетной записи, API-ключу, конечной точке, IP-адресу или другой области.
  • Что является учитываемой единицей: запрос, запись отслеживания или другая операция.
  • Используют ли конечные точки общее ограничение или имеют независимые разрешенные объемы.
  • Максимальное количество записей и размер полезной нагрузки, разрешенные в одном запросе.
  • Как дублирующие отправки, недействительные записи и повторные попытки влияют на использование.
  • Предоставляют ли ответы сведения об ограничении скорости или рекомендации по повторным попыткам.
  • Чем исчерпание квоты отличается от временного ограничения скорости.

Для интеграции с 17TRACK используйте официальную страницу Tracking API и документацию API в качестве отправной точки для этой конфигурации. До развертывания подтвердите поведение соответствующей конечной точки и ограничения учетной записи. Приведенные в этом руководстве расчетные значения пропускной способности являются иллюстрациями архитектуры, а не утверждениями о разрешенных объемах, размерах пакетов или гарантиях сервиса 17TRACK.

Разместите надежную очередь между обработкой заказов и регистрацией

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

Практический процесс выглядит так:

  1. Сохраните отправление и намерение его зарегистрировать. Используйте транзакционный outbox или эквивалентную схему, чтобы не сохранить заказ, потеряв при этом фоновую задачу.
  2. Проверьте и нормализуйте входные данные. Сохраняйте трекинг-номера как строки, включая ведущие нули. Применяйте нормализацию с учетом перевозчика только при наличии обоснования.
  3. Проверьте наличие существующей регистрации. Используйте стабильный идентификатор, соответствующий провайдеру и вашей модели данных.
  4. Поместите подходящие записи в очередь. Сохраняйте количество попыток, время следующей разрешенной повторной попытки и достаточный контекст для диагностики.
  5. Отправляйте через общий ограничитель. Получайте доступную емкость непосредственно перед исходящим запросом.
  6. Сохраняйте результаты на уровне записей. Разделяйте подтвержденный успех, ошибку с возможностью повторной попытки, окончательный отказ и неоднозначные результаты.

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

Координируйте ограничения между рабочими процессами

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

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

Используйте массовую регистрацию, не теряя контроль на уровне записей

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

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

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

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

Отделяйте текущий трафик от исторического импорта

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

Делайте повторные попытки контролируемыми, отложенными и ограниченными

HTTP 429 означает «Слишком много запросов». RFC 6585 указывает, что ответ 429 может содержать заголовок Retry-After. RFC 9110 определяет значение этого заголовка как дату HTTP или задержку в секундах. Клиент должен поддерживать оба формата, а не предполагать, что всегда возвращается целое число.

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

Классифицируйте сбои до выполнения повторной попытки:

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

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

Масштабируйте прием вебхуков независимо

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

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

Проектируйте потребителей так, чтобы они выдерживали повторную доставку, если только контракт провайдера явно не устанавливает иное. Для устранения дубликатов предпочтительно использовать документированный стабильный идентификатор события. Если его нет, тщательно спроектируйте и протестируйте составной идентификатор: использование только метки статуса может объединить разные события в одно.

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

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

Тестируйте восстановление, а не только максимальную пропускную способность

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

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

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

До начала пикового сезона распределите операционную ответственность. Инженеры должны отвечать за управление отправкой и инструменты восстановления; владелец интеграции должен подтверждать разрешенные объемы провайдера; операционная команда должна определить, какие отправления имеют приоритет. Документируйте, когда следует приостановить импорты, запросить дополнительную емкость или исследовать пропущенные обновления. Лучшая архитектура — та, которая остается предсказуемой, когда трафик превышает ее текущую производительность обработки.

Часто задаваемые вопросы

Увеличит ли добавление API-ключей пропускную способность?

Не обязательно. Несколько ключей могут использовать общий разрешенный объем на уровне учетной записи. Уточните область действия ограничения и разрешенный способ масштабирования у провайдера. Не используйте ротацию ключей для обхода ограничений.

Должна ли каждая регистрация использовать максимально возможный пакет?

Нет. Большие пакеты могут повысить эффективность запросов, но ожидание их заполнения увеличивает задержку при низком объеме трафика. Используйте документированный максимальный размер и таймер отправки, а затем настраивайте параметры на основе измеренной задержки принятия и характера сбоев.

Как предотвратить дублирующие регистрации после тайм-аута?

Используйте надежный локальный идентификатор отправления и документированное провайдером поведение для идемпотентности или обработки дубликатов. Если результат остается неопределенным, выполните сверку, если она поддерживается, прежде чем повторять отправку. Одна лишь локальная дедупликация не может доказать, был ли удаленный запрос успешным.

Означает ли успешная регистрация, что информация об отслеживании актуальна?

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

Когда команде следует запросить у провайдера дополнительную емкость?

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

Источники

Loading