Okvir može učiniti da PHP aplikacija djeluje dovršeno puno prije nego što postane otporna. Rute su uredne, ovisnosti se umeću, migracije se pokreću i prvo postavljanje uspijeva. Zatim stiže stvarnost: uzvodni API uspori, radnik reda čekanja ponovno se pokrene usred zadatka, upit baze podataka naiđe na podatke veličine produkcijskih ili mala razlika u konfiguraciji pokvari spremnik.

Otpornost je ono što ostaje kada sretni put prestane biti jedini put. Ona nije značajka okvira ni pojedinačni infrastrukturni izbor. Ona je arhitektonska navika: učiniti kvarove razumljivima, ograničiti njihov opseg utjecaja i osigurati da se sustav može oporaviti bez drame.

Koristite okvir kao temelj, a ne kao granicu

Moderni PHP okviri uklanjaju velik dio slučajne složenosti. Pružaju usmjeravanje, validaciju, autentikaciju, redove čekanja, predmemoriranje, apstrakcije baze podataka i smisleno ustrojstvo projekta. To je vrijedno. Pogreška je dopustiti da konvencije okvira postanu cjelokupan dizajn aplikacije.

Poslovna pravila trebala bi biti razumljiva bez čitanja HTTP kontrolera, ORM modela ili konfiguracijske datoteke reda čekanja. Koristan smjer ovisnosti jednostavan je: mehanizmi isporuke pozivaju aplikacijski kod; aplikacijski kod koordinira ponašanje domene; infrastruktura implementira sučelja koja aplikacija treba.

Na primjer, slučaj upotrebe potvrde narudžbe možda treba pohraniti narudžbu i zatražiti autorizaciju plaćanja. Kontroler bi trebao prevesti zahtjev u ulaz za taj slučaj upotrebe, a ne sadržavati pravila određivanja cijena, odluke o transakcijama i pozive API-ja trećih strana u jednoj metodi.

final class ConfirmOrder
{
    public function __construct(
        private OrderRepository $orders,
        private PaymentGateway $payments,
    ) {}

    public function handle(ConfirmOrderCommand $command): Order
    {
        $order = Order::fromCommand($command);

        $this->orders->save($order);

        $this->payments->authorize($order->id(), $order->total());

        return $order;
    }
}

Točni nazivi klasa manje su važni od razdvajanja. Aplikacija se može testirati s lažnim pristupnikom, dok se HTTP sloj, prilagodnik baze podataka i klijent za plaćanje mogu razvijati neovisno. Ovo nije argument za razrađenu ceremoniju u svakoj CRUD krajnjoj točki. Ovo je argument za smještanje složenosti tamo gdje se o njoj može promišljati kada složenost stigne.

Dizajnirajte API-je oko ugovora i neuspjeha

API je obećanje dano u nesavršenim uvjetima. Njegovi oblici odgovora, statusni kodovi, pravila validacije, ponašanje paginacije i format pogrešaka postaju dio proizvoda. Tretiranje toga kao usputnih pojedinosti kontrolera čini kasnije promjene nepotrebno skupima.

Počnite tako da validaciju ulaza učinite eksplicitnom, ali nemojte stati na tome. Klijentima je također potrebno predvidljivo ponašanje kada resursi ne postoje, kada je zahtjev u sukobu s trenutačnim stanjem i kada je ovisnost privremeno nedostupna. Izbjegavajte otkrivanje stogovnih tragova ili sirovih pogrešaka baze podataka. Umjesto toga vratite stabilne, korisne informacije o pogrešci.

{
  "error": {
    "code": "payment_unavailable",
    "message": "Payment authorization is temporarily unavailable."
  }
}

Za operacije koje se mogu ponovno pokušati, idempotentnost zaslužuje ranu pozornost. Klijentu može isteći vrijeme nakon što je poslužitelj već obradio zahtjev. Ponovni pokušaj poziva “create payment” ne smije neprimjetno stvoriti drugo terećenje. Ključ idempotentnosti, pohranjen uz rezultat operacije, daje poslužitelju način da prepozna ponovni pokušaj i vrati izvorni ishod.

Vremenska ograničenja jednako su važna. HTTP klijent bez vremenskog ograničenja zapravo vanjskoj usluzi daje dopuštenje da PHP radnika zauzme na neodređeno vrijeme. Namjerno odaberite vremenska ograničenja, gdje je korisno razlikujte neuspjehe povezivanja od pogrešaka poslužitelja i ponovno pokušavajte samo neuspjehe koji su vjerojatno privremeni. Ponovni pokušaj pogreške validacije je šum; ponovno pokušavanje svakog isteka vremena bez ograničenja može pojačati prekid rada.

Održavajte pristup bazi podataka poštenim

