Citat:
Deunan:
Facebook je presao na mikroservis arhitekturu, pa ne znam koliko ima poente raspravljati "koju bazu koristi" kad svaki servis ima posebno svoje baze. A servisa ko zna koliko ima (Netflix ima oko 400)...
Testirao sam neki server da se odjednom uloguje 10 000 korisnika iz MySQL baze. Ma, nema sanse, posle par stotina krene "TIMEOUT..." upozorenje. Za takve stvari samo in-memory baza. MNESIA tih 10 000 uloguje za 2-3 sekunde.
Microservices su trenutno popularni, pa ima i dosta hype-a. Kao sto Bane kaze, imati middleware koji kesira bazu je normalno, to se radilo i dok smo koristili SOA, pa je samo preneto na microservices - isto kao i hexagonalni paterni i jos svasta. MySQL sam po sebi moze da ima 10,000 konekcija, to nije problem, samo ako imas resurse, mozda ne znas da ga podesis - ali ni to nije toliko bitno, nijedan login servis nece svaki login gadjati bazu - kao sto opet Bane rece, normalno je da imas servis ispred koji kesira.
Glavna "fora" nije da taj kes bude in-memory, naravno da ce biti, vec kako inteligentno resiti distribuirano invalidiranje tog kesa po svim instanacama servisa. :) Naravno, koncept da se in-memory key-value store drzi odvojeno je skroz validan, ali ne tako skalabilan, tj. onda opet imas problem sa skalabilnoscu, samo malo pomeren. Ovo je ozbiljna tema (mozda neko od moderatora da razdvoji), ali nije ni blizu jednostavna za resavanje.
Treci deo price, to sto kazes da "svaki servis ima svoju bazu", to je nesto sto se ocekuje, sa stanovista design patterna. Ali, sa stanovista biznis logike, to nije nimalo jednostavno izvesti. Zamisli da imas bas korisnike u bazi. Trebaju ti korisnici za servis za autentikaciju (proveri username i password), trebaju ti korisnici za servis za accounting (koliko nekog resursa koji korisnik trosi, treba mu ID), i za servis za billing (ovaj pita i bazu od accounting-a koliko je potrosio i bazu korisnika za to koji su podaci korisnika). Ako je sve u relacionoj bazi, resenje je poznato odavno, upiti brzi, JOIN radi po primarnom kljucu. Ako svaki servis ima svoju bazu, onda imas problem, prvo jer ti je data denormalizovana (pa se kolicina povecala), drugo jer je treba sinhronizovati. Neko resenje koje se korisit je da ubacis neki middleware mikroservis za citanje ka bazi, ali onda opet imas sve podatke u jednoj bazi (koja onda trpi pritisak), koji ces resavati kesiranjem, kako na nivou tog middleware servisa, tako i kesiranjem za svaki servis odvojeno (da bi dodatno smanji pritisak ka bazi). E sad, onda imas problem sa invalidacijom kesa, jer ti izmene na jednom servisu idu nazad ka bazi, pa to treba vratiti nazad na ostale servise zbog invalidacij njihovog kesa, pa imas back-pressure koji puni bafere koji to citaju, pa moze sve da se blokira....
Mikroservisi su super dok su stateless, ja obozavam taj fazon - REST, hexagonalni pattern, stateless, milina. Odlicni su i za obradu neke unstructured date, tipa "zveknem sve u fajlove/objekte/S3" i udri. Ali kad ti treba relaciona data, nije jednostavno. I da se razumemo, najlakse je reci "pa pravi nerelaciono" - ali nije model taj na osnovu koga se modelira data, vec poslovne potrebe. Jednostavno, ljudi koji su pravili relacioni model (Codd i ekipica) tamo sedamdesetih nisu to radili "jer su pametni", nego jer su posmatrali realne poslovne procese. Ove in-memory strukture deluju super kad imas test case i nesto sitno korisnika, ali kad shvatis da ti treba da ti data bude ACID compliant i da ti nije prihvatljivo da izgubis nijedan jedini zapis, jer ti je tupple zapravo finansijska izjava i imas regulativu (poresku) koja potencira na integritetu tihi podataka, sve postane... zanimljivije. :D
Malo se raspisah.
tl;dr : Nije mikroservis arhitektura resenje za sve.
Please do not feed the Trolls!
Blasphemy? How can I blaspheme? I'm a god!'
Re: Linux ili apgrejd na Win 10?