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

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

Почнете со граници, а не со технологии

Границата на услугата треба да одразува деловна способност со сопствени правила и речник. „Нарачки“, „наплата“ и „идентитет“ можат да бидат разумни граници бидејќи претставуваат различни одговорности. „Читања од база на податоци“, „испраќање е-пошта“ и „валидација“ обично не се доволни сами по себе; тие се имплементациски аспекти што може да припаѓаат во поширок домен.

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

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

Направете ја сопственоста експлицитна

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

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

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

Изберете го вистинскиот вид договор

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

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

{
  "event": "order.placed",
  "event_id": "a1b2c3",
  "occurred_at": "2026-08-10T12:00:00Z",
  "data": {
    "order_id": "ord_123",
    "customer_id": "cus_456",
    "total": 49.99,
    "currency": "USD"
  }
}

Потрошувачот треба да го третира event_id како клуч за идемпотентност. Испораката барем еднаш е вообичаена во дистрибуираните системи, па затоа „обработи ја секоја порака точно еднаш“ ретко е безбедна претпоставка. Зачувајте доволно состојба за да откриете повторување пред да испратите е-пошта, да примените кредит или да создадете испорака.

Дизајнирајте за откажување пред да се случи

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

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

$response = $client->request('POST', '/payments', [
    'json' => $payload,
    'headers' => [
        'Idempotency-Key' => $paymentAttemptId,
    ],
    'timeout' => 3.0,
]);

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

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

Одржувајте ги API-јата мали и набљудливи

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

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

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

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

Користете Docker за да ги направите околините предвидливи

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

FROM php:8.3-cli

WORKDIR /app
COPY . .
RUN docker-php-ext-install pdo_mysql

CMD ["php", "bin/console", "messenger:consume", "async"]

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

Не ја мешајте независноста со изолацијата

Независното распоредување е вредно само кога е безбедно. Услуга што мора да ги координира изданијата со пет други не е суштински независна, дури и ако секоја има сопствено складиште и Docker слика. Внимателно верзирајте ги API-јата, прво правете дополнителни промени и отстранувајте стари полиња или крајни точки само откако потрошувачите ќе мигрираат.

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

Оправдајте ја сложеноста со конкретна придобивка

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

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