Tracking API:n skaalautuvuus: kuinka käsitellä sesonkiajan volyymia, nopeusrajoituksia ja joukkorekisteröintiä

Seuranta-API:n skaalaamiseksi sesonkihuipun aikana sijoita lähetysten rekisteröinti kestävään jonoon, valvo palveluntarjoajan rajoituksia kaikkien työntekijöiden yli, käytä eräajoa vain dokumentoitujen rajojen puitteissa ja käsittele seurantapäivitykset asynkronisesti. Käsittele rekisteröinnin läpimeno, uudelleenyritykset ja webhookien käsittely erillisinä kapasiteettiongelmina. Työntekijöiden lisääminen ilman lähtevien pyyntöjen hallintaa voi lisätä rajoitusten aiheuttamaa hidastamista sen sijaan, että se purkaisi jonosi.

Kun tekniset tiimit yhdistävät tilaustenhallintajärjestelmän, varastoalustan tai verkkokaupan taustajärjestelmän seurantapalveluun, tavoitteena ei ole vain lähettää enemmän pyyntöjä. Tavoitteena on rekisteröidä lähetykset määritellyssä aikaikkunassa, säilyttää päivitykset liikennepiikkien aikana ja palautua virheistä luomatta päällekkäistä työtä.

Mitoita työmäärä lähetysten, pyyntöjen ja päivitysten perusteella

Päivittäinen lähetysten määrä ei yksin riitä integraation mitoittamiseen. Varasto voi vapauttaa suurimman osan seurantatunnuksista lyhyen lähetysikkunan aikana, kun taas tilapäivityksiä saapuu koko päivän ajan. Mallinna nämä työmäärät erikseen.

• Rekisteröintien saapuminen: Järjestelmääsi sekunnissa tai minuutissa saapuvien uusien lähetystietueiden määrä, mukaan lukien tuonnit ja varaston vapautuspiikit.
• Lähtevä API-liikenne: Rekisteröintipyynnöt, haut, korjaukset, täsmäytyskutsut ja uudelleenyritykset.
• Saapuva päivitysliikenne: Webhook-toimitukset ja uudelleentoimitukset, jos palveluntarjoaja tukee niitä.
• Jatkokäsittely: Tietokantakirjoitukset, asiakasilmoitukset, analytiikkatapahtumat ja jokaisen päivityksen käynnistämät tilamuutokset.

Aseta sisäinen rekisteröintitavoite, kuten suurin hyväksyttävä aika seurantatunnuksen vastaanottamisen ja rekisteröinnin vahvistamisen välillä. Pidä tämä erillään seurannan ajantasaisuudesta: onnistunut rekisteröinti ei tarkoita, että kuljetusliikkeen skannaustieto olisi jo saatavilla.

Laske todellinen rekisteröintikapasiteetti

Pyyntörajoitetulle rekisteröinnin päätepisteelle hyödyllinen suunnittelusuhde on:

Rekisteröintikapasiteetti = sallittuja pyyntöjä sekunnissa × tietueiden keskimääräinen määrä pyyntöä kohden × onnistuneiden tietueiden osuus

Tämä on suunnitteluarvio, ei palveluntarjoajan takuu. Se olettaa, että pyyntörajoitukset ovat sitova rajoite. Tietuepohjaiset kiintiöt, hyötykuorman koko, viive ja jaetut tilikohtaiset rajoitukset voivat asettaa matalamman ylärajan.

Esimerkkinä oletetaan, että integraatio saa lähettää kaksi rekisteröintipyyntöä sekunnissa ja lähettää kussakin pyynnössä keskimäärin 30 tietuetta. Sen nimelliskapasiteetti on 60 tietuetta sekunnissa ennen virheitä ja muita rajoitteita. Jos saapuvia rekisteröintejä tulee jatkuvan piikin aikana keskimäärin 80 tietuetta sekunnissa, jono kasvaa noin 20 tietueella sekunnissa. Nämä luvut ovat hypoteettisia eivätkä ole 17TRACKin rajoituksia.

Laske myös palautumiskapasiteetti. Jos uusia tietueita saapuu nopeudella λ ja tehokas käsittelykapasiteetti on μ, olemassa olevan B tietueen jonon purkaminen kestää noin B / (μ − λ) sekuntia, kun μ > λ. Jos käsittelykapasiteetti ei ylitä saapumisnopeutta, jono ei tyhjene näissä olosuhteissa.

