OBRASCI (ŠABLONI) ZA RAZVOJ

APLIKACIJA NA MIKROSERVISNOJ
ARHITEKTURI

XML i WS, Miroslav Zarić, FTN, 202

bazirano na materijalima dostupnim na: https://microservices.io/patterns
0

 OBRASCI ZA UPRAVLJANJE PODACIMA

• Jedna baza po servisu
• Deljene baze
• Saga
• Kompozicija API-ja
• CQRS (Command Query Responsibility Segregation)
• Domain Event (domenski događaji)
• Event Sourcing (izvori događaja)

OBRASCI ZA UPRAVLJANJE PODACIMA

JEDNA BAZA PO SERVISU

• Kontekst u kome se koristi - Većina servisa ima potrebu da trajno sačuva određene podatke.
• Problem - koja arhitektura baze podataka je pogodna za mirkoservisnu arhitekturu?
• Faktori koji utiču na izbor:
• Servisi treba da su međusobno slabo zavisni kako bi se mogli razvijati, puštati u rad i skalirati nezavisno
jedan od drugog.
• Određene poslovne transakcije moraju sačuvati određene nepromenljive podatke koje koristi više
servisa.
• Poslovne transakcije treba da pretražuju podatke koji pripadaju nekim drugim servisima.
• Pretraživanja podataka treba da spoje podatke koji postoje u bazama koje pripadaju drugim servisima.
• Baze podataka se ponekad moraju replicirati ili izdeliti (“sharding”) kako bi se skalirale.
• Različiti servisi mogu imati različite zahteve u pogledu čuvanja podataka, za neke su relacione baze
dobro rešenje, za neke to nisu, za neke su najbolje rešenje graf-orijentisane baze podataka ili
repozitorijumi nestrukturiranih podataka.

OBRASCI ZA UPRAVLJANJE PODACIMA

JEDNA BAZA PO SERVISU

• Rešenje - podatke svakog od servisa čuvati kao
privatne, tako da im samo taj servis ima direktni
pristup, a svima ostlaima ti podaci su dostupni jedino
preko servisnog API-ja. Servis transakciono upravlja
samo svojim podacima.

• Postoji nekoliko nalčina da se obezbedi privatnost podataka. Za relacione baze moguće su sledeće opcije:
• Private-tables-per-service – svaki servis je vlasnik određenog skupa tabela i ima ekskluzivno pravo
pristupa tim tabelama.
• Schema-per-service – svaki servis je vlasnik jedne šeme podatka i jedini joj ima pristup.
• Database-server-per-service – svaki servis koristi sopstveni server baze podataka.
slika preuzeta sa: https://microservices.io/patterns/data/database-per-service.html

OBRASCI ZA UPRAVLJANJE PODACIMA

JEDNA BAZA PO SERVISU

• Rezultati primene
• Dobre strane:
- Garantuje slabu međuzavisnost servisa.
- Promene u strukturi baze jednog servisa ne utiču ni na jedan drugi servis.
- Svaki servis je slobodan da koristi kakav god tip baze podataka je za njega najpodesniji.
• Loše strane:
- Implementacija poslovnih transakcija koje zahtevaju učestvovanje više servisa nije više
jednostavna, jer se sada radi o distribuiranoj transakciji, a njih po CAP (Consistency,
Availability, Partition tolerance) teoremi treba izbegavati kad je moguće.
- Implementacija pretrage kojom se spajaju podaci iz više servisa je izazov.
- Kompleksnost rešenja sa raznorodnim tipovima baza.

OBRASCI ZA UPRAVLJANJE PODACIMA

DELJENA BAZA
• Kontekst u kome se koristi - Većina servisa ima potrebu da trajno sačuva određene podatke.
• Problem - koja arhitektura baze podataka je pogodna za mirkoservisnu arhitekturu?
• Faktori koji utiču na izbor:
• Servisi treba da su međusobno slabo zavisni kako bi se mogli razvijati, puštati u rad i skalirati nezavisno
jedan od drugog.
• Određene poslovne transakcije moraju sačuvati određene nepromenljive podatke koje koristi više
servisa.
• Poslovne transakcije treba da pretražuju podatke koji pripadaju nekim drugim servisima.
• Pretraživanja podataka treba da spoje podatke koji postoje u bazama koje pripadaju drugim servisima.
• Baze podataka se ponekad moraju replicirati ili izdeliti (“sharding”) kako bi se skalirale.
• Različiti servisi mogu imati različite zahteve u pogledu čuvanja podataka, za neke su relacione baze
dobro rešenje, za neke to nisu, za neke su najbolje rešenje graf-orijentisane baze podataka ili
repozitorijumi nestrukturiranih podataka.

