Pouzdani sustavi nisu oni koji se savršeno ponašaju na dijagramu. To su oni koji nastavljaju ostvarivati korisne rezultate kada se redovi čekanja gomilaju, ovisnost uspori, implementacija se preklopi sa stvarnim prometom ili se dva dijela aplikacije nakratko ne slažu oko trenutačnog stanja.

U tom raskoraku između namjeravanog dizajna i onoga što se doista događa u produkciji živi emergentno ponašanje. Primamljivo ga je smatrati neuspjehom arhitekture: nešto iznenađujuće mora značiti da je nešto loše dizajnirano. U pozadinskim sustavima ta je pretpostavka prejednostavna. Emergentno ponašanje neizbježno je čim neovisne komponente međusobno djeluju pod opterećenjem, uz ponovne pokušaje, djelomične kvarove, predmemoriranje i istodobna pisanja.

Praktični cilj nije ukloniti emergenciju. Cilj je oblikovati je u ponašanje koje je sigurno, vidljivo i oporavljivo.

Arhitektura je skup interakcija, a ne dijagram stoga

Tipična PHP usluga može izgledati jednostavno: HTTP zahtjev stiže do aplikacije, aplikacija poziva API, čita ili zapisuje u bazu podataka i vraća odgovor. Ipak, svaki korak ima vlastito vrijeme izvršavanja, način kvara i politiku ponovnih pokušaja. Dodajte Docker orkestraciju, predmemoriju, pozadinskog radnika i više instanci aplikacije, pa lokalne odluke počinju utjecati na cijeli sustav.

Primjerice, klijentu istekne vrijeme dok se zahtjev za plaćanje još obrađuje. Klijent ponovno pokušava. Uravnoteživač opterećenja šalje ponovljeni pokušaj drugom PHP spremniku. Oba zahtjeva dosežu istu granicu transakcije baze podataka u neznatno različitim trenucima. Ako krajnja točka nije idempotentna, jedna radnja korisnika može stvoriti dvije naplate, dvije e-poruke ili dvije narudžbe.

Nijedna pojedinačna komponenta ne mora nužno biti pokvarena. Dvostruki ishod proizlazi iz razumnog ponašanja na svakom sloju. Rješenje je arhitektonsko: učinite operaciju sigurnom za ponavljanje i svakom sloju pružite dovoljno konteksta da prepozna isti logički zahtjev.

Dizajnirajte za sigurno ponavljanje

Ponovni pokušaji nisu rubni slučaj. Mreže otkazuju, radnici se ponovno pokreću, potrošači primaju istu poruku više puta, a korisnici osvježavaju stranice. Svaka operacija koja mijenja trajno stanje trebala bi biti dizajnirana imajući na umu ponavljanje.

API može prihvatiti ključ idempotentnosti koji dostavlja pozivatelj i pohraniti dovršeni rezultat uz taj ključ. Ključ mora biti zaštićen jedinstvenim ograničenjem baze podataka; sama provjera postojećeg retka u kodu aplikacije ranjiva je na istodobne zahtjeve.

CREATE TABLE api_requests (
    id BIGINT PRIMARY KEY,
    idempotency_key VARCHAR(255) NOT NULL,
    response_code INT NULL,
    response_body JSON NULL,
    UNIQUE KEY api_requests_idempotency_key (idempotency_key)
);

Točna shema razlikovat će se, ali načelo je važno: neka baza podataka provodi invarijantu koja mora preživjeti više PHP procesa. Pri dvostrukom ključu aplikacija može učitati pohranjeni rezultat ili prijaviti da je obrada još u tijeku. Takvo je ponašanje korisnije od pretvaranja da istek vremena znači da se ništa nije dogodilo.

Držite nuspojave iza trajne granice

Ažuriranja baze podataka i vanjske nuspojave posebno su opasni zajedno. Ako se narudžba potvrdi, a proces se sruši prije objavljivanja odgovarajućeg događaja, nizvodni sustavi nikada neće saznati za nju. Ako se događaj objavi prvi, a transakcija se poništi, saznat će za narudžbu koja ne postoji.

Obrazac izlaznog spremnika rješava to tako da pohranjuje promjenu domene i zapis događaja u istoj transakciji baze podataka. Zaseban radnik objavljuje događaje na čekanju i označava ih isporučenima tek nakon uspješne objave. Sam radnik trebao bi pretpostaviti isporuku barem jednom, što znači da i potrošači trebaju idempotentnost.

To nije nepotrebna ceremonija. Pretvara neizvjestan problem vremena izvršavanja u eksplicitan, provjerljiv automat stanja.

Učinite načine kvara vidljivima u API ugovoru

Mnogi krhki sustavi otkazuju zato što njihovi ugovori podrazumijevaju sigurnost koju implementacija ne može pružiti. Sinkrona krajnja točka koja pokreće nekoliko udaljenih poziva ne može pošteno jamčiti trenutačan konačni odgovor u svim uvjetima kvara.

Za rad koji može biti spor ili ovisiti o nepouzdanim uslugama vratite prihvaćeni zahtjev s trajnim identifikatorom operacije. Omogućite klijentima da upitaju njegov status ili prime povratni poziv ondje gdje je taj model prikladan. Važna je razlika između „zahtjev je primljen” i „zatraženi poslovni ishod je dovršen”.