Varmista, mitä palveluntarjoaja todella rajoittaa

Nopeusrajoitus ja käyttökiintiö ratkaisevat eri ongelmia. Nopeusrajoitus määrittää, kuinka nopeasti pyyntöjä tai tietueita voidaan lähettää. Käyttökiintiö voi määrittää, kuinka paljon seurantatoimintaa tili voi käyttää laskutus- tai käyttöoikeusjakson aikana. Yhden rajan alittaminen ei tarkoita, että toinenkin raja täyttyy.

Ennen työntekijämäärien määrittämistä tarkista seuraavat asiat palveluntarjoajan dokumentaatiosta ja tilisi ehdoista:

• Sovelletaanko rajoituksia tiliin, API-avaimeen, päätepisteeseen, IP-osoitteeseen vai johonkin muuhun kohteeseen.
• Onko laskettava yksikkö pyyntö, seurantatietue vai jokin muu toiminto.
• Jakavatko päätepisteet saman rajoituksen vai onko niillä erilliset kiintiöt.
• Yhdessä pyynnössä sallittu tietueiden enimmäismäärä ja hyötykuorman enimmäiskoko.
• Miten päällekkäiset lähetykset, virheelliset tietueet ja uudelleenyritykset vaikuttavat käyttöön.
• Palauttavatko vastaukset tietoa rajoituksista tai ohjeita uudelleenyritykseen.
• Miten kiintiön loppuminen eroaa tilapäisestä nopeusrajoituksesta.

17TRACK-integraatiossa käytä virallista Tracking API -sivua ja API-dokumentaatiota tämän määrityksen lähtökohtina. Vahvista sovellettavan päätepisteen toiminta ja tilikohtaiset rajoitukset ennen käyttöönottoa. Tämän oppaan esimerkkikapasiteetit ovat arkkitehtuuriesimerkkejä eivätkä lausuntoja 17TRACKin käyttöoikeuksista, eräkoista tai palvelutakuista.

Sijoita kestävä jono tilausten käsittelyn ja rekisteröinnin väliin

Älä pakota kassaa tai varaston valmistumista odottamaan, että seurantapalveluntarjoaja hyväksyy rekisteröinnin. Tallenna lähetys paikallisesti, tallenna rekisteröintitehtävä kestävästi ja anna taustatyöntekijöiden käsitellä lähetys.

Käytännöllinen työnkulku on:

1. Tallenna lähetys ja sen rekisteröintiaikomus. Käytä transaktionaalista outbox-mallia tai vastaavaa rakennetta, jotta tilausta ei tallenneta ilman taustatehtävää.
2. Vahvista ja normalisoi syötteet. Säilytä seurantatunnukset merkkijonoina, myös alkunollat. Käytä kuljetusliikekohtaista normalisointia vain, kun se on perusteltua.
3. Tarkista olemassa oleva rekisteröinti. Käytä palveluntarjoajalle ja tietomallillesi sopivaa vakaata tunnistetta.
4. Aseta kelvolliset tietueet jonoon. Tallenna yritysten määrä, seuraava sallittu uudelleenyritysaika ja riittävä konteksti vianmääritystä varten.
5. Lähetä jaetun rajoittimen kautta. Hanki kapasiteetti välittömästi ennen lähtevää pyyntöä.
6. Tallenna tietuetason tulokset. Erota vahvistettu onnistuminen, uudelleenyrityskelpoinen virhe, pysyvä hylkäys ja epäselvät tulokset.

Jono vastaanottaa piikin, mutta se ei luo palveluntarjoajalle lisää kapasiteettia. Jos vanhin käsittelykelpoinen tietue vanhenee jatkuvasti, selvitä saapumisnopeuden ja käsittelykapasiteetin välinen ero sen sijaan, että lisäisit vain työntekijöitä.

Koordinoi rajoitukset työntekijöiden kesken

Erilliset työntekijät eivät saa olettaa, että kukin voi käyttää koko tilikohtaista kiintiötä. Käytä koordinoitua nopeusrajoitinta tai välittäjää, joka jakaa yhteisen pyyntöbudjetin. Sisällytä tähän budjettiin ajoitetut tuonnit, operatiiviset skriptit ja täsmäytystyöt.

