Spremljanje razširljivosti API-ja: Kako obvladovati obseg v času največje sezone, omejitve hitrosti in množično registracijo

Za povečanje zmogljivosti API-ja za sledenje v času največje sezone postavite registracijo pošiljk za zanesljivo čakalno vrsto, uveljavite omejitve ponudnika za vse delavce, paketno obdelavo izvajajte samo v dokumentiranih omejitvah in posodobitve sledenja obdelujte asinhrono. Prepustnost registracije, promet ponovnih poskusov in obdelavo spletnih kavljev obravnavajte kot ločene težave zmogljivosti. Dodajanje več delavcev brez nadzora odhodnih zahtev lahko poveča omejevanje hitrosti namesto da bi zmanjšalo zaostanek.

Za inženirske ekipe, ki sistem za upravljanje naročil, skladiščno platformo ali zaledni sistem e-trgovine povezujejo s storitvijo za sledenje, cilj ni preprosto pošiljati več zahtev. Pošiljke je treba registrirati v določenem časovnem okviru, ohraniti posodobitve med prometnimi konicami in se po napakah obnoviti brez ustvarjanja podvojenega dela.

Dimenzionirajte delovno obremenitev glede na pošiljke, zahteve in posodobitve

Dnevni obseg pošiljk ni dovolj za dimenzioniranje integracije. Skladišče lahko večino številk za sledenje sprosti v kratkem časovnem oknu odpreme, medtem ko posodobitve stanja prihajajo ves dan. Te delovne obremenitve modelirajte ločeno.

• Prihodi registracij: Novi zapisi pošiljk, ki vstopajo v vaš sistem na sekundo ali minuto, vključno z uvozi in navali ob sprostitvi iz skladišča.
• Odhodni promet API-ja: Zahteve za registracijo, iskanja, popravki, klici za usklajevanje in ponovni poskusi.
• Prihodni promet posodobitev: Dostave spletnih kavljev in njihove ponovne dostave, če jih ponudnik podpira.
• Nadaljnja obdelava: Zapisi v bazo podatkov, obvestila strankam, analitični dogodki in spremembe statusa naročil, ki jih sproži vsaka posodobitev.

Določite interni cilj registracije, na primer najdaljši sprejemljivi čas med prejemom številke za sledenje in potrditvijo njene registracije. To naj bo ločeno od ažurnosti sledenja: uspešna registracija ne pomeni, da je skeniranje prevoznika že na voljo.

Izračunajte učinkovito zmogljivost registracije

Za končno točko registracije, omejeno s številom zahtev, je uporabna naslednja povezava za načrtovanje:

Zmogljivost registracije = dovoljene zahteve na sekundo × povprečno število zapisov na zahtevo × delež uspešnih zapisov

To je ocena za načrtovanje, ne jamstvo ponudnika. Predpostavlja, da so omejitve zahtev odločilna omejitev. Kvote na podlagi zapisov, velikost vsebine, zakasnitev in skupne omejitve računa lahko določijo nižjo zgornjo mejo.

Za ponazoritev predpostavimo, da ima integracija dovoljenje za dve zahtevi za registracijo na sekundo in v vsaki zahtevi pošlje povprečno 30 zapisov. Njena nazivna zmogljivost je pred napakami in drugimi omejitvami 60 zapisov na sekundo. Če prihajajoče registracije med trajajočim navalom v povprečju dosegajo 80 zapisov na sekundo, se čakalna vrsta povečuje za približno 20 zapisov na sekundo. Te številke so hipotetične in ne predstavljajo omejitev 17TRACK.

Izračunajte tudi zmogljivost obnovitve. Če novi prihodi še naprej prihajajo s hitrostjo λ in je učinkovita zmogljivost obdelave μ, se obstoječi zaostanek B zapisov izprazni v približno B / (μ − λ) sekundah, ko je μ > λ. Če zmogljivost obdelave ne presega hitrosti prihodov, se zaostanek v teh pogojih ne bo zmanjšal.

