Повеќето системи не пропаѓаат затоа што тимот избрал погрешен јазик, база на податоци или облачен провајдер. Тие пропаѓаат затоа што вчерашните разумни претпоставки тивко стануваат денешни ограничувања. Еден потрошувач станува многу. Синхроното барање почнува да координира работа низ услуги. Барање до база на податоци што било безопасно при лансирањето почнува да се натпреварува со секое друго барање.

Отпорноста, според тоа, помалку се однесува на изградба на импресивен стек, а повеќе на дизајнирање за промени. Во PHP backend работата, тоа значи експлицитно дефинирање на границите, одржување на оперативното однесување видливо и избирање сложеност само кога решава реален притисок.

Почнете со одговорности, не со технологии

Една услуга треба да биде разбирлива според тоа што поседува. „API апликацијата“ обично е премногу широка одговорност. Појасен опис би бил: таа ги валидира барањата насочени кон клиентите, применува деловни правила, ја зачувува авторитативната состојба за својот домен и објавува исход за другите делови од системот.

Ова врамување ги подобрува одлуките пред во дискусијата да влезе која било рамка или инфраструктурен дијаграм. Ги открива важните прашања: Која компонента е изворот на вистината? Кои операции мора да завршат пред корисникот да добие одговор? Која работа може безбедно да се случи подоцна? Кој смее да измени запис?

Модуларен монолит често е одличен прв одговор. Тој може да ги одржи поврзаниот код, трансакциите и прашањата за распоредување едноставни, додека спроведува граници преку модули, интерфејси и тестови. Разделувањето на услуги е оправдано кога независното скалирање, сопственоста, динамиката на распоредување или изолацијата на неуспеси создаваат конкретна корист — не само затоа што архитектурниот дијаграм изгледа помодерно.

Дизајнирајте API-ја околу трајни договори

API е ветување дадено во несовршени услови. Клиентите надградуваат бавно, мрежите повторуваат барања, а невалиден влез на крајот пристигнува. Отпорниот API ги третира овие како нормални работни услови, а не како исклучителни рабни случаи.

Користете имиња ориентирани кон ресурси каде што одговараат, но дајте предност на доследното однесување пред стилската чистота. Одговорите за грешки треба да имаат стабилна форма, неуспесите при валидација треба да ги наведуваат засегнатите полиња, а статусните кодови треба точно да го одразуваат исходот. Клиентот не треба да мора да анализира човечка реченица за да одлучи дали може да повтори обид.

Повторните обиди заслужуваат посебно внимание. Ако клиентот повтори барање за плаќање, нарачка или обезбедување по истек на време, серверот не смее слепо да ја изврши акцијата двапати. За операции со значајни несакани ефекти, прифатете клуч за идемпотентност и зачувајте го резултатот поврзан со тој клуч. Повтореното барање тогаш може да го врати првичниот исход наместо да создаде нов.

public function createOrder(Request $request): Response
{
    $key = $request->header('Idempotency-Key');

    if (!$key) {
        return $this->json(['error' => 'Idempotency-Key is required'], 400);
    }

    return $this->idempotency->run($key, function () use ($request) {
        return $this->orders->create($request->validated());
    });
}

Важниот детал не е обликот на контролерот. Тоа е дизајнот на складирањето и трансакциите зад него: клучот мора да биде поврзан со опсегот на барањето, истовремените барања што го користат мора безбедно да се обработуваат, а завршениот одговор мора да остане достапен за соодветен период на задржување.

Нека базата на податоци ја штити вистината

Валидацијата во апликацијата е вредна, но не е замена за ограничувањата во базата на податоци. Две барања може во ист момент да поминат проверка за уникатност на ниво на апликација. Уникатен индекс е тоа што спречува и двете да бидат потврдени.

Користете примарни клучеви, странски клучеви каде што одразуваат вистинска врска, уникатни ограничувања за деловни инваријанти и трансакции за промени што мора да успеат заедно. Одржувајте ги трансакциите фокусирани: држењето трансакција отворена додека повикувате надворешен API го зголемува времето на заклучување и претвора далечински прекин во спор во базата на податоци.

