alef0 napísal:
si za monolit?
ako si to, riso, predstavujes v praxi? lebo clanok je mudry, ale viac ideologicky
Ja si to nepredstavujem, v praxi to pouzivam uz par rokov viac ci menej (v poslednej dobe uz skor viac). A ver tomu, ze velke firmy uz takto dnes funguje a casto nove generacie ich platforiem su robene presne takymto sposobom a uz su niektore aj v produkcii (Hailo napr.).
Najdolezitejsim prvkom takejto architekturi je vascinou nejaky solidny middleware napriec celou platformou, cez ktory vedia spolu mikrosluzby spoly komunikovat bez toho, aby mali znalost akychkolvek konfiguracnych bludov.
Modernych sposobov je viac, ale ja pouzivam RabbitMQ ako mocny middleware napriec celou architekturou. Nad rabbitom mas nejaky asynchronny framework, aby si mohol iba publishovat eventy, ktore z message queue si na starost zoberu jednotlive mikrosluzby, ked maju momentalne cas. Na to pouzivam Celery, ale mas tiez viacero moznosti.
Dolezite je, aby vsetky mikrosluzby boli:
1) stateless (neuchovavaju ziadne informacie)
2) decoupled (bez dependencies na inych mikrosluzbach)
3) idempotentne (lebo v takychto architekturach je bezne, ze nejaky event z unique id 123 bude triggernuty 2-3 krat)
- k tomu este dotat, ze vsetky unique ids by mali byt generovane top down, cize niekde na zaciatku vygenerujes unikatne identifikatori a potom to posles na platformu, kde okrem RabbitMQ este mozu byt interne pouzivane ine message queues ako NSQ, cize toto je v takych pripadoch dolezite.
4) hlupe (mikrosluzba A nemoze vediet nic o mikrosluzbe B, C atd...)
Dalsou dolezitou vecou je minimalizovat konfiguraciu (cim menej roznych konstant, URL adries, portov a pod., najlepsie len jedna adresa na middleware cluster a ziadnu inu konfiguraciu nepotrebujes). Musi to by skalovatelne, to znamena, nieco ako Puppet alebo Chef musi vediet deploynut celu platformu s desiatkami / stovkami mikrosluzieb jednym klikom v hocijakom prostredi (lokalne na tvojom Macbooku, interacne, staging aj production musia byt uplne rovnako a replikovatelne velmi jednoducho) a potom to musi samo rast a krpatiet podla potreby (na AWS doporucujem autoscaling groups).
Databazy tiez su dost casto problem. Vacsinou sa pouziva mix SQL a NoSQL, pricom coraz viac dat sa postupne presuva skor do key value stores. Idealne by bolo mat vsetko, co je momentalne consumer facing v cloude v niecom ako DynamoDB alebo Redis a asynchronne bezat nejaku synchronizaciu do relacnej databazy, kde mozes nad datami robyt narocne operacie ako rozne komplexne sql prikazy, co by produkcne prostredie zabili, keby si to tam bezal (Redshift napriklad), reporting, analytics a pod.
Co najviac veci by si mal robit asynchronne. Priklad, mas API, kde consumer posle peniaze z kreditky, tak mu okamzite vrat response, aby bola aplikacia svizna, a peniaze z kariet ber asynchronne, pricom dalsou vyhodou v takom pripade je, ze mozes skusit zobrat peniaze z karty viac krat, v pripade, ze bude platba odmietnuta, cize firma strati menej penazi, kedze niekedy v pondelok Jozovu kartu odmietne, ale v utorok mu uz pridu nove peniazky, tak uz bude fungovat a moze uhradit peniaze, co nam dlzi.
Takisto veci ako emaily ani nespominam, posielaj asynchronne a najlepsie cez nejaku cloud sluzbu, vlastny mail server je v dnesnej dobe uz absurdita.
Na samom vrchu mikrosluzbovej architektury by mala byt iba tenka HTTP RESTful vrstva (tzv. edge).
Ono sa to lahko vysvetluje, ale v praxi tam je vela problemov, ale postupne ludia prichadzaju s novymi rieseniami.
Napriklad caching je uz dlhodobo mojou nocnou morou, lebo v takychto architekturach je to dost komplikovane.
Zatial vsetko.