Potrdite, kaj ponudnik dejansko omejuje

Omejitev hitrosti in dovoljena poraba rešujeta različna problema. Omejitev hitrosti nadzoruje, kako hitro je mogoče poslati zahteve ali zapise. Dovoljena poraba lahko nadzoruje, koliko dejavnosti sledenja lahko račun porabi v obračunskem obdobju ali obdobju upravičenosti. Biti pod eno omejitvijo ne pomeni skladnosti z drugo.

Pred nastavitvijo števila delavcev glede na dokumentacijo ponudnika in pogoje vašega računa potrdite naslednje:

• Ali omejitve veljajo na ravni računa, ključa API, končne točke, naslova IP ali drugega obsega.
• Ali je šteta enota zahteva, zapis sledenja ali druga operacija.
• Ali si končne točke delijo omejitev ali imajo neodvisne dovoljene količine.
• Največje število zapisov in dovoljena velikost vsebine v eni zahtevi.
• Kako podvojene predložitve, neveljavni zapisi in ponovni poskusi vplivajo na porabo.
• Ali odgovori razkrivajo informacije o omejevanju hitrosti ali navodila za ponovni poskus.
• Kako se izčrpanje kvote razlikuje od začasnega omejevanja hitrosti.

Za integracijo 17TRACK uporabite uradno stran Tracking API in dokumentacijo API-ja kot izhodišče za to konfiguracijo. Pred uvedbo potrdite veljavno vedenje končne točke in omejitve računa. Zmogljivosti, prikazane v tem priročniku, so ponazoritve arhitekture in ne izjave o upravičenjih, velikostih paketov ali jamstvih storitve 17TRACK.

Med obdelavo naročil in registracijo postavite zanesljivo čakalno vrsto

Ne dovolite, da zaključek nakupa ali skladiščnega postopka čaka, da ponudnik sledenja sprejme registracijo. Pošiljko trajno shranite lokalno, trajno zabeležite registracijsko nalogo in prepustite pošiljanje delavcem v ozadju.

Praktičen potek je:

1. Shranite pošiljko in njen namen registracije. Uporabite transakcijski outbox ali enakovredno zasnovo, da se izognete shranjevanju naročila ob izgubi naloge v ozadju.
2. Preverite in normalizirajte vnose. Številke za sledenje ohranite kot nize, vključno z začetnimi ničlami. Normalizacijo, specifično za prevoznika, uporabite samo, kadar je utemeljena.
3. Preverite obstoječo registracijo. Uporabite stabilno identiteto, primerno za ponudnika in vaš podatkovni model.
4. Postavite upravičene zapise v čakalno vrsto. Shranite število poskusov, čas naslednjega upravičenega ponovnega poskusa in dovolj konteksta za diagnostiko.
5. Pošiljajte prek skupnega omejevalnika. Zmogljivost pridobite neposredno pred odhodno zahtevo.
6. Shranite rezultate na ravni zapisov. Ločite potrjen uspeh, napako, ki jo je mogoče ponoviti, trajno zavrnitev in dvoumne rezultate.

Čakalna vrsta absorbira naval; ne ustvarja zmogljivosti ponudnika. Če se starost najstarejšega upravičenega zapisa nenehno povečuje, raziščite razliko med hitrostjo prihodov in zmogljivostjo obdelave, namesto da preprosto povečate število delavcev.

Uskladite omejitve med delavci

Neodvisni delavci ne smejo vsak zase predvidevati, da lahko porabijo celotno dovoljeno količino računa. Uporabite usklajen omejevalnik hitrosti ali razpošiljevalnik, ki dodeljuje skupni proračun zahtev. V ta proračun vključite načrtovane uvoze, operativne skripte in opravila usklajevanja.