Nopeus ja samanaikaisuus ovat eri säätimiä. Rajoitin hallitsee pyyntöjen käynnistystiheyttä, kun taas samanaikaisuusrajoitus hallitsee yhtä aikaa käynnissä olevien pyyntöjen määrää. Molemmat ovat hyödyllisiä palveluntarjoajan viiveen kasvaessa. Samanaikaisuuden lisääminen voi auttaa viiveeseen rajoittuvassa työmäärässä, mutta se ei voi ohittaa lähtevän liikenteen nopeusrajoitusta.

Käytä massarekisteröintiä menettämättä tietuetason hallintaa

Jos päätepiste tukee useita tietueita pyyntöä kohden, eräajo voi vähentää pyyntöjen aiheuttamaa kuormaa. Se ei välttämättä vähennä tietuepohjaista käyttöä, eikä suurin sallittu erä ole aina paras operatiivinen valinta.

Muodosta erät kahden laukaisimen avulla: tietueiden enimmäismäärä ja enimmäisodotusaika. Lähetä erä, kun jompikumpi täyttyy. Näin vilkkaat jaksot voivat täyttää erät tehokkaasti ilman, että vähäisen liikenteen tarvitsee odottaa loputtomasti.

• Huomioi hyötykuorman rajat tietuemäärien lisäksi. Valinnaiset metatiedot voivat tehdä samankokoisista eristä kooltaan hyvin erilaisia.
• Säilytä sisäinen eräluettelo. Kirjaa, mitkä paikalliset lähetysidentiteetit lähetettiin, ja yhdistä jokainen palautettu tulos oikeaan tietueeseen.
• Tarkista sovellustason tulokset. HTTP-onnistumisvastaus ei yksin todista, että jokainen tietue hyväksyttiin.
• Yritä uudelleen vain niitä tietueita, jotka sitä tarvitsevat. Onnistuneiden tietueiden uudelleenlähetys luo tarpeetonta liikennettä ja voi vaikuttaa käyttöön.
• Ohjaa pysyvät validointivirheet korjattaviksi. Muuttumattoman virheellisen hyötykuorman ei pidä kiertää uudelleenyritysjonossa.

Aikakatkaisu on erityisen tärkeä: palveluntarjoaja on voinut hyväksyä pyynnön, vaikka asiakas ei saanut vastausta. Merkitse tulos epäselväksi. Selvitä tilanne tuetun idempotenssimekanismin, dokumentoidun päällekkäisen rekisteröinnin säännön tai mahdollisen täsmäytyshaun avulla. Älä oleta, että aikakatkaistu kirjoitus epäonnistui.

Erota reaaliaikainen liikenne historiallisista tuonneista

Takautuva tuonti ei saa käyttää kaikkea kapasiteettia, jota tarvitaan juuri lähetettyihin lähetyksiin. Käytä erillisiä jonoja painotetulla ajoituksella tai määritellyillä kapasiteettivarauksilla. Anna tuontien käyttää vapaata kapasiteettia ja säilytä samalla vähimmäisosuus reaaliaikaisille rekisteröinneille. Käytä vanhenemiseen perustuvaa tai muuta reiluussääntöä, jotta alemman prioriteetin tietueet käsitellään lopulta.

Tee uudelleenyrityksistä hallittuja, viivästettyjä ja rajattuja

HTTP 429 tarkoittaa “Too Many Requests”. RFC 6585 määrittää, että 429-vastaus voi sisältää Retry-After-otsakkeen. RFC 9110 määrittää, että otsakkeen arvo on joko HTTP-päivämäärä tai viive sekunteina. Asiakkaan tulee jäsentää molemmat muodot eikä olettaa, että aina palautetaan kokonaisluku.

Kun kelvollinen uudelleenyritysviive ilmoitetaan, älä yritä uudelleen ennen sen päättymistä. Jos ohje puuttuu, käytä rajattua eksponentiaalista backoffia jitterillä: kasvata yritysten välistä viivettä asteittain ja lisää satunnaisuutta, jotta työntekijät eivät yritä kaikki samanaikaisesti. Uudelleenyritysten on kuljettava saman lähtevän liikenteen rajoittimen kautta kuin ensimmäisten yritysten.

Luokittele virheet ennen uudelleenyritystä:

