Faqja kryesoreBlogShkallëzueshmëria e API-së së gjurmimit: Si të përballoni volumin e sezonit të pikut, kufizimet e tarifës dhe regjistrimin në masë

Shkallëzueshmëria e API-së së gjurmimit: Si të përballoni volumin e sezonit të pikut, kufizimet e tarifës dhe regjistrimin në masë

17TRACK

Për të shkallëzuar një API gjurmimi për sezonin e pikut, vendosni regjistrimin e dërgesave pas një radhe të qëndrueshme, zbatoni kufijtë e ofruesit në të gjithë punonjësit, përdorni grupe vetëm brenda kufijve të dokumentuar dhe përpunoni përditësimet e gjurmimit në mënyrë asinkrone. Trajtojeni kapacitetin e regjistrimit, trafikun e riprovimeve dhe përpunimin e webhook-eve si probleme të veçanta kapaciteti. Shtimi i më shumë punonjësve pa kontrolluar kërkesat dalëse mund të rrisë kufizimin e trafikut në vend që të zbrazë ngarkesën tuaj.

Shkallëzueshmëria e API-së së gjurmimit: Si të përballoni volumin e sezonit të pikut dhe normën

Për ekipet inxhinierike që lidhin një sistem menaxhimi porosish, platformë magazine ose backend ecommerce me një shërbim gjurmimi, qëllimi nuk është thjesht të dërgohen më shumë kërkesa. Qëllimi është të regjistrohen dërgesat brenda një afati të përcaktuar, të ruhen përditësimet gjatë rritjeve të trafikut dhe të rikuperohen dështimet pa krijuar punë të dyfishtë.

Dimensiononi ngarkesën rreth dërgesave, kërkesave dhe përditësimeve

Volumi ditor i dërgesave nuk mjafton për të dimensionuar një integrim. Një magazinë mund të lëshojë shumicën e numrave të gjurmimit në një interval të shkurtër dërgimi, ndërsa përditësimet e statusit mbërrijnë gjatë gjithë ditës. Modelojini këto ngarkesa veçmas.

  • Mbërritjet e regjistrimeve: Regjistrimet e reja të dërgesave që hyjnë në sistemin tuaj për sekondë ose minutë, duke përfshirë importet dhe shpërthimet e lëshimeve nga magazina.
  • Trafiku dalës i API-së: Kërkesat për regjistrim, kërkimet, korrigjimet, thirrjet e rakordimit dhe riprovimet.
  • Trafiku hyrës i përditësimeve: Dërgesat dhe ridërgesat e webhook-eve, kur ofruesi i mbështet ato.
  • Puna pasuese: Shkrimet në bazën e të dhënave, njoftimet e klientëve, ngjarjet analitike dhe ndryshimet e statusit të porosisë të shkaktuara nga çdo përditësim.

Vendosni një objektiv të brendshëm regjistrimi, si koha maksimale e pranueshme midis marrjes së një numri gjurmimi dhe konfirmimit të regjistrimit të tij. Mbajeni këtë të ndarë nga freskia e gjurmimit: regjistrimi i suksesshëm nuk do të thotë se skanimi i transportuesit është tashmë i disponueshëm.

Llogaritni kapacitetin efektiv të regjistrimit

Për një endpoint regjistrimi të kufizuar nga kërkesat, një marrëdhënie e dobishme planifikimi është:

Kapaciteti i regjistrimit = kërkesa të lejuara për sekondë × regjistrime mesatare për kërkesë × fraksioni i regjistrimeve të suksesshme

Ky është një vlerësim planifikimi, jo një garanci e ofruesit. Ai supozon se kufijtë e kërkesave janë kufizimi kryesor. Kuotat e bazuara në regjistrime, madhësia e ngarkesës, vonesa dhe kufijtë e përbashkët të llogarisë mund të vendosin një tavan më të ulët.

Vetëm për ilustrim, supozoni se një integrim lejohet të bëjë dy kërkesa regjistrimi për sekondë dhe dërgon mesatarisht 30 regjistrime në çdo kërkesë. Kapaciteti nominal është 60 regjistrime për sekondë përpara dështimeve dhe kufizimeve të tjera. Nëse regjistrimet hyrëse janë mesatarisht 80 regjistrime për sekondë gjatë një shpërthimi të qëndrueshëm, radha rritet me rreth 20 regjistrime për sekondë. Këto shifra janë hipotetike, jo kufij të 17TRACK.