Hitrost in sočasnost sta različna nadzora. Omejevalnik nadzoruje, kako pogosto se zahteve začnejo; omejitev sočasnosti nadzoruje, koliko jih ostane v izvajanju. Oboje je koristno, ko se zakasnitev ponudnika poveča. Povečanje sočasnosti lahko pomaga delovni obremenitvi, omejeni z zakasnitvijo, vendar ne more zaobiti omejitve odhodne hitrosti.

Uporabite množično registracijo, ne da bi izgubili nadzor na ravni zapisov

Kjer končna točka podpira več zapisov na zahtevo, lahko paketna obdelava zmanjša režijske stroške zahtev. Ni nujno, da zmanjša porabo na podlagi zapisov, največji dovoljeni paket pa ni vedno najboljša operativna izbira.

Pakete sestavljajte z dvema sprožilcema: največjim številom zapisov in najdaljšim časom čakanja. Pošljite jih, ko je dosežen kateri koli od njiju. Tako lahko prometna obdobja učinkovito zapolnijo pakete, promet z majhnim obsegom pa ne bo čakal nedoločen čas.

• Upoštevajte omejitve vsebine in število zapisov. Izbirni metapodatki lahko povzročijo, da se enako veliki paketi zelo razlikujejo po številu bajtov.
• Vzdržujte interni manifest paketa. Zabeležite, katere lokalne identitete pošiljk so bile poslane, in vsak vrnjeni rezultat pravilno povežite z njim.
• Preglejte rezultate na ravni aplikacije. Uspešen odgovor HTTP sam po sebi ne dokazuje, da je bil sprejet vsak zapis.
• Ponovno pošljite samo zapise, ki to potrebujejo. Ponovno predvajanje uspešnih zapisov ustvarja nepotreben promet in lahko vpliva na porabo.
• Trajne napake pri preverjanju usmerite v popravek. Nespremenjena neveljavna vsebina ne sme krožiti skozi čakalno vrsto za ponovne poskuse.

Posebej pomembna je časovna omejitev: ponudnik je zahtevo morda sprejel, čeprav vaš odjemalec ni prejel odgovora. Tak rezultat označite kot dvoumen. Razrešite ga s podprtim mehanizmom idempotentnosti, dokumentiranim pravilom za podvojeno registracijo ali iskanjem za usklajevanje, kjer je na voljo. Ne predpostavljajte, da je zapis, ki je potekel zaradi časovne omejitve, neuspešen.

Ločite sprotni promet od zgodovinskih uvozov

Ponovna zapolnitev ne sme porabiti vse zmogljivosti, potrebne za na novo odpremljene pošiljke. Uporabite ločene čakalne vrste s ponderiranim razporejanjem ali izrecnimi rezervacijami zmogljivosti. Uvozom dovolite uporabo proste zmogljivosti, hkrati pa ohranite minimalno dodelitev za sprotne registracije. Uporabite staranje ali drugo pravilo pravičnosti, da bodo zapisi z nižjo prednostjo sčasoma obdelani.

Ponovne poskuse izvajajte nadzorovano, z zamikom in omejeno

HTTP 429 pomeni »Too Many Requests«. RFC 6585 določa, da lahko odgovor 429 vključuje glavo Retry-After. RFC 9110 določa vrednost te glave kot datum HTTP ali zakasnitev v sekundah. Odjemalec mora razčleniti obe obliki, namesto da vedno predpostavi vrnjeno celo število.

Ko je podana veljavna zakasnitev ponovnega poskusa, ne poskušajte znova, preden poteče. Ko navodila za ponovni poskus niso na voljo, uporabite omejeno eksponentno umikanje z naključnostjo: postopoma povečujte zakasnitev med poskusi in dodajte naključnost, da vsi delavci ne bi poskušali znova hkrati. Ponovni poskusi morajo potekati skozi isti omejevalnik odhodnega prometa kot prvi poskusi.

Pred ponovnim poskusom razvrstite napake:

• Omejevanje hitrosti: Zakasnite prizadeto delo in zmanjšajte pritisk razpošiljanja v ustreznem obsegu omejitve.
• Začasne omrežne ali strežniške napake: Ponovite v okviru omejene politike in upoštevajte dvoumne rezultate zapisovanja.
• Napake pri preverjanju pristnosti ali avtorizaciji: Sprožite opozorilo in zaustavite prizadeto delo, dokler poverilnice ali dovoljenja niso popravljeni.
• Napake pri preverjanju: Zapis popravite ali ga ločite, namesto da ga nespremenjenega ponovno pošljete.
• Izčrpana dovoljena količina: Upoštevajte dokumentirano rešitev za račun, namesto da bi to obravnavali kot kratkotrajen prometni naval.

Nastavite omejitev števila poskusov in največjo starost ponovnega poskusa. Izčrpane elemente premaknite v čakalno vrsto za zavržena sporočila z razlogom, odgovorno osebo in postopkom za ponovno predvajanje. V nasprotnem primeru lahko stare napake tiho porabljajo zmogljivost, namenjeno novim pošiljkam.

Vnos spletnih kavljev povečujte neodvisno

Kjer ponudnik ponuja ustrezne spletne kavlje, lahko ti zmanjšajo ponavljajoče se preverjanje stanja. Ustvarjajo pa tudi ločeno prihajajočo delovno obremenitev, ki mora ostati razpoložljiva med navali posodobitev.

Prejemna končna točka naj bo osredotočena: zahtevo preverite z dokumentiranim mehanizmom ponudnika, dogodek trajno shranite in vrnite zahtevano potrdilo. Spremembe naročil, analitiko in sporočila strankam obdelujte asinhrono. Prejema ne potrjujte, preden ni zagotovljen trajni sprejem, če bi s tem tvegali izgubo dogodka.

Potrošnike zasnujte tako, da prenesejo podvojeno dostavo, razen če pogodba s ponudnikom izrecno določa drugače. Za odstranjevanje dvojnikov raje uporabite dokumentiran stabilen identifikator dogodka. Če ta ne obstaja, sestavljeno identiteto skrbno zasnujte in preizkusite: uporaba samo oznake stanja bi lahko različne dogodke združila v enega.

Zaščitite se tudi pred posodobitvami, ki prispejo izven vrstnega reda. Zgodovino dogodkov shranjujte ločeno od izpeljanega trenutnega stanja pošiljke. Kjer je mogoče, uporabite dokumentirane časovne žige dogodkov in pravila prehodov; ne predpostavljajte, da je vrstni red prihoda vrstni red dogodkov ali da stanja pošiljke tvorijo univerzalno naraščajoče zaporedje.

Usklajevanje naj bo ciljno usmerjeno in omejeno s hitrostjo. Z njim lahko preiskujete domnevne vrzeli pri dostavi ali dvoumne registracije, vendar lahko agresivno preverjanje vsake pošiljke znova ustvari odhodno obremenitev, ki naj bi se ji spletni kavlji izognili.

Preizkusite obnovitev, ne le največje prepustnosti

Preizkuse obremenitve lastnih komponent izvajajte s simulatorjem ponudnika. Preizkuse, ki pošiljajo pomemben promet živemu ponudniku, uskladite in ostanite znotraj dovoljenih omejitev. Uspešen preizkus mora pokazati, da se sistem po motnji vrne v normalno stanje, ne le da sprejme velik naval.

• Ponovite naval, značilen za skladišče, ki mu sledi nadaljevanje običajnega prometa.
• Vstavite odzive z omejevanjem hitrosti, povečano zakasnitvijo in začasnimi strežniškimi napakami.
• Simulirajte delno zavrnitev paketa in časovno omejitev po sprejemu na strani strežnika.
• Dostavite podvojene dogodke spletnih kavljev in dogodke izven vrstnega reda.
• Prekinite dostop do baze podatkov in preverite, da nesprejeti dogodki niso napačno potrjeni.
• Zaženite ponovno zapolnitev poleg sprotnih registracij in preverite pravičnost.
• Ponovno predvajajte elemente iz čakalne vrste za zavržena sporočila, ne da bi zaobšli omejitve hitrosti.

