Повеќето PHP бекенд-системи не откажуваат затоа што контролерот содржи една линија премногу. Тие откажуваат затоа што нормалниот код тивко претпоставува дека базите на податоци одговараат, редиците прифаќаат работа, API-јата на трети страни се однесуваат правилно и распоредувањата пристигнуваат без прекин. Шаблонскиот код може да направи апликацијата да изгледа уредно; отпорноста е она што ја одржува корисна кога реалноста станува неуредна.

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

Почнете со неуспехот како влезен елемент во дизајнот

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

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

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

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

Одржувајте го HTTP слојот тенок и експлицитен

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

final class CreateOrderController
{
    public function __invoke(CreateOrderRequest $request, CreateOrder $action): JsonResponse
    {
        $result = $action->handle(
            customerId: $request->user()->id,
            items: $request->validated('items'),
            idempotencyKey: $request->header('Idempotency-Key')
        );

        return response()->json($result->toArray(), $result->httpStatus());
    }
}

Дејството може да ја поседува деловната трансакција и да врати значаен исход. Исто така, може да стави последователна работа во редица откако нарачката безбедно ќе се евидентира. Контролерот останува едноставен, што е одлично својство за код на работ на системот.

Направете ги повторувањата безбедни пред да ги правите чести

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

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

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

$attempts = 0;

while (true) {
    try {
        return $client->send($payload);
    } catch (TransientTransportException $e) {
        $attempts++;

        if ($attempts >= 3) {
            throw $e;
        }

        usleep(100_000 * $attempts);
    }
}

Овој пример илустрира ограничена логика за повторување, а не универзална политика. Во продукција, сместете ја зад клиент за интеграција, за истекувањата на време, повторливите грешки, евидентирањето и корелациските податоци да останат доследни. Работникот, исто така, треба да има сопствена стратегија за повторување и dead-letter, наместо да наследува претпоставки за веб-барања.

Користете редици за да ја заштитите латентноста на барањата

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

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

Изградете ги задачите околу набљудлива состојба

Наместо задача што само вели „испрати фактура“, зачувајте состојба на фактурата и дозволете задачата безбедно да ја унапреди. Забележете го обидот, надворешната референца каде што е достапна и причина за неуспех погодна за операторите. Базата на податоци станува извор на вистината; редицата станува механизам за испорака на работа.

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

Нека базата на податоци ги наметнува инваријантите

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

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

Дизајнирајте ги контејнерите за замена, не за поправка

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

Проверките на здравјето треба да го одразуваат она што го тврдат. Лесна проверка на живост може да потврди дека PHP процесот одговара. Проверката на подготвеност треба да одговори дали инстанцата може безбедно да опслужува сообраќај, без секоја сонда да се претвори во скапа целосна ревизија на зависностите. Ако услуга за препораки надолу по текот е опционална, нејзиниот прекин не мора нужно да ја направи целата апликација неподготвена.

Мерете ги сигналите што ги насочуваат одлуките

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

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

Целта не е контролна табла полна со графикони. Таа е побрзи, посмирени одлуки кога однесувањето се менува под оптоварување или при прекин.

Отпорноста е збир на намерни компромиси

Не постои единствена „отпорна архитектура“ што може да се копира во PHP проект. На мала внатрешна алатка може да ѝ треба едноставна трансакција и јасна порака за грешка. Работен тек насочен кон клиенти може да оправда идемпотентност, outbox, редици и усогласување. Зрелиот избор е пропорционална сложеност: градете заштитни мерки таму каде што неуспехот има значајни последици, а сè друго одржувајте го разбирливо.

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