• Koristite vremenska ograničenja za odlazne pozive; nepostojanje vremenskog ograničenja nije otpornost.
• Ponovno pokušavajte samo kvarove koji mogu uspjeti pri drugom pokušaju.
• Ograničite broj ponovnih pokušaja i dodajte odgodu kako preopterećena ovisnost ne bi bila dodatno opterećena.
• Očuvajte ID-ove korelacije kroz HTTP zahtjeve, zapisnike, poruke reda čekanja i zadatke radnika.
• Vraćajte pogreške koje razlikuju neispravan unos, privremenu nedostupnost i prihvaćeni asinkroni rad.

Prekidač strujnog kruga ili ograničenje konkurentnosti mogu biti vrijedni kada se ovisnost pogoršava, ali treba ih odabrati za poznati način kvara. Generička biblioteka za otpornost ne zamjenjuje jasno razumijevanje koji zahtjevi mogu biti odgođeni, odbačeni, ponovno pokušani ili stavljeni u red čekanja.

Neka baza podataka nosi invarijante

Kod aplikacije izvrstan je za izražavanje radnih tijekova. Baze podataka bolje štite činjenice koje moraju ostati istinite pri istodobnom izvršavanju. Jedinstvena ograničenja, strani ključevi, ograničenja provjere gdje su podržana i primjereno ograničene transakcije arhitektonski su alati, a ne samo pojedinosti pohrane.

Razmotrite zalihe. Čitanje količine zaliha u PHP-u, oduzimanje jedne jedinice i ponovno zapisivanje može dovesti do prekomjerne prodaje kada se zahtjevi nadmeću. Uvjetno ažuriranje često je sigurnije jer baza podataka procjenjuje dostupnu količinu u trenutku izmjene.

UPDATE inventory
SET available = available - 1
WHERE product_id = :product_id
  AND available > 0;

Ako nijedan red nije ažuriran, aplikacija zna da nijedna zaliha nije rezervirana. Rezultat je deterministički čak i kada mnogi spremnici aplikacije istodobno obrađuju zahtjeve. Za složenije radne tijekove mogu biti prikladne transakcije i zaključavanje na razini retka, ali trebali bi ostati kratki. Duge transakcije pretvaraju uobičajeno opterećenje u sukob oko zaključavanja i kaskadne istekove vremena.

Spremnici mijenjaju granice kvara, a ne sam kvar

Docker čini implementaciju ponovljivom, ali ponovno pokretanje spremnika i dalje je ponovno pokretanje. PHP radnici mogu biti prekinuti između primanja posla i njegova dovršetka. Datoteke zapisane unutar spremnika mogu nestati zajedno sa spremnikom. Varijable okruženja mogu biti pogrešno konfigurirane. Provjere stanja mogu prijaviti da je proces živ dok su njegove veze s bazom podataka iscrpljene.

Gradite usluge kao zamjenjive procese. Držite trajno stanje u upravljanoj pohrani, lokalni disk tretirajte kao privremen osim ako nije izričito montiran i sigurnosno kopiran te učinite pokretanje sigurnim za ponavljanje. Migracije baze podataka zaslužuju posebnu pažnju: implementirajte kod koji može podnijeti i staru i novu shemu prije uklanjanja starih stupaca ili ponašanja.

Prozori kompatibilnosti često su manje glamurozni od rada na značajkama, ali upravo oni omogućuju postupne implementacije bez pretvaranja svakog izdanja u koordinirani događaj.

Promatrajte ponašanje za koje očekujete da će se pojaviti

Metrike i zapisnici trebaju odgovarati na operativna pitanja, a ne samo potvrđivati da proces postoji. Pratite latenciju zahtjeva i stope pogrešaka po krajnjoj točki, dubinu i starost reda čekanja, zasićenost veza s bazom podataka, kvarove odlaznih ovisnosti te stopu ponovnih pokušaja ili obrade dvostrukih poruka.

Strukturirani zapisnici s identifikatorima zahtjeva i korelacije omogućuju praćenje jedne operacije kroz PHP-FPM ili dugotrajne radnike, potrošače reda čekanja i vanjske pozive. Zapisnici bez konteksta postaju zbirka anegdota; tragovi bez smislenih naziva operacija postaju skup labirint.

Najvažnije, upozoravajte na simptome koje korisnici doživljavaju: trajne kvarove, rastući zaostatak, iscrpljeni kapacitet ili rad koji ostaje nedovršen dulje od prihvatljivog intervala. Kratak porast ponovnih pokušaja može biti zdrav. Red čekanja koji nikada ne sustigne nije.

Otpornost proizlazi iz kontroliranih posljedica

Emergentno ponašanje ne može se ukloniti dizajnom jer se stvarni sustavi sastoje od neovisnih dijelova s nesavršenim informacijama. Ono što arhitektura na višoj razini može učiniti jest ograničiti posljedice: dvostruki zahtjevi postaju jedna logička operacija, prekinuti rad postaje rad koji se može nastaviti, odgođene ovisnosti postaju vidljiv zaostatak, a promjene sheme postaju kompatibilni prijelazi.

Najjači pozadinski sustavi nisu oni koji pretpostavljaju da će svaki sloj savršeno surađivati. To su oni koji unaprijed odlučuju što se događa kada se to ne dogodi — i čine taj ishod dosadnim, sigurnim i lakim za popravak.