Llogaritni gjithashtu kapacitetin e rikuperimit. Nëse mbërritjet e reja vazhdojnë me normën λ dhe kapaciteti efektiv i përpunimit është μ, një ngarkesë ekzistuese prej B regjistrimesh kërkon afërsisht B / (μ − λ) sekonda për t'u zbrazur kur μ > λ. Nëse kapaciteti i përpunimit nuk e tejkalon normën e mbërritjeve, ngarkesa nuk do të pastrohet në këto kushte.

Konfirmoni se çfarë kufizon realisht ofruesi

Një kufi norme dhe një lejim përdorimi zgjidhin probleme të ndryshme. Kufiri i normës kontrollon sa shpejt mund të dërgohen kërkesat ose regjistrimet. Një lejim përdorimi mund të kontrollojë sa aktivitet gjurmimi mund të konsumojë një llogari gjatë një periudhe faturimi ose të drejtash përdorimi. Qëndrimi nën njërin nuk dëshmon pajtueshmërinë me tjetrin.

Para se të vendosni numrin e punonjësve, konfirmoni sa vijon kundrejt dokumentacionit të ofruesit dhe kushteve të llogarisë suaj:

  • Nëse kufijtë zbatohen për llogari, çelës API, endpoint, adresë IP ose një fushë tjetër.
  • Nëse njësia e numëruar është një kërkesë, regjistrim gjurmimi ose operacion tjetër.
  • Nëse endpoint-et ndajnë një kufi ose kanë lejime të pavarura.
  • Numri maksimal i regjistrimeve dhe madhësia e ngarkesës së lejuar në një kërkesë.
  • Si ndikojnë dërgimet e dyfishta, regjistrimet e pavlefshme dhe riprovimet në përdorim.
  • Nëse përgjigjet shfaqin informacion për kufizimin e trafikut ose udhëzime për riprovim.
  • Si ndryshon shterimi i kuotës nga kufizimi i përkohshëm i trafikut.

Për një integrim me 17TRACK, përdorni faqen zyrtare të Tracking API dhe dokumentacionin e API-së si pikënisje për këtë konfigurim. Konfirmoni sjelljen e endpoint-it përkatës dhe kufijtë e llogarisë përpara vendosjes në prodhim. Kapacitetet shembull në këtë udhëzues janë ilustrime arkitekturore, jo deklarime për të drejtat e përdorimit, madhësitë e grupeve ose garancitë e shërbimit të 17TRACK.

Vendosni një radhë të qëndrueshme midis përpunimit të porosive dhe regjistrimit

Mos e bëni përfundimin e blerjes ose të punës së magazinës të presë që një ofrues gjurmimi të pranojë një regjistrim. Ruajeni dërgesën lokalisht, regjistroni detyrën e regjistrimit në mënyrë të qëndrueshme dhe lejojuni punonjësve në sfond të trajtojnë dërgimin.

Një rrjedhë praktike është:

  1. Ruani dërgesën dhe qëllimin e saj të regjistrimit. Përdorni një transactional outbox ose një dizajn ekuivalent për të shmangur ruajtjen e porosisë ndërsa humbet detyra në sfond.
  2. Vlerësoni dhe normalizoni hyrjet. Ruajini numrat e gjurmimit si vargje, duke përfshirë zerot në fillim. Aplikoni normalizim specifik për transportuesin vetëm kur justifikohet.
  3. Kontrolloni për një regjistrim ekzistues. Përdorni një identitet të qëndrueshëm të përshtatshëm për ofruesin dhe modelin tuaj të të dhënave.
  4. Vendosni në radhë regjistrimet e përshtatshme. Ruani numrin e përpjekjeve, kohën e ardhshme të lejueshme për riprovim dhe kontekst të mjaftueshëm për diagnostikim.
  5. Dërgoni përmes një kufizuesi të përbashkët. Merrni kapacitet menjëherë përpara kërkesës dalëse.
  6. Ruani rezultatet në nivel regjistrimi. Ndani suksesin e konfirmuar, dështimin e riprovueshëm, refuzimin e përhershëm dhe rezultatet e paqarta.