OBRASCI ZA UPRAVLJANJE PODACIMA

DELJENA BAZA
• Moguće rešenje - Koristiti jednu bazu podataka, koju dele svi
mikroservisni moduli. Svaki servis može slobodno da pristupa i podacima
koji su u vlasništvu drugih mikroservisa, koristeći lokalne transakcije (ACID
- Atomicity, Consistency, Isolation, Durability compliant).
OBRASCI ZA UPRAVLJANJE PODACIMA

DELJENA BAZA
• Rezultati primene
• Dobre strane:
- Programer se koristi već dobro poznatih tehnikama za pristup podacima (transakcije) kako bi
garantovao konzistenciju podataka.
- Jednu zajedničku bazu je lakše održavati.
• Negativne strane:
- Međuzavisnost mikroservisnih modula tokom razvoja - programer koji radi na razvoju jednog
servisa mora da se koordiniše pri promenama ili čeka rezultat razvoja dela baze podataka
koji primarno koristi neki drugi servis. Ovo usporava razvoj.
- Međuzavisnost servisa tokom izvršavanja programa - pošto svi servisi pristupaju istoj bazi i
potencijalno istim tabelama može doći do preklapanja u pristupu i do eventualnog
blokiranja jednog servisa od strane drugog koji drži zaključanim deo baze.
- Jedna jedinstvena baza se može pokazati kao loše rešenje sa stanovišta raspoloživog
prostora za čuvanje podataka.

OBRASCI ZA UPRAVLJANJE PODACIMA

SAGA OBRAZAC
• Kontekst u kome se koristi - Implementiran je obrazac jedne baze po servisu. Određene
poslovne transakcije ipak zahtevaju da više servisa odradi određeni deo posla, pa je neophodno
obezbediti mehanizam kojim se postiže konzistencija podataka između servisa.
Pri tome se ne može raditi lokalnom ACID transakcijom, jer se radi o potpuno odvojenim bazama.
• Problem - Kako održati konzistenciju podataka između različitih servisa?
• Faktori koji utiču na izbor:
• Primena Two phase commit (2PC) protokola nije odgovarajuća opcija.
2PC je protokol za distribuirane transakcije koji je transparentan ka krajnjem korisniku, podrška za upravljanje transakcijama
(koordinator) često se ugrađuje u samu platformu distribuiranog sistema. Transakcije se obavljaju u dva koraka
- commit-request/voting korak u kome koordinator priprema sve procese koji učestvuju u transakciji i da glasaju Da/Ne (izvršiti
komit?)
-commit korak - koordinator na osnovu glasanja svih učestuvjućih procesa donosi odluku da li da izvrši komitovanje (samo ako su
svi glasali Da).

OBRASCI ZA UPRAVLJANJE PODACIMA

SAGA OBRAZAC
• Rešenje - Implementirati poslovnu transakciju koja zahteva učešće više servisa kao sagu.
• Saga predstavlja sekvencu lokalnih transakcija.
• Svaka lokalna transakcija (unutar servisa) ažurira stanje svoje baze i generiše događaj koji se koristi kao okidač za sledeću
transakciju u sekvenci.
• Ukoliko lokalna transakcija ne uspe, jer narušava neko od postavljenih pravila, u sagi se izvršava niz kompenzacionih
transakcija kojima se poništavaju prethodne promene izazvane lokalnim transakcijama povezanim u sagu.

• Dva načina koordinacije transakcija u sagi:

• Koreogra ja - svaka lokalna transakcija generiše
događaj i tako trigeruje lokalne transakcije u
drugim servisima
• Orkestracija - poseban objekat (orkestrator)
upravlja učesnicima tako što utvrđuje koju lokalnu
transakciju treba da izvrše
slika preuzeta sa: https://microservices.io/patterns/data/saga.html
fi

OBRASCI ZA UPRAVLJANJE PODACIMA

SAGA OBRAZAC
• Implementacija koreogra jom
1. Order Service prima POST request, i kreira
Order u pending stanju
2. Order Service emituje Order Created događaj
3. Customer Service “hvata” ovaj događaj i
pokušava da rezerviše sredstva na računu
klijenta
4. Customer Service emituje događaj koji sadrži
informaciju o uspehu/neuspehu rezervacije
sredstava
5. OrderService detektuje ovaj događaj i njegov
event handler prihvata ili odbija porudžbinu.

