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

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

Метриките за перформанси опишуваат момент

Латентноста, протокот, употребата на CPU и стапката на грешки се важни. Тие откриваат дали системот ја исполнува тековната побарувачка. Проблемот почнува кога тие стануваат целата архитектонска дискусија.

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

Перформансите одговараат: „Колку ефикасно функционира ова во познати услови?“ Отпорноста поставува пошироко прашање: „Што се случува кога условите повеќе не се познати?“

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

Почнете со границите на неуспех

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

Честа грешка е да се користи долгото стандардно истекување на време и тоа да се нарече доверливост. Долгите истекувања на време често го влошуваат преоптоварувањето. Барањата ги зафаќаат работниците додека чекаат, пуловите на работници се полнат, редиците растат и мал неуспех на зависност се шири во поширок прекин.

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

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

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

На повторните обиди им треба буџет, не оптимизам

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

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

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

$key = $request->header('Idempotency-Key');

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

$order = $orders->createOnce($key, $request->validated());

return response()->json($order, 201);

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

Дизајнирајте асинхрона работа за повторување

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

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

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

Направете ги промените на податоците практично повратни

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

Претпочитајте промени со проширување и стеснување за важните шеми:

1. Додајте нови структури на начин што е компатибилен наназад.
2. Распоредете код што може да ги чита и старите и новите форми.
3. Пополнете ги податоците наназад во контролирани серии каде што е потребно.
4. Префрлете ги читањата и запишувањата откако новата патека е докажана.
5. Отстранете ја старата структура во подоцнежно распоредување.

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

Контејнерите треба да ја изложуваат здравствената состојба, не да ја кријат

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

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

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

Набљудувајте го системот како збир на ветувања

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

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

Отпорноста е архитектонска навика

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

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