PHP se često procjenjuje prema najmanje discipliniranom kodu napisanom u njemu. To je čudan standard za jezik koji jednako učinkovito može pokretati čist API, zahtjevan transakcijski tijek rada i dobro zaokruženu uslugu, kao i zapetljanu skriptu.

Pravo pitanje nije može li se PHP skalirati. Pitanje je je li pozadinski sustav dizajniran da elegantno otkazuje, sigurno se razvija i da se uobičajeni put lako održava. To su arhitekturni problemi. PHP na njih nudi posebno praktičan odgovor: gradite oko jasnih granica, oslanjajte se na jednostavnu infrastrukturu i održavajte operativnu složenost razmjernom problemu.

Započnite s granicama, a ne okvirima

Okvir može ubrzati isporuku, ali ne bi smio postati mjesto na kojem živi svaka poslovna odluka. Najotpornije PHP aplikacije rano odvajaju odgovornosti: obrada HTTP-a, slučajevi upotrebe aplikacije, domenska pravila i integracija infrastrukture trebaju imati zasebne odgovornosti.

Kontroler treba prevesti zahtjev u poziv aplikacijskom sloju i rezultat ponovno prevesti u odgovor. Ne bi trebao sadržavati pravila određivanja cijena, petlje ponovnih pokušaja ni izravne upite prema bazi podataka. Ta se suzdržanost isplati kada isti slučaj upotrebe kasnije treba pokrenuti iz radnika reda čekanja, zadatka naredbenog retka ili drugog API-ja.

final class CreateOrderController
{
    public function __invoke(CreateOrderRequest $request): JsonResponse
    {
        $order = $this->createOrder->handle(
            new CreateOrderCommand(
                customerId: $request->customerId(),
                items: $request->items()
            )
        );

        return new JsonResponse(['id' => $order->id()], 201);
    }
}

Korisna granica ovdje nije sam kontroler. To su CreateOrderCommand i slučaj upotrebe koji stoji iza njega. To sustavu daje stabilno središte, dok se web rute, potrošači reda čekanja i implementacije baze podataka mogu mijenjati na rubovima.

Dizajnirajte API-je za nesavršene mreže

Inženjeri pozadinskih sustava velik dio vremena provode rješavajući uvjete koje zanemaruje sretan put: klijenti ponovno pokušavaju zahtjeve, veze se neočekivano zatvaraju, a ovisne usluge odgovaraju sporo. Pouzdan API to priznaje od samog početka.

Za operacije koje stvaraju resurs ili pokreću vanjski sporedni učinak, podržite idempotentnost ondje gdje je važna. Klijent koji nakon isteka vremena ponovno pokuša zahtjev povezan s plaćanjem ne smije slučajno stvoriti dvije naplate. Ključ idempotentnosti, pohranjen s ishodom izvornog zahtjeva, omogućuje poslužitelju da vrati isti rezultat za ekvivalentan ponovni pokušaj.

Pogreške validacije trebaju biti jasne i strukturirane. Neuspjesi autentikacije i autorizacije trebaju biti razlikovni. Neočekivani neuspjesi ne bi smjeli otkrivati pojedinosti implementacije. Dosljedni oblici odgovora pomažu pozivateljima da izgrade pouzdano ponašanje bez obrnutog inženjeringa svakog krajnjeg odredišta.

• Koristite odgovarajuće statusne kodove, ali učinite i tijelo odgovora korisnim.
• Postavite izričita vremenska ograničenja za izlazne HTTP pozive.
• Pokušavajte ponovno samo neuspjehe koji su vjerojatno privremeni.
• Koristite ograničene ponovne pokušaje s odgodom; neograničeni ponovni pokušaji pretvaraju prolazni problem u problem resursa.
• Zabilježite identifikator korelacije kako bi se jedan zahtjev mogao pratiti kroz zapise i asinkroni rad.

Ponovni pokušaji zaslužuju posebnu pažnju. Ponovno pokušavanje sigurnog čitanja nakon kratkog prekida veze može biti razumno. Ponovno pokušavanje neidempotentnog pisanja bez strategije uklanjanja duplikata može biti opasno. „Pokušaj ponovno” nije strategija otpornosti osim ako to podržava semantika operacije.

Neka baza podataka provodi važne istine

Aplikacijski kod treba izražavati poslovna pravila, ali baza podataka treba štititi invarijante koje moraju vrijediti pri konkurentnom izvršavanju. Ako adresa e-pošte mora biti jedinstvena, upotrijebite jedinstveno ograničenje. Ako podređeni zapis ne može postojati bez nadređenog, upotrijebite strani ključ kada ga podatkovni model podržava. Ako nekoliko promjena mora zajedno uspjeti ili ne uspjeti, upotrijebite transakciju.

PHP obrađivači zahtjeva često su kratkotrajni, što može olakšati podcjenjivanje konkurentnosti. Dva zahtjeva i dalje mogu pročitati istu dostupnu zalihu i oba pokušati je rezervirati. Rješenje nije optimistična if naredba. Može zahtijevati transakciju, uvjetno ažuriranje ili strategiju zaključavanja odabranu za tijek rada.

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