Spremljajte starost najstarejše upravičene registracije, zakasnitev sprejema, stopnjo uspeha na ravni zapisov, pogostost omejevanja hitrosti, obseg ponovnih poskusov, zaostanek pri obdelavi spletnih kavljev in rast čakalne vrste za zavržena sporočila. Sama globina čakalne vrste ni zadostna: velika čakalna vrsta se lahko hitro izprazni, majhna pa lahko vsebuje nekaj pogosto neuspešnih, poslovno ključnih pošiljk.

Pred največjo sezono določite operativno odgovornost. Inženiring naj bo odgovoren za nadzor razpošiljanja in orodja za obnovitev; lastnik integracije naj potrdi upravičenja ponudnika; operacije naj določijo, katere pošiljke imajo prednost. Dokumentirajte, kdaj zaustaviti uvoze, zahtevati dodatno zmogljivost ali preiskati manjkajoče posodobitve. Najboljša zasnova je tista, ki ostane predvidljiva, ko promet preseže njeno trenutno zmogljivost obdelave.

POGOSTA VPRAŠANJA

Ali bo dodajanje ključev API povečalo prepustnost?

Ni nujno. Več ključev si lahko deli dovoljeno količino na ravni računa. Pri ponudniku potrdite obseg omejitve in dovoljen način povečevanja. Ne uporabljajte menjavanja ključev za zaobidenje omejitev.

Ali mora vsaka registracija uporabiti največji možni paket?

Ne. Večji paketi lahko izboljšajo učinkovitost zahtev, vendar čakanje na njihovo zapolnitev pri majhnem obsegu poveča zakasnitev. Uporabite dokumentirano zgornjo mejo velikosti in časovnik za pošiljanje, nato pa nastavitev prilagodite na podlagi izmerjene zakasnitve sprejema in vedenja pri napakah.

Kako preprečiti podvojene registracije po časovni omejitvi?

Uporabite trajno lokalno identiteto pošiljke ter dokumentirano idempotentnost ponudnika ali njegovo vedenje pri obravnavi dvojnikov. Če izid ostane negotov, ga pred ponovnim predvajanjem uskladite, kjer je to podprto. Lokalno odstranjevanje dvojnikov samo po sebi ne more dokazati, ali je bila oddaljena zahteva uspešna.

Ali uspešna registracija pomeni, da so informacije o sledenju ažurne?

Ne. Sprejem registracije, razpoložljivost dogodka prevoznika, obdelava ponudnika in vaša lastna obdelava posodobitev so ločene faze. Merite jih ločeno, da se zakasnjeno skeniranje prevoznika ne zamenja z zaostankom registracije.

Kdaj naj ekipa zahteva več zmogljivosti ponudnika?

Zahtevajte jo, ko napovedani prihodi in zahtevani čas obnovitve presežejo preverjeno uporabno zmogljivost, potem ko odstranite ponovne poskuse, podvojene predložitve in neučinkovito paketno obdelavo, ki se jim je mogoče izogniti. Večja dovoljena količina ne bo odpravila blokiranega potrošnika ali ozkega grla v bazi podatkov, zato najprej ugotovite odločilno omejitev.

Viri

• 17TRACK Tracking API — uradna vstopna točka za ponudbo API-ja.
• Dokumentacija API-ja 17TRACK — referenca za preverjanje zahtev integracije, vedenja končnih točk in veljavnih omejitev zahtev.
• RFC 6585, razdelek 4: 429 Too Many Requests — semantika omejevanja hitrosti HTTP in neobvezna navodila Retry-After.
• RFC 9110, razdelek 10.2.3: Retry-After — obliki HTTP-date in delay-seconds.
• RFC 9110, razdelek 9.2.2: Idempotentne metode — vidiki ponovnih poskusov, ko je izid zahteve negotov.