Индексите треба да следат набљудувани шаблони на пристап. Индекс е корисен кога поддржува филтрирање, спојување или подредување на конкретно барање; не е декорација за секоја колона. Прегледувајте бавни барања со вистински параметри и реалистичен обем на податоци. Потоа проверете го планот за извршување пред да прогласите дека проблемот е во барањето или ORM релацијата.

Одвојте го локалното потврдување од надворешната испорака

Кога ажурирање во базата на податоци мора да активира е-пошта, webhook или последователен настан, избегнувајте да третирате мрежен повик во процесот како дел од трансакцијата. Надежен образец е outbox: запишете ја деловната промена и записот за настанот во иста трансакција, а потоа нека worker ги испорача настаните што чекаат. Испораката може да се случи повеќе од еднаш, па потрошувачите сè уште имаат потреба од идемпотентно ракување.

• Потврдете ги заедно авторитативната состојба и записот за настанот.
• Обработувајте ги записите што чекаат асинхроно со ограничени повторни обиди.
• Запишувајте ги неуспесите доволно јасно за операторите да можат да истражат.
• Направете ги потрошувачите безбедни кога настанот повторно се испорачува.

Ова не го елиминира неуспехот. Го прави експлицитен и поправлив.

Користете асинхрона работа за да ја заштитите патеката на барањето

Веб-барањето вообичаено треба да го направи само она што е потребно за да произведе точен, навремен одговор. Обработката на слики, генерирањето извештаи, масовните известувања и некритичните интеграции се силни кандидати за редици. Придобивката не е само брзина; таа е изолација. Бавен провајдер за е-пошта не треба да ги исцрпи истите worker-и за барања потребни за опслужување страници со сметки.

Редиците бараат дисциплина. Секоја задача има потреба од истек на време, политика за повторни обиди и набљудлива крајна состојба на неуспех. Повторните обиди треба да бидат ограничени и не треба да повторуваат небезбедни несакани ефекти без идемпотентност. Задача што секогаш не успева не е кандидат за повторен обид засекогаш; таа е оперативен сигнал.

Направете Docker повторлива средина, а не мистериозна кутија

Контејнерите можат да го направат локалниот развој и распоредувањето подоследни, но само кога конфигурацијата останува намерна. Изградете неизменлива слика на апликацијата, внесувајте конфигурација специфична за околината при извршување и чувајте ги податоците со состојба надвор од контејнерот на апликацијата. Контејнер за база на податоци може да биде удобен при развој; трајноста во продукција зависи од управувано складирање, постојани волумени, резервни копии и процес на обновување што навистина е тестиран.

За PHP, работното опкружување треба да изложува јасно здравствено однесување. Проверка за живост одговара дали процесот треба да се рестартира. Проверка за подготвеност одговара дали може безбедно да прима сообраќај. Не ја правете подготвеноста зависна од секоја опционална зависност; во спротивно, прекин во неповрзана интеграција може непотребно да отстрани здрав капацитет.

Мерете пред да оптимизирате

Работата на перформансите е најефективна кога започнува со симптом видлив за корисникот и докази. Снимајте траење на барања, стапки на грешки, длабочина на редици, латентност на базата на податоци и заситеност на ресурси. Додајте структурирани логови со идентификатор на барање или корелација, за неуспешниот API повик да може да се следи низ worker-и и зависни услуги.

Потоа оптимизирајте ја ограничената патека. Тоа може да биде N+1 барање, недостиг на пагинација, прекумерна серијализација, преголем payload или connection pool под притисок. Кеширањето може да помогне, но воведува одлуки за инвалидација и доследност. Кеширајте податоци само кога барањето за свежина е разбрано и дефинирајте како кешот се пополнува, истекува и заобиколува за време на инцидент.

Градете за следната промена

Одржливоста е отпорност со текот на времето. Мали промени што може да се прегледаат, планови за миграција што дозволуваат безбедно враќање назад, автоматизирани тестови околу деловните правила и јасна сопственост на оперативните контролни табли ја намалуваат цената на приспособувањето. Целта не е да се предвиди секое идно барање. Таа е обичната промена да не изгледа опасна.

Најдобрата архитектура ретко е најголемата збирка компоненти. Таа е онаа што го прави важното однесување лесно за лоцирање, неуспесите лесни за ограничување, а одлуките лесни за ревидирање. Надвор од стекот, тоа е трајната предност: систем што може да продолжи да се развива без да ја изгуби стабилноста.