Një radhë përthith një shpërthim; ajo nuk krijon kapacitet ofruesi. Nëse regjistrimi më i vjetër i përshtatshëm vazhdon të plaket, hetoni hendekun midis normës së mbërritjeve dhe kapacitetit të përpunimit në vend që të rrisni thjesht numrin e punonjësve.

Koordinoni kufijtë midis punonjësve

Punonjësit e pavarur nuk duhet të supozojnë secili se mund të konsumojë të gjithë lejimin e llogarisë. Përdorni një kufizues të koordinuar norme ose një dispeçer që cakton një buxhet të përbashkët kërkesash. Përfshini importet e planifikuara, skriptet operative dhe punët e rakordimit në këtë buxhet.

Norma dhe njëkohshmëria janë kontrolle të ndryshme. Kufizuesi kontrollon sa shpesh nisin kërkesat; kufiri i njëkohshmërisë kontrollon sa kërkesa mbeten në proces. Të dyja janë të dobishme kur rritet vonesa e ofruesit. Rritja e njëkohshmërisë mund të ndihmojë një ngarkesë të kufizuar nga vonesa, por nuk mund të anashkalojë një kufi të normës dalëse.

Përdorni regjistrimin në grup pa humbur kontrollin në nivel regjistrimi

Kur një endpoint mbështet regjistrime të shumta për kërkesë, grupimi mund të zvogëlojë shpenzimet e kërkesave. Ai nuk zvogëlon domosdoshmërisht përdorimin e bazuar në regjistrime dhe grupi më i madh i lejuar nuk është gjithmonë zgjedhja më e mirë operative.

Ndërtoni grupe duke përdorur dy nxitës: një numër maksimal regjistrimesh dhe një kohë maksimale pritjeje. Dërgojini kur arrihet cilido prej tyre. Kjo lejon që periudhat me ngarkesë të mbushin grupet në mënyrë efikase pa i detyruar trafiku me volum të ulët të presë pafundësisht.

  • Respektoni kufijtë e ngarkesës, si dhe numrin e regjistrimeve. Metadatat opsionale mund t'i bëjnë grupet me të njëjtën madhësi shumë të ndryshme në bajte.
  • Mbani një manifest të brendshëm të grupit. Regjistroni cilat identitete lokale të dërgesave u dërguan dhe lidhni saktë çdo rezultat të kthyer.
  • Kontrolloni rezultatet në nivel aplikacioni. Një përgjigje e suksesshme HTTP nuk provon vetvetiu se çdo regjistrim u pranua.
  • Riprovoni vetëm regjistrimet që kanë nevojë për riprovim. Ridërgimi i regjistrimeve të suksesshme krijon trafik të panevojshëm dhe mund të ketë pasoja në përdorim.
  • Dërgoni dështimet e përhershme të validimit për korrigjim. Një ngarkesë e pavlefshme dhe e pandryshuar nuk duhet të qarkullojë në radhën e riprovimeve.

Një skadim kohe është veçanërisht i rëndësishëm: ofruesi mund ta ketë pranuar kërkesën edhe pse klienti juaj nuk e mori përgjigjen. Shënojeni atë rezultat si të paqartë. Zgjidheni përmes një mekanizmi të mbështetur idempotence, një rregulli të dokumentuar për regjistrimet e dyfishta ose një kërkimi rakordimi kur është i disponueshëm. Mos supozoni se një shkrim të cilit i ka skaduar koha ka dështuar.

Ndani trafikun aktiv nga importet historike

Një mbushje historike nuk duhet të konsumojë të gjithë kapacitetin e nevojshëm për dërgesat e reja. Përdorni radha të veçanta me planifikim të ponderuar ose rezerva të qarta kapaciteti. Lejojini importet të përdorin kapacitetin e lirë duke ruajtur një alokim minimal për regjistrimet aktive. Aplikoni plakjen ose një rregull tjetër drejtësie në mënyrë që regjistrimet me përparësi më të ulët të përpunohen përfundimisht.

Bëjini riprovimet të kontrolluara, të vonuara dhe të kufizuara

HTTP 429 do të thotë “Too Many Requests”. RFC 6585 specifikon se një përgjigje 429 mund të përfshijë një kokë Retry-After. RFC 9110 përcakton se vlera e asaj koke është ose një datë HTTP ose një vonesë në sekonda. Klienti duhet të analizojë të dyja format, në vend që të supozojë se gjithmonë kthehet një numër i plotë.

