Afklar opgave og beslutning
Denne vejledning gør webhooks og batchbehandling til et arbejdsflow, der kan gennemgås. Det forbinder domænebeslutninger, ejerskab, beviser og accept, så resultatet fortsætter med at fungere i produktionen.
Vælg synkron, webhook eller batchlevering fra volumen, latency, genforsøg og operationelt ejerskab.
Praktisk arbejdsgang
- 1
Beholdningskildetyper, identifikatorer, felter, lokaliteter, ejere og udgivelsestilstande.
- 2
Vælg leveringsmønsteret fra volumen, latens, redaktionel kontrol og fejltolerance.
- 3
Tilknyt kildeposten til en separat sprogversionspost med holdbar kobling.
- 4
Tilføj godkendelse, idempotens, forsøg igen, cache-invalidering, logning og adgangskontrol.
- 5
Testpublikation, kildeændringer, utilgængelige resultater, rollback, tastaturbetjening og overvågning før udgivelse.
Eksempel eller værktøj
Et livscyklusdiagram bliver en implementeringskontrakt for genforsøg, idempotens, overvågning og genafspilning. I værktøjet skal du også registrere basislinje, ejer, beslutning, bevis, åbent spørgsmål og godkendelsesdato. Brug en rigtig side eller transaktion, så teamet ser afhængigheder, undtagelser og vedligeholdelsesarbejdet, der følger efter udgivelsen.
| Beslutningspunkt | Optag | Acceptkriterium |
|---|---|---|
| Baseline | Observeret nuværende tilstand | Kilde og dato registreret |
| Beslutning | Valgt mulighed og begrundelse | Risiko og publikum taget i betragtning |
| Beviser | Test, dokumenter eller mål | Gennemgåbar og versionsspecifik |
| Godkendelse | Navn, rolle og dato | Alle obligatoriske kriterier opfyldt |
Vælg levering fra latenstid, volumen og ejerskab
Brug synkron levering til små interaktive anmodninger, der normalt gennemføres inden for grænseflade-timeoutet og kan rapportere et resultat med det samme. Brug webhooks, når arbejdet er asynkront, men hvert resultat skal ind i CMS, så snart det er klar. Brug batchbehandling til store planlagte indsamlinger, kontrolleret import eller migrering, hvor gennemløb og reproducerbarhed betyder mere end øjeblikkelig levering. Mønstrene kan eksistere side om side, men hver indholdsklasse bør have en dokumenteret standard.
Estimer dagligt og spidsvolumen, varestørrelse, acceptabel færdiggørelsestid, genforsøgsvindue, bestillingskrav, anmelderkapacitet og operationel ejer. Et hurtigt resultat har ingen værdi, hvis redaktionskøen ikke kan behandle det. Inkluder upstream- og downstream-grænser: CMS-eksport, API-hastighed, køarbejdere, callback-slutpunkt, databaseskrivning, cache-invalidering og gennemgang af arbejdsbyrden. Vælg det enkleste mønster, der opfylder det komplette servicemål.
| Mønster | Brug hvornår | Væsentlig kontrol |
|---|---|---|
| Synkron | Lille anmodning og kort begrænset latenstid | Timeout med sikker klientforsøg igen |
| Webhook | Uafhængige job skal ankomme med det samme | Signaturbekræftelse og idempotent hændelseshåndtering |
| Batch | Stort kontrolleret sæt og planlagt færdiggørelse | Manifest, kontrolpunkt, forsoning og genafspilning |
Implementer en verificerbar webhook-livscyklus
Accepter kun HTTPS POST, verificer signaturen mod den rå tekst, kontroller tidsstempletolerancen, og afvis ikke-understøttede hændelsesversioner. Gem begivenheds-id'et under en unik begrænsning, før du anvender forretningsændringer. Returner succes efter holdbar modtagelse, og behandl derefter asynkront. En gentagen begivenhed giver succes uden at gentage bivirkningen. Roter signeringshemmeligheder med en overlapningsperiode, og begræns diagnostisk output, så det ikke afslører signaturer eller indhold.
Modeltilstande såsom modtaget, valideret, matchet, anvendt, ignoreret, forsøger igen og mislykkedes. Match resultatet til job-id, kilde-id, kilderevision, landestandard og tilstand. Hvis den aktuelle kilde er nyere, skal du gemme resultatet til revision, men ikke åbne eller erstatte det aktuelle udkast. Håndter begivenheder, der ikke er i orden, efter statslige overgangsregler frem for ankomstordre. Behold et afspilningsværktøj, der kræver en årsag, operatøridentitet og omfang.
- 1
Bekræft transport, rå-body-signatur, tidsstempel, begivenhedstype og kontraktversion.
- 2
Fortsæt med den unikke begivenhed og anerkend holdbar modtagelse.
- 3
Løs opgave og nøjagtig kilderevision, før du ændrer CMS.
- 4
Anvend en idempotent tilstandsovergang og opret udkastet, der kan gennemgås.
- 5
Optag fuldførelsen eller diriger begivenheden til kontrolleret genforsøg og genafspilning.
Gør batches reproducerbare og forenelige
Opret et uforanderligt manifest med batch-id, oprettelsestid, forespørgsel eller udvælgelsesregel, individuelt vare-id, kilderevision, landestandard, tilstand, prioritet og kontrolsum. Frys manifestet før indsendelse, så en senere CMS-forespørgsel ikke kan ændre, hvad batchen betyder. Del det op i afgrænsede bidder, og brug stabile idempotensnøgler til hvert emne. Checkpoint-afslutning efter holdbare skrivninger, så arbejdere kan genoptage uden at starte forfra.
Til sidst afstem indsendte, accepterede, fuldførte, afviste, forældede, mislykkede og bevidst springede elementer. Optællinger skal balancere i forhold til det originale manifest, og hver ikke-fuldførte post skal have en årsag og næste handling. Genafspilning af et undersæt skaber et nyt genafspilningsmanifest, der er knyttet til originalen. Ændre ikke de oprindelige optællinger eller slet fejlbehæftede beviser. Udgiv kun batchresultater i gennemgangstilstande med arbejdsbelastningsgrænser, der beskytter redaktionen.
Manifestet retter elementidentitet, kilderevision, indstillinger og kontrolsum.
Hver elementoperation er idempotent og kan gentages uafhængigt.
Kontrolpunkter genoptages efter afbrydelse uden at duplikere udkast.
Slutstatustæller stemmer nøjagtigt overens med manifestet.
Genafspilning er scoped, autoriseret, linket og kan revideres.
Overvåg køer og øv genopretning
Overvåg accepteret frekvens, fuldførelsesrate, fejlrate efter kategori, kødybde, alder for ældste vare, percentiler for behandlingsvarighed, webhook-bekræftelsesfejl, genforsøgstælling, antal døde bogstaver, forældet resultatrate og tid fra resultat til redaktionel godkendelse. Advarsel om brugerpåvirkning og voksende efterslæb i stedet for isolerede forbigående fejl. Dashboards adskiller udbyderbehandling, tilbagekaldslevering, CMS-applikation og redaktionel ventetid.
Runbook identificerer ejere, sikker pause, skaleringsgrænser, rotation af legitimationsoplysninger, genafspilningsgodkendelse, håndtering af døde bogstaver, udbyderkommunikation og gendannelsesverifikation. Udøv mistet tilbagekald, gentagen hændelse, ude af drift hændelse, udbyderafbrydelse, CMS-udfald, skemamismatch, udløbet hemmelighed og delvis batchafslutning. Accept kræver gendannelse uden duplikatudgivelse, stille tab, manuel databaseredigering eller fjernelse af det sidst godkendte indhold.
Roller, beviser og godkendelse
Hold generation adskilt fra udgivelse. Et vellykket svar er et udkast, ikke en godkendelse. Gem kilde-id'et og -versionen, transformationsindstillinger, resultat-id'er, gennemgangstilstand, godkender og udgivelsestid. Når kilden ændres, skal du markere sprogversionen til gennemgang i stedet for lydløst at erstatte godkendt indhold. Dette gør rollback og revision mulig på tværs af platforme.
Drift og vedligeholdelse
Værket slutter ikke ved udgivelsen. Knyt sprogversionen eller konfigurationen til dens kilde, overvåg kvalitets- og servicemål, og definer konkrete gennemgangsudløsere. Triggere omfatter kildeændringer, juridiske ændringer, nye publikumsbehov, tilbagevendende supportspørgsmål, tekniske ændringer og hændelser. En navngivet ejer evaluerer udløseren, åbner en ny revision, når det er nødvendigt, og registrerer fornyet godkendelse.
Tjekliste før udgivelse
Integrationen bruger holdbare kildeidentifikatorer.
Legitimationsoplysninger gemmes på serversiden og roteres.
Timeout, genforsøg og hastighedsbegrænsningsadfærd er defineret.
Gentagne anmodninger er idempotente.
Genereret indhold går ind i en anmeldelsestilstand.
Kildeændringer ugyldiggør eller genåbner versionen.
Sprognavigation fungerer ved hjælp af tastatur og hjælpeteknologi.
Overvågning dækker fejl, køer, latens og forældet indhold.