• Nopeusrajoitus: Viivytä kyseistä työtä ja vähennä lähetyspainetta asiaankuuluvan rajoituksen piirissä.
• Tilapäiset verkko- tai palvelinvirheet: Yritä uudelleen rajatun käytännön mukaisesti ja huomioi epäselvät kirjoitustulokset.
• Todennus- tai valtuutusvirheet: Hälytä ja keskeytä kyseinen työ, kunnes tunnistetiedot tai käyttöoikeudet on korjattu.
• Validointivirheet: Korjaa tai eristä tietue sen sijaan, että lähettäisit sen muuttumattomana uudelleen.
• Loppuun käytetty kiintiö: Noudata dokumentoitua tilin korjausmenettelyä sen sijaan, että käsittelisit tilannetta lyhyenä liikennepiikkinä.

Aseta sekä yritysten enimmäismäärä että uudelleenyritysten enimmäisikä. Siirrä loppuun käsitellyt kohteet dead-letter-jonoon ja tallenna syy, vastuuhenkilö sekä uudelleentoiston menettely. Muuten vanhat virheet voivat huomaamatta kuluttaa uusille lähetyksille tarkoitettua kapasiteettia.

Skaalaa webhookien vastaanotto erikseen

Jos palveluntarjoaja tarjoaa sopivia webhooks-rajapintoja, ne voivat vähentää toistuvaa tilojen pollausta. Ne luovat kuitenkin erillisen saapuvan työmäärän, jonka on pysyttävä käytettävissä päivityspiikkien aikana.

Pidä vastaanottava päätepiste keskittyneenä: vahvista pyyntö palveluntarjoajan dokumentoidulla mekanismilla, tallenna tapahtuma kestävästi ja palauta vaadittu kuittaus. Käsittele tilamuutokset, analytiikka ja asiakasviestit asynkronisesti. Älä kuittaa vastaanottoa ennen kestävää hyväksyntää, jos se voisi aiheuttaa tapahtuman menettämisen.

Suunnittele kuluttajat kestämään päällekkäiset toimitukset, ellei palveluntarjoajan sopimuksessa nimenomaisesti muuta määrätä. Käytä deduplikointiin mieluiten dokumentoitua vakaata tapahtumatunnistetta. Jos sellaista ei ole, suunnittele ja testaa yhdistelmäidentiteetti huolellisesti: pelkän tilatunnisteen käyttäminen voisi yhdistää erilliset tapahtumat yhdeksi.

Suojaudu myös väärässä järjestyksessä saapuvilta päivityksiltä. Tallenna tapahtumahistoria erillään johdetusta nykyisestä lähetys­tilasta. Sovella dokumentoituja tapahtuma-aikaleimoja ja siirtymäsääntöjä, jos niitä on saatavilla; älä oleta, että saapumisjärjestys on tapahtumajärjestys tai että lähetys­tilat muodostavat aina kasvavan sarjan.

Pidä täsmäytys kohdennettuna ja nopeusrajoitettuna. Sen avulla voidaan tutkia epäiltyjä toimitusaukkoja tai epäselviä rekisteröintejä, mutta jokaisen lähetyksen aggressiivinen pollaaminen voi luoda uudelleen lähtevän kuorman, jota webhookien oli tarkoitus vähentää.

Testaa palautumista, älä vain enimmäisläpimenoa

Suorita kuormitustestit omia komponenttejasi vastaan palveluntarjoajan simulaattorilla. Koordinoi testit, jotka lähettävät merkittävää liikennettä oikealle palveluntarjoajalle, ja pysy sallituissa rajoissa. Onnistuneen testin tulee osoittaa, että järjestelmä palaa normaalitilaan häiriön jälkeen, ei vain sitä, että se hyväksyy suuren piikin.

• Toista varastotyylinen piikki, jota seuraa jatkuva normaali liikenne.
• Syötä rajoitusvastauksia, kohonnutta viivettä ja tilapäisiä palvelinvirheitä.
• Simuloi osittaista erän hylkäystä ja aikakatkaisua palvelimen hyväksyttyä pyynnön.
• Toimita päällekkäisiä ja väärässä järjestyksessä saapuvia webhook-tapahtumia.
• Keskeytä tietokannan käyttö ja varmista, ettei hyväksymättömiä tapahtumia kuitata virheellisesti.
• Suorita takautuva tuonti reaaliaikaisten rekisteröintien rinnalla ja tarkista reiluus.
• Toista dead-letter-kohteet ohittamatta nopeusrajoituksia.