slika preuzeta sa: https://microservices.io/patterns/data/saga.html

fi

OBRASCI ZA UPRAVLJANJE PODACIMA

SAGA OBRAZAC
• Implementacija orkestracijom
1. Order Service prima POST /orders zahtev i
kreira objekat Create Order saga orchestrator
2. Orkestrator kreira Order u PENDING stanju
3. Orkestrator šalje Reserve Credit komandu to
Customer Service-u
4. Customer Service pokušava da rezerviše
sredstva na računu
5. Customer Service šalje povratnu poruku sa
informacijom o rezultatu rezervacije
6. Orkestrator donosi odluku da ili odobri ili
odbije Order

slika preuzeta sa: https://microservices.io/patterns/data/saga.html

OBRASCI ZA UPRAVLJANJE PODACIMA

SAGA OBRAZAC
• Rezultati primene
• Dobre strane:
- Omogućava aplikaciji da obezbedi konzistentnost podataka među servisima, a da pri tome ne
koristi distribuirane transakcije.
• Loše strane:
- Komplikuje se programsko rešenje. Moraju se dobro osmisliti kompenzacione transakcije koje
poništavaju promene postignute u prethodnim koracima sage.
• Dodatni problemi:
- Kako bi se postigla pouzdanost, servis mora atomično ažurirati svoju bazu, a potom publikovati
poruku/događaj. Ne može se osloniti na tradicionalne mehanizme distribuiranih transakcija i
message brokere. Kako bi se to postoglo mora se osloniti na dodatne šablone (Event Sourcing,
Transactional Outbox, Aggreagates, Domain Events).

OBRASCI ZA UPRAVLJANJE PODACIMA

KOMPONOVANJE API-JA (API COMPOSITION)

• Kontekst u kome se koristi - Implementirana je mirkoservisna arhitektura, aza
čuvanje podataka obrazac jedne baze po servisu. Kao rezultat tog pristupa nije
više jednostavno prikupiti podatke koji pripadaju različitim servisima.

• Problem - Kako implementirati upite koji povlače podatke sa različitih

mikroservisa?

OBRASCI ZA UPRAVLJANJE PODACIMA

KOMPONOVANJE API-JA (API COMPOSITION)

• Rešenje - Upiti se realizuju tako što se definiše
komponenta koja radi kompoziciju API-ja (API
Composer). Ova komponenta poziva svaki
mikroservis ponaosob, a zatim obavlja spajanje
pojedinačnih rezultata u memorijskim strukturama
(in-memory) pre vraćanja rezultata krajnjem
korisniku.
• U praksi često komponenta koja je API
Gateway obavlja i ovu ulogu.

slika preuzeta sa: https://microservices.io/patterns/data/api-composition.html

OBRASCI ZA UPRAVLJANJE PODACIMA

KOMPONOVANJE API-JA (API COMPOSITION)

• Rezultati primene
• Dobre strane:
- Obezbeđuje jednostavan način da se u mikroservisnoj arhitekturi obave složeniji upiti.
• Loše strane:
- Neki upiti mogu rezultovati u velikim skupovima međurezultata i neefikasnom
obradom.

OBRASCI ZA UPRAVLJANJE PODACIMA

CQRS OBRAZAC
• CQRS - Command Query Responsibility Segregation
• Kontekst u kome se koristi - Implementirana je mirkoservisna
arhitektura, aza čuvanje podataka obrazac jedne baze po servisu.
Kao rezultat tog pristupa nije više jednostavno prikupiti podatke koji
pripadaju različitim servisima. Kada je implementiran i Event
Sourcing Pattern to čini upite nad podacima komplikovanim.
• Problem - Kako implementirati upite koji povlače podatke sa
različitih mikroservisa?

OBRASCI ZA UPRAVLJANJE PODACIMA

CQRS OBRAZAC
• Rešenje - Definisati bazu podataka samo za
čitanje, koja predstavlja repliku podataka
potrebnih da se podrži određeni upit.
• Aplikacija obezbeđuje da ova replika bude
uvek ažurna putem pretplate na
odgovarajuće događaje koje emituje onaj
mikroservis koji je vlasnik podataka.

slika preuzeta sa: https://microservices.io/patterns/data/cqrs.html

OBRASCI ZA UPRAVLJANJE PODACIMA

