Názory k článku Prechod hostingu na mikroslužby: cesta zlyhaní a úspechov
-
Díky za zkušenosti z praxe. Tyto zkušenosti jsou cenné, protože jedna věc je teorie microservis a druhá věc je si to projít doopravdy v praxi se všemi chuťovkami okolo.
K tomu ACID a drobení databáze. Databázově distribuovaný systém se těžko udržuje konzistentní. Proto je rozumné se někde zastavit a ponechat si monolit, jak o tom píšete. Výhodou jsou snadné JOINy databázových tabulek a hlavně možnost využít databázové transakce, které zajišťuji konzistenci. A co si málokdo uvědomuje, dobře napsaný monolit se dá také škálovat. -
Díky za článek.
Z mojí zkušenosti je právě typický problém nějaká zažitá představa, že microservices vyřeší většinu stávajících problémů s monolitem. A čím více microservices, tím lépe. Kompletně ignorujíc, že se s vytvářením distribuovaného systému objeví nepřeberné množství složitějších problémů.
Za mě microservices ano, ale s rozvahou a tam kde se dají jasně z produktového pohledu definovat boundaries.
Doporučuji k přečtení:
https://dwmkerr.com/the-death-of-microservice-madness-in-2018/
https://www.simplethread.com/youre-not-actually-building-microservices/27. 6. 2019, 07:11 editováno autorem komentáře
-
Ďakujem za reakciu a odkazy na články.
Súhlasím, že mikroslužby problémy monolitov nevyriešia - ono to je vôbec otázne, či sú to problémy monolitov, alebo či nejde väčšinou len o ľudský faktor. Monolity samé o sebe nie sú zlé, ak sa správne navrhnú a hlavne, správne sa aj vyvíjajú. Ak sa ten vývoj pokašle a začne sa kód prasiť a ohýbať, tak sa budúca generácia vývojového tímu má načo tešiť :)
Mikroslužby prinášajú vlastné problémy, nakoľko je to úplne iný svet. Otázkou je, či množstvo a zložitosť tých skutočných problémov bude oproti monolitom väčšie, alebo dúfajme menšie. Ukáže až čas a skúsenosti ďalších.
-
Našim veľkým problémom bola nenažranosť Elasticu - vzhľadom na hardvér. Aj tá malá inštancia ELK Stacku, ktorá nám slúži len pre vyhľadávanie v eventoch za posledné 3 týždne beží na samostatnom serveri (8-jadro / 32GB RAM / 240GB SSD), a neustále je ten server vyťažený na 60-80%.
Spočiatku tento ELK Stack bežal na omnoho výkonnejšom serveri, avšak asi po pol roku sa totálne zrútil. Problém bol ten, že sme mali otvorené všetky indexy (inak povedané: aktívne všetky dáta) za posledných ~6 mesiacov. Čím viac indexov je v ES otvorených, tým väčšie množstvo RAM ES vyžaduje. Následne sme to riešili uzatváraním indexov starších ako 3 mesiace. Dáta tak boli stále uložené na disku, avšak elastic ich nemal v pamäti a nebolo možné s nimi aktívne pracovať. Idea bola taká, že v prípade potreby tie indexy znova otvoríme a vyhľadáme dané dáta.
Väčšie inštancie ES je lepšie riešiť v clusteri - povedzme dva servery s vyšším výkonom a SSD diskami vyhradiť len na nedávne dáta, a k tomu mať v clusteri minimálne jeden ďalší server pre archívne dáta s pomalšími diskami o vyššej kapacite (a prípadne vertikálne škálovať servery pri nedostatočnej kapacite). Toto je vhodné riešenie pre ES obsahujúce destiatky tera dát. Idea síce dobrá, ale priveľmi drahá vzhľadom k tomu, ako často zisťujeme, čo sa dialo pred rokmi.
Najväčší problém s dlhodobým uchovávaním logov sme videli v indexácii dát. Ako som spomínal v článku, ak je field ID typu integer, jeho zmena na string nie je v elasticu možná. Je nutné zahodiť index, a vytvoriť ho nanovo (možno kecám, a najnovšia verzia ES to už má vyriešené). Môže nastať aj situácia, že po čase zistíte, že Vám koliduje nejaký field, ktorý je zaindexovaný, a tie dáta nemáte (ES ich odmietol, pretože nesedel dátový typ). Pre kritické systémy je preto lepšie dodatočne tie dáta uchovávať aj v surovej forme.
Retencia troch týždňov, ktorú sme si interne určili, vyšla z toho, že hlbšie do minulosti ideme len vo výnimočných prípadoch - najčastejšie ELK stack využívame len pre debugovanie pri vývoji. Pre vizualizáciu štatistík a zaujímavých dát sypeme metriky do Influxu a zobrazujeme ich Grafanou. A ak potrebujeme niečo spätne z tých historických dát extrahovať a vizualizovať, nie je to problém - surové dáta sú v JSONu a nie je nič jednoduchšie, ako prejsť dané fajly python skriptom.