Seuraa vanhimman käsittelykelpoisen rekisteröinnin ikää, hyväksymisviivettä, tietuetason onnistumisastetta, rajoitusten yleisyyttä, uudelleenyritysten määrää, webhookien käsittelyviivettä ja dead-letter-jonon kasvua. Pelkkä jonon syvyys ei riitä: suuri jono voi tyhjentyä nopeasti, kun taas pieni jono voi sisältää muutaman toistuvasti epäonnistuvan ja liiketoiminnalle kriittisen lähetyksen.

Määritä operatiivinen vastuu ennen sesonkihuippua. Teknisen tiimin tulee vastata lähetyksen hallinnasta ja palautustyökaluista; integraatiosta vastaavan tulee vahvistaa palveluntarjoajan käyttöoikeudet; operaatioiden tulee määrittää priorisoitavat lähetykset. Dokumentoi, milloin tuonnit keskeytetään, milloin pyydetään lisäkapasiteettia ja milloin puuttuvia päivityksiä tutkitaan. Paras rakenne on sellainen, joka pysyy ennakoitavana, kun liikenne ylittää sen välittömän käsittelykapasiteetin.

Usein kysytyt kysymykset

Lisäävätkö API-avainten lisääminen läpimenoa?

Eivät välttämättä. Useat avaimet voivat jakaa tilikohtaisen kiintiön. Vahvista rajoituksen laajuus ja sallittu skaalaustapa palveluntarjoajalta. Älä käytä avainten kierrätystä rajoitusten ohittamiseen.

Pitäisikö jokaisessa rekisteröinnissä käyttää suurinta mahdollista erää?

Ei. Suuremmat erät voivat parantaa pyyntötehokkuutta, mutta niiden täyttymisen odottaminen lisää viivettä vähäisen liikenteen aikana. Käytä dokumentoitua kokorajaa ja ajastettua lähetystä, ja säädä niitä mitatun hyväksymisviiveen ja virhekäyttäytymisen perusteella.

Miten päällekkäiset rekisteröinnit voidaan estää aikakatkaisun jälkeen?

Käytä kestävää paikallista lähetysidentiteettiä sekä palveluntarjoajan dokumentoitua idempotenssi- tai päällekkäiskäsittelyä. Jos tulos jää epävarmaksi, täsmäytä se tuetulla tavalla ennen uudelleenlähetystä. Paikallinen deduplikointi yksin ei voi todistaa, onnistuiko etäpyyntö.

Tarkoittaako onnistunut rekisteröinti, että seurantatiedot ovat ajan tasalla?

Ei. Rekisteröinnin hyväksyminen, kuljetusliikkeen tapahtuman saatavuus, palveluntarjoajan käsittely ja omien päivitystesi käsittely ovat erillisiä vaiheita. Mittaa ne erikseen, jotta viivästynyttä kuljetusliikkeen skannausta ei sekoiteta rekisteröintijonoon.

Milloin tiimin pitäisi pyytää palveluntarjoajalta lisää kapasiteettia?

Pyydä lisää kapasiteettia, kun ennustetut saapumiset ja vaadittu palautumisaika ylittävät vahvistetun käytettävissä olevan kapasiteetin sen jälkeen, kun vältettävissä olevat uudelleenyritykset, päällekkäiset lähetykset ja tehoton eräajo on poistettu. Suurempi kiintiö ei korjaa jumittunutta kuluttajaa tai tietokantapullonkaulaa, joten tunnista ensin sitova rajoite.

Lähteet

• 17TRACK Tracking API — virallinen lähtöpiste API-tarjonnalle.
• 17TRACK API documentation — viite integraatiovaatimusten, päätepisteiden toiminnan ja sovellettavien pyyntörajoitusten tarkistamiseen.
• RFC 6585, Section 4: 429 Too Many Requests — HTTP-rajoitusten semantiikka ja valinnainen Retry-After-ohjeistus.
• RFC 9110, Section 10.2.3: Retry-After — HTTP-päivämäärä- ja viive-sekunteina-muodot.
• RFC 9110, Section 9.2.2: Idempotent Methods — uudelleenyrityksiä koskevat näkökohdat, kun pyynnön tulos on epävarma.