CQRS OBRAZAC
• Rezultati primene
• Dobre strane:
- Obezbeđuje podršku za više denormalizovanih upita pri čemu se obezbeđuju dobre
performanse i skalabilnost sistema.
- Pojačava se princip podele nadležnosti - što rezultuje jednostavnijim komandama i upitima.
- Neophodan je u arhitekturama koje su zasnovane na event sourcing-u.
• Loše strane:
- Povećava se kompleksnost sistema
- Moguće je dupliranje koda u različitim servisima.
- Kašnjenje pri replikaciji podataka.

OBRASCI ZA UPRAVLJANJE PODACIMA

DOMENSKI DOGAĐAJ (DOMAIN EVENT)

• Obrazac iz DDD (Domain Driven Development)
• Kontekst u kome se koristi - Servise često treba da objavi
događaj da je ažurirao svoje podatke. Primeri za to su u
prethodnom CQRS obrascu, kao i u koreografski zasnovanoj
sagi.
• Problem - Kako mikroservis objavljuje događaj nakon što je
ažurirao svoje podatke?

OBRASCI ZA UPRAVLJANJE PODACIMA

DOMENSKI DOGAĐAJ (DOMAIN EVENT)

• Rešenje - Organizovati poslovnu logiku servisa kao kolekciju
DDD agregata (aggregates - graf/hijerarhija objekata koja se
može posmatrati kao jedinstvena celina). Oni emituju
domenske događaje svaki put kada se kreiraju ili ažuriraju.
Servis objavljuje ove događaje tako da ih mogu obraditi drugi
servisni moduli.
OBRASCI ZA UPRAVLJANJE PODACIMA

EVENT SOURCING
• Kontekst u kome se koristi - Servisna komanda treba da ažurira bazu podataka i da emituje
poruku/događaj. Na primer servis koji učestvuje u saga obrascu treba atomično da ažurira
jedan bazi i nakon toga emituje poruku/dopgađaj o tome. Servis koji emituje domenski
događaj treba da atomično ažurira agregirani objekat i o tome emituje događaj.
Obe ove operacije - ažuriranje baze i samo slanje poruke/događaja - moraju se obaviti
nedeljivo, kako bi se izbegla nekonzistencija. Istovremeno, nije moguće koristiti distriburiane
transakcije preko više servisa i koristiti message broker da se objave ovakve izmene.
• Problem - Kako pouzdano/nedeljivo obaviti ažuriranje baze i objavu tog događaja?
• Faktori koji utiču na primenu
• Nije moguće koristiti 2PC

OBRASCI ZA UPRAVLJANJE PODACIMA

EVENT SOURCING
• Rešenje - Event sourcing podatke o stanju poslovnog entiteta čuva u stanju sekvence događaja koji
menjaju stanje (serija promena koja poslovni objekat dovode u tekuće stanje). Kad god se stanje objekta
promeni, novi događaj, koji opisuje tu promenu se doda na istu događaja. Kako je snimanje jednog
događaja atomična samo jedna operacija, ona je inherentno atomična. Aplikacija rekonstruiše stanje
objekata tako što izvršava sve događaje iz liste.
• Aplikacija pamti ove događaje / promene stanja u bazi izmena. Ova baza ima API za dodavanje ili čitanje
događaja za neki objekat. Ova baza se koristi i kao message broker jer obezbeđuje API kojim se servisi
mogu pretplatiti da slušaju izmene nad određenim objektima.
• Neki poslovni entiteti mogu da imaju veliki broj registrovanih događaja - izmena. Kako bi se optimizovalo
opterećenje aplikacija može periodično da napravi zamrznuti snimak (snapshot) stanja objekta. U tom
slučaju se za rekonstukciju stanja objekta koristi najnoviji snapshot i lista izmena nakon njega.

OBRASCI ZA UPRAVLJANJE PODACIMA

