Vlákno názorů k článku Mikroslužby: moderní aplikace využívající známých konceptů od Ladislav Jech - No offesive, ale clanek mi prijde, jak z...
-
No offesive, ale clanek mi prijde, jak z doby, kdy se mikroservisy zacaly delat, a popsanymi mechanismy spise pripomina prvni faze, ve kterych jeste nektere firmy ustali, rikaji mikroservice architektura, ale jen maj mensi runtime, na kterem bezi jednu sluzbu misto velkeho ESB runtim (Weblogic, Websphere), na kterem byly ty sluzby postaveny vsechny.
V clanku nektere veci jsou naznacene, napr. proc nepouzivat sdilenou databazi, ale neni to dale rozvedeno, tj. jak tento problem vyresit, to ze ma sluzba svoji databazi neni proste konec smycky problemu flaws v architekture. Dalsi problem nebyla jen rozdelena databaze, ale co mame delat, kdyz potrebujeme s nejakymi daty pracovat ve vice domenovych sluzbach, tj. napr. mam UserID, ktere managuje User service, ale potrebuju to videt v HR sluzbe v seznamu zamestnancu, i v security sluzbe pro linkovani accountu, apod. Zase konzistence. Odpoved je neco, co nekteri lide (z vlastni zkusenosti) nechteji prijimat a co je prave super na event driven systemech :-) a to je tzv. "Eventual Consistency".
Jakmile se plitnul monilit, tak se z dvojfazoveho komitu stalo peklo, co s tim? Odpoved na to jsou asynchroni sluzby, zde mame k dispozici zname pojmy, prvnim z nich jsou tzv. "Sagas". Saga je transakcni model sekvenci lokalnich transakci. UzivatelZalozen, UzivatelZmenen, UzivatelUkoncen, apod. Dalsim vzorem je CQRS - "Command Query Responsibility Segregation", to je jedno z jader mikroservis.
CQRS opet resi jak atomicky aktualizovat databaze a produkovani eventu/zprav. na monolitech byla drive cesta vytvorit distribuovanou/globalni transakci ve ktere provedu obe operace, ale to je cesta do pekla, ktera konci situaci, ze potrebuju udelat v transakci 8 kroku nad ruznymi systemy a posledni selze, takze potrebuju rollback jak prase....:-) not funny scenarios.
A prisel "Event sourcing"(jako backup tu mame tzv. Tram) a "CQRS". Pro nektere to znamena, ze zase vznika nejaka centralni databaze. Ano, ale ta muze byt uz provozovana na distribuovanych systemech, nebo zprostredkovana pomoci na Kafce postavenem Confluentu.
O co jde. Mam neco, cemu rikam "Event Store" pomoci CQRS rozdeluji vstupni a vystupni IO mezi ruzne komponenty. Co to znamena? Sluzba neni zodpovena za persistenci dat, v nekterych pripadech ani nepotrebuje vlastni databazi, ale materializuje si pohledy "Prehravanim eventu".
Priklad sekvence tzv. Commands (Write) a Query (Read).
Write
- FE vygeneruje Create User command
- Ten se v Event Storu ulozi jako UserCreated event
- Fe vygeneruje ModifyUser command
- Ten se v Event Storu ulozi jako UserModified eventEventy jsou publikovany a mohou byt konzumovany sluzbou, ktera o ne ma zajem, napr. modifyuser potrebuji sluzba User, HR a Security service. Ty event dostanou a vsechny si aktualizuji svuj zaznam. Pripadne vubec tuto databazi neudrzuji, ale pokud chteji materializovat tabulku uzivatelu (muze to byt ktera koli sluzba, tzn. zadny domain lock!!!), tak i bez databaze proste prehrajou eventy a zmaterializuji si view pro odpoved a pamet zahodi. Tento pristup ma dalsi vyhodu. Mam tabulku User s ruznymi sloupecky v ruznych sluzbach:
- userId
- name
- accoutn(Security service only version)
- director(HR service only extension)
A najednou si rekneme, ze potrebujeme premodelovat na dva sloupecky:
- First Name
- Last NameA to je v tech mikrosluzbach, ktere nejsou mikrosluzbami proste dost prace. Ne tak v tomhle pripade, protoze jde jenom o Query do event storu, tu query zmenim ok na trech sluzbach, vsechny instance killnu na Kubernetu, a vydeplojuju znovu. Pri restartu si sluzba prehraje eventy a zmaterializuje si nove schema, tzn. zadna posrana migrace dat! :-)
Clovek si rekne, a to jako v tom event storu ulozim vsechno? No jasne, event store muze byt postaveny a Big Data systemech. A co, kdyz potrebuju prehrat nekolik let dat? Pro tento efekt lze delat v event storu tzv. Snapshoty, napr. jednou tydne, tj. budu vzdy prehravat max 7 dni. Co delat s verzovanim Eventu, kdyz se mi zmeni schema, a dalsi otazky jsou, ale ta hlavni, kdyz jsem tu popsal tuhle funkcionalitu je: Kolik mi zabere casu, nez tohle vsechno naimplementuju, to je hardcore :D
No a to clovek uz dneska nemusi, protoze tu mame nekolik reseni (open source) mikroservice platforms, asi nejlepsi na uceni je od mikroguru Richardsona Eventuate.io, z meho pohledu nebude rychla a bude zrava, nebot je postavena na Springu. Dalsi kandidat je Confluent a Axon. Confluent se rozmaha, v Kafce uz dnes najdete objekty jako Table a SQL query language :-))
Pokud Vam jde o vykon a chcete se zamerit spis na psani message handleru, tj. jak udelat z commandu event, kam se vrazi business logika, tak doporucuju hardcore Light4j platformu od NetworkNT, jak uz nazev napovida nejde o balast Springu. Funkcionalitou zkopirovali reseni navrzene Richardsonem, akorat ho prepsali pro co nejvyssi vykon a jeste rozsirili.
Tyhle aspekty by clanek mohl zohlednit taky. Ja se nerozepisuju moc do detailu, do uvozovek davam code names pro google search, koho to zajima.
Jako posledni sem pridam take znamy prvek z dob ESB (SOA) a BPMN a to Process orchestration, coz opet souvisi s globalnimi transakcemi. Mam procces a potrebuju aby cely nejak skoncil, nebo se rolbakoval, bohuzel nejde o transakci o nekolika prikazech nad jednou databazi, ale o transakci nad nekolika aplikacemi(db or service). v SOA se jednalo o tzv. Kompozitni aplikace.
I zde existuje vyvoj smerem k tzv. Choreography, ve zkratce jde o to, ze uprostred nesedi zadny hutny clovicek (Kompozit), ale to co kompozit delal je implemenntovano inter service komunikaci, tj. nikdo uprostred, lokalni transakce, a pohoda. Ale Choreografie existuje jako kompletni obrazek celeho procesniho flow.
-
Pavel TišnovskýZlatý podporovatelDíky moc za doplnění. Toto byl jen úvodní článek se základními termíny, už tak asi 4x delší, než Root potřebuje :-) Ale bude několik pokračování, kde se problematika stavů aplikace bude probírat. O monolitické DB, nad kterými běží "pseudo-mikroslužby" se zmiňuji hlavně proto, že na to narazí spousta týmů, a někdy je to dost peklo (https://www.youtube.com/watch?v=gfh-VCTwMw8)
Zmínka bude i o choerography a rozdílům oproti (asi dnes používanější) orchestration.
ČLÁNKY DO MAILU