Kur jepet një vonesë e vlefshme riprovimi, mos riprovoni para skadimit të saj. Kur mungojnë udhëzimet për riprovim, përdorni backoff eksponencial të kufizuar me jitter: rriteni gradualisht vonesën midis përpjekjeve dhe shtoni rastësi në mënyrë që punonjësit të mos riprovojnë të gjithë së bashku. Riprovimet duhet të kalojnë përmes të njëjtit kufizues dalës si përpjekjet e para.

Klasifikoni dështimet përpara riprovimit:

  • Kufizimi i trafikut: Vononi punën e prekur dhe ulni presionin e dërgimit brenda fushës përkatëse të kufirit.
  • Dështimet kalimtare të rrjetit ose serverit: Riprovoni brenda një politike të kufizuar, duke llogaritur rezultatet e paqarta të shkrimit.
  • Dështimet e autentikimit ose autorizimit: Sinjalizoni dhe ndaloni punën e prekur derisa të korrigjohen kredencialet ose lejet.
  • Dështimet e validimit: Korrigjojeni ose izolojeni regjistrimin në vend që ta ridërgoni të pandryshuar.
  • Lejimi i shteruar: Ndiqni zgjidhjen e dokumentuar për llogarinë në vend që ta trajtoni si një shpërthim të shkurtër trafiku.

Vendosni si një kufi përpjekjesh, ashtu edhe një moshë maksimale riprovimi. Zhvendosini artikujt e shteruar në një radhë dead-letter me një arsye, pronësi dhe procedurë riluajtjeje. Përndryshe, dështimet e vjetra mund të konsumojnë në heshtje kapacitetin e destinuar për dërgesat e reja.

Shkallëzoni në mënyrë të pavarur marrjen e webhook-eve

Kur ofruesi ofron webhook-e të përshtatshme, ato mund të zvogëlojnë kërkimet e përsëritura të statusit. Ato krijojnë gjithashtu një ngarkesë hyrëse të veçantë që duhet të mbetet e disponueshme gjatë shpërthimeve të përditësimeve.

Mbajeni endpoint-in pritës të fokusuar: validoni kërkesën duke përdorur mekanizmin e dokumentuar të ofruesit, ruajeni ngjarjen në mënyrë të qëndrueshme dhe ktheni konfirmimin e kërkuar. Përpunoni ndryshimet e porosive, analitikën dhe mesazhet e klientëve në mënyrë asinkrone. Mos e konfirmoni marrjen përpara pranimit të qëndrueshëm nëse kjo do të rrezikonte humbjen e ngjarjes.

Dizajnojini konsumatorët që të tolerojnë dërgesat e dyfishta, përveçse kur kontrata e ofruesit përcakton shprehimisht të kundërtën. Preferoni një identifikues të dokumentuar dhe të qëndrueshëm të ngjarjes për dedublikim. Nëse nuk ekziston, dizenjoni dhe testoni me kujdes një identitet të përbërë: përdorimi vetëm i një etikete statusi mund të bashkojë ngjarje të ndryshme në një të vetme.

Mbroni gjithashtu kundër përditësimeve jashtë rendit. Ruajeni historikun e ngjarjeve veçmas nga gjendja aktuale e nxjerrë e dërgesës. Aplikoni vulat kohore të dokumentuara të ngjarjeve dhe rregullat e tranzicionit kur janë të disponueshme; mos supozoni se rendi i mbërritjes është rendi i ngjarjeve ose se statuset e dërgesës formojnë një sekuencë universalisht në rritje.

Mbajeni rakordimin të synuar dhe të kufizuar sipas normës. Ai mund të hetojë boshllëqet e dyshuara të dërgesave ose regjistrimet e paqarta, por kërkimi agresiv i çdo dërgese mund të rikrijojë ngarkesën dalëse që webhook-et synonin të shmangnin.

Testoni rikuperimin, jo vetëm shpejtësinë maksimale të përpunimit

