Įvykiais grįsta architektūra: Šablonai, privalumai ir dažni spąstai
Kai sistemos išauga už vienos paslaugos ir vienos duomenų bazės ribų, sinchroninis užklausos-atsakymo modelis tampa našta. Paslaugos tampa glaudžiai susietos, gedimai kaskadiškai plinta, o nepriklausomas komponentų mastelio keitimas tampa beveik neįmanomas. Įvykiais grįsta architektūra (EDA) sprendžia šiuos iššūkius apversdama komunikacijos modelį: užuot tiesiogiai kviesdamos viena kitą, paslaugos skleidžia įvykius, kuriuos kitos paslaugos vartoja asinchroniškai.
Įvykių šaltiniai ir CQRS
Įvykių šaltiniai plėtoja koncepciją toliau, paversdami įvykius pirminiu tiesos šaltiniu. Užuot saugodami dabartinę būseną, saugote visą įvykių seką. CQRS natūraliai dera su įvykių šaltiniais, atskirdama rašymo modelį (įvykių saugyklą) nuo skaitymo modelių (materializuotų rodinių). Rašymo operacijos prideda įvykius į saugyklą, o projekcijos asinchroniškai kuria skaitymui optimizuotus rodinius.
Žinučių tarpininko pasirinkimas: Kafka prieš RabbitMQ
Pasirinkimas tarp Apache Kafka ir RabbitMQ atspindi iš esmės skirtingas žinučių filosofijas. Kafka yra paskirstytas commit žurnalas — žinutės saugomos diske sutvarkytose, nekeičiamose particijose. RabbitMQ yra tradicinis žinučių tarpininkas, įgyvendinantis AMQP — nukreipia žinutes per mainus į eiles. Praktikoje daugelis gamybinių architektūrų naudoja abu: Kafka kaip pagrindinę įvykių magistralę ir RabbitMQ užduočių eilėms ir sudėtingam nukreipimui.
Gedimų valdymas: Negyvų laiškų eilės ir idempotentiniai vartotojai
Paskirstytoje įvykiais grįstoje sistemoje gedimas nėra išimtis — tai konstanta. Negyvų laiškų eilės (DLQ) suteikia saugos tinklą žinutėms, kurių nepavyksta apdoroti po konfigūruojamo bandymų skaičiaus. Lygiai svarbi yra vartotojo idempotentiškumas: kadangi žinučių pristatymas iš esmės yra „bent kartą", kiekvienas vartotojas turi elegantiškai apdoroti pasikartojančias žinutes. Standartinis požiūris — įtraukti unikalų įvykio ID ir palaikyti idempotentiškumo raktų saugyklą.
Operaciniai spąstai, kurių reikia vengti
Padėję daugeliui organizacijų įdiegti įvykiais grįstas architektūras, matome šiuos dažniausius spąstus:
- Galutinio nuoseklumo ignoravimas UI. Jei rašymo kelias yra asinchroninis, bet UI tikisi greito nuoseklumo, vartotojai matys pasenusias duomenis. Projektuokite UI optimistiniams atnaujinimams.
- Įvykių traktavimas kaip API iškvietimų. Įvykiai turėtų reprezentuoti faktus, ne komandas. "OrderShipped" yra geras įvykis; "ShipOrder" yra komanda, užmaskuota kaip įvykis.
- Schemos evoliucijos aplaidumas. Įvykiai yra nekeičiami po paskelbimo, bet jūsų domeno modelis evoliucionuoja. Be schemos registro ir versijų strategijos, seni vartotojai suges keičiantis formatams.
- Nepakankamas stebėjimas. Paskirstytas įvykių srautas iš prigimties sunkiau sekamas. Investuokite į paskirstytą sekimą (OpenTelemetry), koreliacijos ID ir vartotojų vėlavimo stebėjimą nuo pirmos dienos.
Norite aptarti šias temas nuodugniau?
Mūsų komanda pasiruošusi architektūros peržiūroms ir strateginėms sesijoms.
Suplanuoti konsultaciją →