EVENT SOURCING
• Rezultati primene
• Dobre strane:
- Rešava ključne problem pri implementaciji event-driven arhitektura i čini pouzdanim objavljivanje događaja kad dođe do
promene stanja.
- Kako se čuvaju izmene, a ne sama stanja objekata, nema ni uobičajenih problema koji se mogu javiti pri ORM.
- Obezbeđuje 100% pouzdane provere izmena koje su nastale.
- Omogućava izvršavanje vremenskih upita kojima se može utvrditi stanje objekata u bilo kom momentu u vremenu.
- Poslovna logika bazirana na Event sourcingu sastoji se od slabo međusobno zavisnih poslovnih objekata koji razmenjuju samo
događaje informacije o promenama svog stanja. Ovo omogućava lakše migracije na novu arhitekturu.
• Loše strane:
- Programiranje sistema koji koriste ovakav pristup zahteva dodatno navikavanje i dosta je teško za učenje na početku.
- Upiti nad bazom događaja su dosta komplikovani, jer su neophodni precizni upiti kako bi se izvuklo stanje objekata u nekom
momentu u vremenu. Upiti su stoga često kompleksni i poprilično neefikasni.
- Kao rezultat ovih nedostataka, aplikacija skoro po pravilu koristi i CQRS kako bi obezbedila jednostavniji način za izvršavanje
složenih upita. Što opet zahteva održavanje ažurnih replika.

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

• Transakcioni outbox (aplikativni događaji)
• Praćenje kraja transakcionih logova (Transaction logs tailing)
• Pooling publisher

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSAKCIONI OUTBOX
• Kontekst u kome se koristi - Isti kao kod event sourcinga. Servisna komanda treba da ažurira
bazu podataka i da emituje poruku/događaj. Na primer servis koji učestvuje u saga obrascu
treba atomično da ažurira jedan bazi i nakon toga emituje poruku/dopgađaj o tome. Servis koji
emituje domenski događaj treba da atomično ažurira agregirani objekat i o tome emituje
događaj.
Obe ove operacije - ažuriranje baze i samo slanje poruke/događaja - moraju se obaviti
nedeljivo, kako bi se izbegla nekonzistencija. Istovremeno, nije moguće koristiti distriburiane
transakcije preko više servisa i koristiti message broker da se objave ovakve izmene.
• Problem - Kako pouzdano/nedeljivo obaviti ažuriranje baze i objavu tog događaja?
• Faktori koji utiču na primenu
• Nije moguće koristiti 2PC



OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSAKCIONI OUTBOX
• Rešenje - Servis koji koristi relacionu bazu poruke dodaje u outbox tabelu,
kao sastavni deo lokalne transakcije. Servis koji koristi NoSQL bazu
podataka dodaje poruke/događaje kao atribute zapisa. Poseban, proces za
slanje poruka Message Relay objavljuje ove poruke message brokeru.
OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSAKCIONI OUTBOX
• Rezultati primene
• Dobre strane:
- Servis objavljuje domenske događaje sikogo nivoa.
- Nije neophodan 2PC protokol.
• Loše strane:
- Potencijalno sklon greškama jer je moguće da se pri razvoju zaboravi odraditi objavljivanje
određenih poruka posle ažuriranja baza.
• Dodatni problemi:
- Message relay može objaviti neku poruku više od jedan put. Stoga ona komponenta koja
prima poruke mora biti dizajnirana kao idempotentna, ali srećom većina sistema za
konzumaciju poruka je takva.

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSACTION LOG TAILING

• Kontekst u kome se koristi - Implementiran je transaction
Outbox pattern.
• Problem - kako poruku koja je u outboxu emitovati/objaviti?

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSACTION LOG TAILING

• Rešenje - Konstantno pratiti promene na kraju transakcionog log fajla i
objaviti message brokeru svaku poruku insertovanu u outbox (tabelu).
OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSACTION LOG TAILING

• Rezultati primene
• Dobre strane:
- Nije neophodan 2PC protokol.
- Garantovano je tačno detektovanje izmena
• Loše strane:
- Poprilično slabo prihvaćeno rešenje, mada postaje sve poznatije i šire korišćeno.
- Zahteva rešenja koja su specifična za pojedine baze.
- Zahteva pažnju da se izbegnu višestruka objavljivanja.

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

POLLING PUBLISHER
• Kontekst u kome se koristi - Implementiran je transaction
Outbox pattern.
• Problem - kako poruku koja je u outboxu emitovati/objaviti?

OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSACTION LOG TAILING

• Rešenje - Poruke objavljivati tako što se periodično čita (polling) iz outbox
tabela.
OBRASCI ZA TRANSAKCIONU RAZMENU PORUKA

TRANSACTION LOG TAILING

• Rezultati primene
• Dobre strane:
- Jednostavno rešenje, primenljivo na sve relacione baze.
• Loše strane:
- Treba posebna pažnja da se obezbedi da se poruke preuzimaju i
objavljuju po redosledu.
- NoSQL baze možda ne podržavaju na jednostavan način ovako nešto.