Kryeni teste ngarkese ndaj komponentëve tuaj duke përdorur një simulator ofruesi. Koordinoni testet që dërgojnë trafik të konsiderueshëm te një ofrues real dhe qëndroni brenda kufijve të autorizuar. Një test i suksesshëm duhet të tregojë se sistemi kthehet në normalitet pas ndërprerjes, jo vetëm se pranon një shpërthim të madh.

  • Riluani një shpërthim të ngjashëm me atë të magazinës, të ndjekur nga trafik normal i vazhdueshëm.
  • Injektoni përgjigje kufizimi trafiku, vonesë të rritur dhe dështime të përkohshme të serverit.
  • Simuloni refuzim të pjesshëm të grupit dhe një skadim kohe pas pranimit në anën e serverit.
  • Dërgoni ngjarje webhook të dyfishta dhe jashtë rendit.
  • Ndërprisni aksesin në bazën e të dhënave dhe verifikoni që ngjarjet e papranuara të mos konfirmohen gabimisht.
  • Kryeni një mbushje historike krahas regjistrimeve aktive dhe kontrolloni drejtësinë.
  • Riluani artikujt dead-letter pa anashkaluar kontrollet e normës.

Monitoroni moshën e regjistrimit më të vjetër të përshtatshëm, vonesën e pranimit, normën e suksesit në nivel regjistrimi, shpeshtësinë e kufizimit të trafikut, volumin e riprovimeve, vonesën e përpunimit të webhook-eve dhe rritjen e dead-letter. Vetëm thellësia e radhës nuk mjafton: një radhë e madhe mund të zbrazet shpejt, ndërsa një radhë e vogël mund të përmbajë disa dërgesa kritike për biznesin që dështojnë vazhdimisht.

Përpara sezonit të pikut, caktoni përgjegjësinë operative. Inxhinieria duhet të zotërojë kontrollet e dërgimit dhe mjetet e rikuperimit; pronari i integrimit duhet të konfirmojë të drejtat e përdorimit te ofruesi; operacionet duhet të përcaktojnë se cilat dërgesa marrin përparësi. Dokumentoni kur të ndaloni importet, të kërkoni kapacitet shtesë ose të hetoni përditësimet që mungojnë. Dizajni më i fortë është ai që mbetet i parashikueshëm kur trafiku tejkalon kapacitetin e tij të menjëhershëm të përpunimit.

Pyetje të shpeshta

A do ta rrisë kapacitetin shtimi i çelësave API?

Jo domosdoshmërisht. Çelësa të shumtë mund të ndajnë të njëjtin lejim në nivel llogarie. Konfirmoni fushën e kufirit dhe mënyrën e lejuar të shkallëzimit me ofruesin. Mos përdorni rotacionin e çelësave për të anashkaluar kufizimet.

A duhet që çdo regjistrim të përdorë grupin më të madh të mundshëm?

Jo. Grupet më të mëdha mund të përmirësojnë efikasitetin e kërkesave, por pritja për t'i mbushur rrit vonesën në volum të ulët. Përdorni një kufi madhësie të dokumentuar së bashku me një kohëmatës dërgimi, pastaj rregullojeni bazuar në vonesën e matur të pranimit dhe sjelljen e dështimeve.

Si mund të parandalohen regjistrimet e dyfishta pas skadimit të kohës?

Përdorni identitetin e qëndrueshëm lokal të dërgesës dhe sjelljen e dokumentuar të ofruesit për idempotence ose trajtimin e dublikatave. Nëse rezultati mbetet i pasigurt, rakordojeni aty ku mbështetet përpara riluajtjes. Dedublikimi lokal vetëm nuk mund të provojë nëse një kërkesë në distancë pati sukses.

A do të thotë regjistrimi i suksesshëm se informacioni i gjurmimit është aktual?

Jo. Pranimi i regjistrimit, disponueshmëria e ngjarjes së transportuesit, përpunimi nga ofruesi dhe përpunimi i përditësimit tuaj janë faza të veçanta. Matini veçmas në mënyrë që një skanim i vonuar i transportuesit të mos ngatërrohet me një ngarkesë regjistrimi.

Kur duhet një ekip të kërkojë më shumë kapacitet nga ofruesi?

Kërkojeni kur mbërritjet e parashikuara dhe koha e kërkuar e rikuperimit tejkalojnë kapacitetin e verifikuar të përdorshëm, pasi të hiqen riprovimet e shmangshme, dërgimet e dyfishta dhe grupimi joefikas. Një lejim më i madh nuk do të rregullojë një konsumator të bllokuar ose një pengesë në bazën e të dhënave, ndaj identifikoni fillimisht kufizimin kryesor.

Burimet

Loading