Ako ovo ažuriranje ne utječe ni na jedan red, rezervacija se nije dogodila. To je konkretan rezultat otporan na utrke koji aplikacija može obraditi. Točna shema i pristup izolaciji razlikovat će se, ali načelo je trajno: provodite kritične prijelaze stanja blizu podataka.

Koristite redove čekanja za zaštitu vremena odgovora

Ne pripada svaka radnja ciklusu zahtjev–odgovor. Slanje obavijesti, generiranje izvješća, obrada prijenosa datoteka i pozivanje sporih usluga trećih strana uobičajeni su kandidati za asinkroni rad. Premještanje tih radnji u red čekanja može održati API-je responzivnima i ograničiti doseg sporih ovisnosti.

Ali red čekanja nije čarobni sloj pouzdanosti. Radnik može primiti istu poruku više puta. Posao može ne uspjeti na pola puta. Nizvodni pružatelj usluge može prihvatiti zahtjev dok radnik izgubi odgovor. Obrađivači poslova stoga trebaju biti idempotentni, vidljivi i sigurni za ponovno pokušavanje.

Za promjene koje istodobno zapisuju u bazu podataka i objavljuju poruku, razmotrite obrazac odlaznog spremnika. Pohranite namjeravani događaj u istoj transakciji baze podataka kao i poslovnu promjenu, a zatim neka ga zaseban proces objavi. Time se izbjegava krhki jaz u kojem potvrda baze podataka uspije, ali objava poruke ne uspije.

Docker bi lokalni rad trebao učiniti predvidljivim

Spremnici su najvrjedniji kada uklanjaju nejasnoće okruženja. PHP aplikacija trebala bi se moći pokretati s istim deklariranim izvršnim okruženjem, proširenjima i ovisnostima o uslugama u razvojnim, testnim i produkcijskim okruženjima.

Održavajte slike malima i svrhovitima. Kada je prikladno, odvojite ovisnosti za izgradnju od ovisnosti za vrijeme izvođenja. Pokrećite aplikaciju s konfiguracijom koja se pruža putem mehanizama specifičnih za okruženje, umjesto da tajne ugrađujete u sliku. Migracije baze podataka tretirajte kao promišljen korak u implementaciji, a ne kao slučajnu nuspojavu svakog pokretanja spremnika.

Korisna lokalna postavka obično uključuje aplikaciju, bazu podataka i samo pomoćne usluge koje programeri doista trebaju. Lokalno reproduciranje svake produkcijske integracije može stvoriti više prepreka nego sigurnosti. Dajte prednost brzoj povratnoj informaciji, dokumentiranim zadanim vrijednostima i jednostavnom putu za testiranje stvarne integracije kada je to važno.

Mjerite prije optimiziranja

Rad na performansama najučinkovitiji je kada započne pitanjem: što je zapravo sporo i pod kakvim opterećenjem? Spor krajnji cilj može biti uzrokovan neindeksiranim upitom, pretjeranom serijalizacijom, ponovljenim udaljenim pozivima, neučinkovitom paginacijom ili jednostavno zahtjevom koji obavlja posao koji pripada redu čekanja.

Najprije instrumentirajte granice. Pratite trajanje zahtjeva, stopu pogrešaka, ponašanje upita baze podataka, latenciju reda čekanja i neuspjehe ovisnosti. Zapisi trebaju pružati kontekst, a da ne postanu odlagalište osjetljivih podataka. Metrike otkrivaju obrasce; tragovi i strukturirani zapisi pomažu objasniti pojedinačne neuspjehe.

Predmemoriranje je vrijedno kada ima jasnog vlasnika i priču o invalidaciji. Predmemorirajte podatke koji se često čitaju s poznatim zahtjevom svježine. Ne koristite predmemoriranje da biste sakrili neograničeni upit ili zbunjujući podatkovni model. Najbrži poziv bazi podataka i dalje je onaj koji vam više ne treba, ali ispravnost dolazi prije domišljatosti.

Učinite promjenu zahtjevom prvog reda

Skalabilnost nije samo pitanje obrade većeg prometa. Također se radi o omogućavanju većem broju programera, više značajki i više operativnih zahtjeva bez pretvaranja svakog izdanja u kockanje. Mali moduli, izričita sučelja, automatizirani testovi oko poslovnih pravila i reverzibilne promjene baze podataka čine budući rad manje rizičnim.

Skrivena moć PHP-a njegova je sposobnost da ostane blizu problema. Ne zahtijeva razrađenu platformu prije nego što tim može izgraditi disciplinirani pozadinski sustav. Uz jasne granice, jamstva potkrijepljena bazom podataka, promišljenu asinkronu obradu i rad na performansama vođen dokazima, PHP postaje ono što bi dobra tehnologija pozadinskog sustava trebala biti: dovoljno pouzdan da korisnici o njemu nikada ne moraju razmišljati.