Мащабируемост на Tracking API: Как да се справим с обема през пиковия сезон, ограниченията на честотата и масовата регистрация

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

За инженерните екипи, които свързват система за управление на поръчки, складова платформа или бекенд за електронна търговия с услуга за проследяване, целта не е просто да изпращат повече заявки. Тя е да регистрират пратките в определен времеви прозорец, да запазят актуализациите при пикове на трафика и да се възстановяват от повреди, без да създават дублираща работа.

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

Дневният обем пратки не е достатъчен за оразмеряване на интеграция. Складът може да освобождава повечето си номера за проследяване в кратък прозорец за експедиция, докато актуализациите на статусите пристигат през целия ден. Моделирайте тези натоварвания отделно.

• Постъпващи регистрации: Нови записи за пратки, влизащи във вашата система за секунда или минута, включително импортирания и пикове при освобождаване от склада.
• Изходящ 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 означава „Too Many Requests“. RFC 6585 определя, че отговор 429 може да включва заглавка Retry-After. RFC 9110 определя стойността на тази заглавка като HTTP дата или закъснение в секунди. Клиентът трябва да анализира и двете форми, вместо да приема, че винаги се връща цяло число.

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

Класифицирайте отказите преди повторен опит:

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

Задайте както лимит на опитите, така и максимална възраст на повторните опити. Премествайте изчерпаните елементи в опашка за неуспешни съобщения с причина, отговорник и процедура за повторно изпълнение. В противен случай старите откази могат незабелязано да консумират капацитета, предназначен за нови пратки.

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

Когато доставчикът предлага подходящи уебхукове, те могат да намалят повтарящото се извличане на статуси. Те създават и отделно входящо натоварване, което трябва да остане достъпно при пикове на актуализациите.

Поддържайте крайната точка за приемане фокусирана: валидирайте заявката чрез документирания от доставчика механизъм, съхранете събитието по надежден начин и върнете необходимото потвърждение. Обработвайте промените по поръчките, анализите и съобщенията до клиентите асинхронно. Не потвърждавайте получаването, преди събитието да е прието надеждно, ако това би създало риск от загубата му.

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

Защитете се и от актуализации извън ред. Съхранявайте историята на събитията отделно от производното текущо състояние на пратката. Прилагайте документираните времеви маркери на събитията и правилата за преход, когато са налични; не приемайте, че редът на пристигане е редът на събитията или че статусите на пратките образуват универсално нарастваща последователност.

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

Тествайте възстановяването, а не само максималната пропускателна способност

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

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

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

Преди пиковия сезон определете оперативната отговорност. Инженерният екип трябва да притежава контрола на изпращането и инструментите за възстановяване; собственикът на интеграцията трябва да потвърди правата при доставчика; оперативният екип трябва да определи кои пратки са с приоритет. Документирайте кога да спрете импортиранията, да заявите допълнителен капацитет или да проучите липсващи актуализации. Най-силният дизайн е този, който остава предвидим, когато трафикът надхвърли непосредствения му капацитет за обработка.

Често задавани въпроси

Ще увеличи ли добавянето на API ключове пропускателната способност?

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

Трябва ли всяка регистрация да използва възможно най-големия пакет?

Не. По-големите пакети могат да подобрят ефективността на заявките, но изчакването за запълването им увеличава латентността при малък обем. Използвайте документиран горен праг на размера заедно с таймер за изпращане, след което настройвайте въз основа на измерената латентност до приемане и поведението при откази.

Как могат да се предотвратят дублиращи се регистрации след изтичане на времето?

Използвайте надеждна локална идентичност на пратката и документираното от доставчика поведение за идемпотентност или обработка на дубликати. Ако резултатът остане несигурен, извършете съгласуване, когато това се поддържа, преди повторно изпращане. Самата локална дедупликация не може да докаже дали отдалечената заявка е била успешна.

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

Не. Приемането на регистрацията, наличността на събитие от превозвача, обработката от доставчика и собствената ви обработка на актуализациите са отделни етапи. Измервайте ги отделно, така че забавеното сканиране от превозвача да не бъде объркано с натрупване при регистрацията.

Кога екипът трябва да поиска повече капацитет от доставчика?

Поискайте го, когато прогнозните постъпвания и необходимото време за възстановяване надхвърлят проверения използваем капацитет след премахване на предотвратимите повторни опити, дублиращите се изпращания и неефективната пакетна обработка. По-голямото разрешено количество няма да поправи блокиран потребител или тесно място в базата данни, затова първо установете определящото ограничение.

Източници

• 17TRACK Tracking API — официална входна точка за предлагането на API.
• 17TRACK API documentation — справочник за проверка на изискванията за интеграция, поведението на крайните точки и приложимите ограничения на заявките.
• RFC 6585, Section 4: 429 Too Many Requests — семантика на HTTP ограничаването и незадължителни указания за Retry-After.
• RFC 9110, Section 10.2.3: Retry-After — формати HTTP-date и delay-seconds.
• RFC 9110, Section 9.2.2: Idempotent Methods — съображения за повторни опити, когато резултатът от заявката е несигурен.