Mnogi problemi s performansama počinju kao ORM kod koji izgleda bezazleno. Relacija učitana unutar petlje pretvara se u desetke ili stotine upita. Širok upit radi lokalno, ali u produkciji pretražuje sve veću tablicu. Transakcija naraste tako da uključuje mrežne pozive i drži zaključavanja puno dulje nego što je potrebno.

Koristite ORM radi produktivnosti, a zatim provjerite njegovo ponašanje kada je zahtjev važan. Pregledajte generirane upite, unaprijed učitajte odnose koji su stvarno potrebni, odaberite samo potrebne stupce i dodajte indekse koji podržavaju stvarne obrasce upita. Indeks nije značka optimizacije; on je struktura podataka s troškovima zapisivanja i pohrane. Dodajte ga zato što ga poznati upit treba.

Transakcije bi trebale štititi malu, koherentnu promjenu stanja. Držite udaljene pozive izvan transakcije baze podataka kad god je moguće. Ako vanjska radnja mora slijediti potvrđenu promjenu, zabilježite outbox događaj u istoj transakciji i obradite ga asinkrono. Taj obrazac sprječava uobičajeni jaz u kojem se baza podataka uspješno potvrdi, ali kasniji pokušaj objave događaja ne uspije.

Učinite asinkroni rad sigurnim za ponavljanje

Redovi čekanja poboljšavaju odzivnost, ali sami po sebi ne čine rad pouzdanim. Zadatak se može pokrenuti više puta, ne uspjeti nakon djelomične nuspojave ili se ponovno pokušati nakon što su se njegove pretpostavke promijenile. Stoga bi rukovatelji redom čekanja trebali biti idempotentni, opažljivi i uskog opsega.

• Koristite trajni identifikator za otkrivanje već dovršenog rada.
• Postavite jasnu politiku ponovnih pokušaja i usmjerite iscrpljene zadatke prema mehanizmu za neuspjehe koji se pregledava.
• Zabilježite dovoljno konteksta za istraživanje bez stavljanja tajni ili osjetljivih sadržaja u zapisnike.
• Neka sadržaji zadataka budu mali i učitajte trenutačno stanje kada se zadatak pokrene.

Spremnici bi trebali smanjiti odstupanja, a ne skrivati ih

Docker je najkorisniji kada razvojna, testna i produkcijska okruženja čini dosljednijima. Slika spremnika trebala bi jasno navesti što joj treba: PHP okruženje za izvođenje, potrebna proširenja, aplikacijski kod i promišljena naredba za pokretanje.

Konfiguracija bi trebala dolaziti iz okruženja, uz validaciju pri pokretanju za vrijednosti bez kojih aplikacija ne može raditi. Nemojte dopustiti da nedostajući URL baze podataka proizvede nejasnu pogrešku tek nakon prvog zahtjeva. Provjera konfiguracije s brzim neuspjehom pretvara operativnu zagonetku u provediv neuspjeh postavljanja.

Gradite slike reproducibilno gdje je praktično, izbjegavajte stavljanje alata samo za razvoj u produkcijsku sliku i pokrećite aplikaciju s najmanjim privilegijama kompatibilnima s njezinim potrebama. Cilj nije učiniti Dockerfile vizualno sofisticiranim. Cilj je učiniti postavljeni artefakt predvidljivim.

Promatrajte ponašanje kojim namjeravate upravljati

Zapisnici, metrike i provjere zdravlja arhitektonski su alati jer oblikuju brzinu kojom tim može razumjeti sustav uživo. Strukturirani zapisnici s identifikatorom zahtjeva ili korelacije omogućuju praćenje jedne operacije kroz kontrolere, zadatke i pozive usluga. Provjere zdravlja trebale bi razlikovati “proces je pokrenut” od “aplikacija može poslužiti koristan promet”, bez pretvaranja svakog prolaznog problema ovisnosti u petlju ponovnog pokretanja.

Dobra opažljivost također informira odluke o dizajnu. Ako se spora krajnja točka ne može pripisati upitu, promašaju predmemorije ili udaljenoj ovisnosti, njezino poboljšanje postaje nagađanje. Instrumentirajte granice na kojima su vrijeme, neuspjesi i upotreba resursa važni.

Otpornost je disciplinirana jednostavnost

Najjače PHP aplikacije rijetko su one s najviše obrazaca. To su one čije su granice jasne, čije operacije mogu sigurno ne uspjeti i čije ponašanje ostaje čitljivo pod pritiskom.

Najprije izgradite jednostavnu verziju, a zatim ojačajte mjesta na kojima se podaci mijenjaju, vanjski sustavi međusobno djeluju i ponovni pokušaji postaju mogući. Poslovnu logiku držite dovoljno neovisnom za testiranje, rad s bazom podataka dovoljno namjernim za skaliranje i pretpostavke postavljanja dovoljno eksplicitnima za provjeru. Okvir može ubrzati taj rad. Arhitektura je ono što osigurava da aplikacija nastavi zasluživati tu brzinu nakon prvog izdanja.