ŠABLONI ZA RAZVOJ APLIKACIJA NA

MIKROSERVISNOJ ARHITEKTURI

XML i WS, Miroslav Zarić, FTN, 2020

bazirano na materijalima dostupnim na: https://microservices.io/patterns
 ŠABLONI (PATTERNS) - PONOVO

• Za razvoj složenih aplikacija dobro je koristiti već

ustanovljena dobra rešenja koja dovode do stabilnih, lako
održivih i ponovo upotrebljivih softverskih rešenja

• Mikroservisna arhitektura koju smo već analizirali takođe se

može posmatrati kao šablon - šablon arhitekture aplikacija
 ŠABLONI U MIKROSERVISNIM SISTEMIMA
• Mogu se podeliti na različite grupe šablona - svaki rešava određeni
aspekt razvoja sistema
• šabloni za dekompoziciju sistema u servise
- šabloni za refaktoring aplikacija u
mikroservisnu arhitekturu
• šabloni za upravljanje podacima u
mikroservisnim sistemima
• šabloni za transakcionu razmenu poruka
• šabloni za testiranje
• šabloni za instalaciju (isporuku -
deployment) aplikacije
• šabloni za eksterne API-je
• Cross cutting concerns šabloni
• eksternalizacija konfiguracije
• šabloni za pronalaženje servisa
• šabloni pouzdanosti sistema
• šabloni za sigurnost sistema
• Observability šabloni
• UI šabloni
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

• dekompozicija po poslovnim funkcionalnostima

• dekompozicija po poddomenima
• samostalan (self-contained) servis
• jedan servis po timu šablon
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE
DEKOMPOZICIJA PO POSLOVNIM FUNKCIONALNOSTIMA
• Kontekst u kome se koristi - razvoj kompleksne aplikacije uz opredeljenje da se ona razvije na
mikroservisnoj arhitekturi. Ovo podrazumevas strukturu aplikacije u formi slabo zavisnih servisa.
• Problem - kako dekomponovati sistem u servisne komponente?
• Faktori koji utiču na izbor rešenja
• Arhitektura mora biti stabilna. • Servisi treba da su slabo povezani - svaki servis
• Servisi moraju biti kohezivni. Jedan servis može da vidljiv je samo preko svog API-ja koji skriva
implementira mali skup međusobno povezanhi unutrašnju implementaciju.
funkcija. • Servis treba da je moguće nezavisno testirati.
• Servisi treba da su u skladu sa Common Closure • Treba da je dovoljno mali da zadovolji preporuku o
Principle - stvari čije izmene su međuzavisne “timu za dve pizze”.
(menjaju se zajedno) treba i da su upakovane u • Svaki tim koji je zadužen za servis mora biti
zajednički modul. autonoman (treba da može da razvija i deploye-uje
servis nezavisno od drugih timova).
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE
DEKOMPOZICIJA PO POSLOVNIM FUNKCIONALNOSTIMA
• Rešenje
• Definisati servise u skladu sa poslovnim funkcionalnostima
• Poslovna funkcionalnost je često direktno povezana sa
određenim tipovima poslovnih objekata (domenskih
podataka):
• upravljanje porudžbinama
• upravljanje finansijskim transakcijama…
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE
DEKOMPOZICIJA PO POSLOVNIM FUNKCIONALNOSTIMA
• Primer - online prodavnica mora podržati funkcionalnosti održavanja kataloga proizvoda, upravljanje
zalihama, upravljanje porudžbinama, upravljanje isporukama…

slika preuzeta sa: https://microservices.io/patterns/decomposition/decompose-by-business-capability.html

ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE
DEKOMPOZICIJA PO POSLOVNIM FUNKCIONALNOSTIMA
• Rezultat primene
• Stabilna arhitektura sistema, jer su poslovne funkcionalnosti često dosta stabilne -
relativno slabo promenljive.
• Razvojni timovi su višefunkcionalni, autonomni i organizovani tako da isporuče
određenu poslovnu funkcionalnost (više nego što su orijentisani samo na tehničke
detalje).
• Servisi razdvojeni na ovaj način su interno kohezivni, a međusobno slabo zavisni.
• Potenijalni problemi
• Kako tačno uočiti poslovne funkciopnalnosti? - Zahteva se razumevanje poslovnog
modela, a često i organizacione strukture, poslovnih procesa organizacije itd.
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

DEKOMPOZICIJA PO PODDOMENIMA
• Kontekst u kome se koristi - azvoj kompleksne aplikacije uz opredeljenje da se ona razvije na
mikroservisnoj arhitekturi. Ovo podrazumevas strukturu aplikacije u formi slabo zavisnih servisa.
• Problem - kako dekomponovati sistem u servisne komponente?
• Faktori koji utiču na izbor rešenja
• Arhitektura mora biti stabilna. • Servisi treba da su slabo povezani - svaki servis
• Servisi moraju biti kohezivni. Jedan servis može da vidljiv je samo preko svog API-ja koji skriva
implementira mali skup međusobno povezanhi unutrašnju implementaciju.
funkcija. • Servis treba da je moguće nezavisno testirati.
• Servisi treba da su u skladu sa Common Closure • Treba da je dovoljno mali da zadovolji preporuku o
Principle - stvari čije izmene su međuzavisne “timu za dve pizze”.
(menjaju se zajedno) treba i da su upakovane u • Svaki tim koji je zadužen za servis mora biti
zajednički modul. autonoman (treba da može da razvija i deploye-uje
servis nezavisno od drugih timova).
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

DEKOMPOZICIJA PO PODDOMENIMA
• Rešenje
• Definisati servise u skladu sa DDD (domain driven design) poddomenima. DDD definiše
domen - prostor problema koje aplikacija rešava. Domen se deli na poddomene, pri čemu
svaki od poddomena odgovara određenom delu poslovanja - rešava uži problem.
• Poddomene možemo klasifikovati kao:
• osnovni (core) - u ovom domenu se obavljaju ključne poslovne operacije (one bez kojih
poslovanje ne donosi nikakvu korist).
• pomoćni - u ovom domenu se obavljaju poslovne aktivnosti koje potpomažu osnovne
operacije, ali nisu ključne (mogu se i outsource-ovati).
• opšti (generički) - u ovom domenu obavljaju se poslovne aktivnosti koje su opšte - idealno
za podršku ovim aktivnostima koristiti neko generičko rešenje.
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

DEKOMPOZICIJA PO PODDOMENIMA
• Primer - domen poslovanja online prodavnice može se
podeliti na poddmene:
održavanje kataloga proizvoda, upravljanje zalihama,
upravljanje porudžbinama, upravljanje isporukama

slika preuzeta sa: https://microservices.io/patterns/decomposition/decompose-by-subdomain.html

ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

DEKOMPOZICIJA PO PODDOMENIMA
• Rezultat primene
• Stabilna arhitektura sistema jer su poslovne funkcionalnosti relativno slabo promenljive.
• Razvojni timovi su višefunkcionalni, autonomni i organizovani tako da isporuče određenu poslovnu
funkcionalnost (više nego što su orijentisani samo na tehničke detalje).
• Servisi razdvojeni na ovaj način su interno kohezivni, i međusobno slabo zavisni.
• Potenijalni problemi
• Kako tačno uočiti poddomene? - Zahteva se razumevanje poslovnog modela, a često i
organizacione strukture, poslovnih procesa organizacije itd.
Dobre polazne tačke za identifikaciju su:
• organizaciona struktura
• domenski model visokog nivoa
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

SAMOSTALAN (SELF-CONTAINED) SERVIS

• Kontekst u kome se koristi - kompleksna mikroservisna aplikacija kod koje izvršenje određenog klijentskog
zahteva podrazumeva saradnju više mikroservisnih modula, a klijent očekuje brz odgovor. Međuservisna
komunikacija se može obaviti kao serija sinhronih poziva, ali to ugrožava dostupnost servisa, a i vreme odziva.
• Problem - kako organizovati komunikaciju između servisnih komponenti kada obrađuju sinhroni klijentski zahtev?
• Faktori koji utiču na izbor rešenja:
• Mikroservisne arhitekture često dele odgovornost za obradu određenih klijentskih zahteva između više
različitih servisa od kojih svaki obavlja određeni deo posla.
• Operacija koju je klijent zahtevao treba da je visoko dostupna i da ima kratko vreme odziva.
• Dostupnost neke operacije se može izračunati kao proizvod dostupnosti svih servisa koji učestvuju u
izvršavanju operacije.
• U slučaju da je neki poziv neuspešan, servis može pokušati ponavljanje zahteva korespondirajućem servisu,
ali to sve produžava ukupno vreme odziva.
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

SAMOSTALAN (SELF-CONTAINED) SERVIS

• Rešenje
• Dizajnirati servis tako da može odgovoriti na sinhrone zahteve klijenta bez čekanja na odgovore
drugih komponenti.
• Jedan način da se ovo postigne jeste da se kompletna funkcionalnost složene operacije
implementira unutar jednog servisnog moduls (spajanjem postojećih servisa).
Ali to nije uvek (skoro nikad) dobro rešenje.
• Drugi način da se ovo implementira jeste da se saradnja između servisa obezbedi korišćenjem
drugih šablona (CQRS, SAGA). Na taj način samostalni servis bi koristio Saga šablon da
asinhronim (dakle neblokirajućim) porukama obezbedi konzistentnost podataka, a CQRS šablon
bi koristio da obezbedi (opet asinhrono) održavanje odgovarajuće replike podataka čiji je vlasnik
neki drugi servis, a ta replika datom servisu obezbeđuje visoku responzivnost (brz odziv).
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

SAMOSTALAN (SELF-CONTAINED) SERVIS

• Rešenje
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

SAMOSTALAN (SELF-CONTAINED) SERVIS

• Primer
• U aplikaciji za online naručivanje hrane, operacija za naručivanje hrane pretražuje CQRS repliku podataka
restoranske baze kako bi pročitala ponudu i cene, a zatim koristi SAGA šablon da kreira porudžbinu.

slika preuzeta sa: https://microservices.io/patterns/decomposition/self-contained-service.html

ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

SAMOSTALAN (SELF-CONTAINED) SERVIS

• Rezultat primene
• Dobre strane:
• Poboljšana dostupnost servisa vidljivog krajnjem korisniku, kao i vreme odziva.
• Loše strane:
• Povećanje kompleksnoti sistema zbog kreiranja replika (CQRS).
• Povećana kompleksnost zbog korišćemnja SAGA.
• Smanjenje jasnoće API-ja zbog korišćenja SAGA.
• Servisi postaju veći jer se deo funkcionalnosti ipak ugrađuje u samostalni servis
umesto da se uvek oslanja na dodatne servise.
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

JEDAN SERVIS PO TIMU

• Kontekst u kome se koristi - visokoefikasne kompanije za razvoj softvera su organizovane po timovima. Svaki tim je
relativno dugotrajan, mali po broju članova, slabo povezan sa ostalim timovima i multifunkcionalan. Conway-ov zakon
tvrdi da arhitektura rezultujućeg softvera direktno odslikava organizaciju timova koji su taj softver napravili. Mikroservisna
arhitektura zahteva slabo povezane timove. Pristup u kome određeni timovi rade deliće koda u više servisa nije prirodan
za ovakvu arhitekturu, jer se članovi tima angažuju u različitim projektima, zahteva se kooridnacija različitih timova,
progres u jednom timu može biti uslovljen raspoloživošću članova drugog tima. Bolji pristup od ovog tzv. shared
ownership modela je code/service ownership model u kome je jedan tim ekskluzivno nadležan za razvoj koda koji
implementira određeni servis. Idealno, tim bi u svakom momentu trebao da bude vlasnik samo jednog servisa.
• Problem - Kakav je odnos između timova i servisa?
• Faktori koji utiču na izbor rešenja:

• Timovi treba da su mali (5-9 ljudi).
• Tim treba da je autonoman i slabo zavisan od drugih
timova.
• Količina i složenost koda ne sme da prevazilazi kapacitet
tima
• Fino granulirani servisi poboljšavaju održivost, dostupnost
i mogućnost testiranja koda
• Ali fino granuliranje servisa povećava kompleksnost
celokupnog rešenja
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

JEDAN SERVIS PO TIMU

• Rešenje - Svaki servis je ekskluzivno u
vlasništvu samo jednog razvojnog tima.
Idealno svaki tim je odgovoran samo za jedan
servis.
• Timovi su vlasnici i jedini odgovorni za
održavanje koda koji obezbeđuje određene
poslovne funkcionalnosti.
• Kod koji održavaju je takvog obima da ne
prevazilazi kapacitet tima, a tim je odgovoran
za njegovo održavanje i deployment.

slika preuzeta sa: https://microservices.io/patterns/decomposition/service-per-team.html

ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

JEDAN SERVIS PO TIMU

• Rezultati primene
• Dobre strane
• Obezbeđuje autonomiju svakom timu pri čemu je za njihov rad dovoljna minimalna
koordinacija sa ostalim timovima.
• Omogućava da su timovi slabo međusobno zavisni.
• Poboljšava kvalitet koda jer se vlasništvo i održavanje koda fiksira na duže vreme za
određeni tim.
• Loše strane:
• Timovi mogu da izgube iz vida stvari koje se nude krajnjem korisniku.
• Implementacija funkcionalnosti koje se prostiru preko nekoliko servisa može biti
komplikovana i zahteva da se timovi usaglase i sarađuju.
 ŠABLONI ZA REFAKTORING MONOLITNE
U MIKROSERVISNU APLIKACIJU
• aplikacija “davitelj” (strangler application)
• sloj protiv korupcije (anti corruption layer)
ŠABLONI ZA REFAKTORING MONOLITNE U MIKROSERVISNU APLIKACIJU

STRANGLER APPLICATION
• Kontekst u kome se koristi - Postoji monolitna aplikacija, koja zahteva dalji razvoj
funkcionalnosti koji treba usmeriti na mikroservisnu arhitekturu.
• Problem - kako obezbediti tranziciju kompleksne monolitne aplikacija na novu mikroservisnu
arhitekturu i obezbediti prelazak na novije tehnologije?
• Faktori koji utiču na izbor ovog rešenja:
• aplikacija treba da koristi strukturu web aplikacija,
• individualni URI-ji se lako mapiraju na funkcionalnosti aplikacije,
• te funkcionalnosti se lako zamenjuju mirkoservisnom implementacijom koja se odaziva na
isti URL,
• moguće je sprovesti fazni prelazak: transformacija, koegzistencija parcijalno novog i starog
rešenja, eliminacija starog rešenja.
ŠABLONI ZA REFAKTORING MONOLITNE U MIKROSERVISNU APLIKACIJU

STRANGLER APPLICATION
• Rešenje - Aplikacija se sastoji od dva tipa
servisa, servisa koji implementiraju
funkcionalnost koja je već postojala u
prethodnoj monolitnoj aplikaciji, i servisa koji
implementiraju nove funkcionalnosti.
• Ovi drugi servisi su “driving force” koja
dokazuje validnost prelaska na novu
arhitekturu. Tokom vremena ostaci monolitne
aplikacije se gase.

slika preuzeta sa: https://microservices.io/patterns/decomposition/service-per-team.html

ŠABLONI ZA REFAKTORING MONOLITNE U MIKROSERVISNU APLIKACIJU

ANTI CORRUPTION LAYER

• Kontekst u kome se koristi - Ovaj šablon nije isključivo vezan za problem refactoringa monolitne u
mikroservisnu arhitekturu, već je potreban i kada se postojeći sistemi evolutivno razvijaju (dodaju
nove funkcionalnosti) i integrišu. Kada god imamo više sistema koji treba da komuniciraju, a nisu u
potpunosti usklađeni po pitanju protokola i sadržaja poruka, sloj protiv korupcije je dobro rešenje.
• Problem - kako obezbediti komunikaciju između nekompatibilinih ili parcijalno kompatibilnih
sistema, posebno legacy sistema i novih servisnih rešenja?
• Faktori koji utiču na izbor ovog rešenja:
• servis treba da obezbedi povezivanje sa legacy sistemima,
• servis treba da se integriše sa drugim sistemima koji koriste različite komunikacione protkole i/ili
različite reprezentacije podataka,
• ne postoji mogućnost ili je previše komplikovano usaglašavanje svih servisa i aplikacija na neki
standardni model komunikacije.
ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

ANTI CORRUPTION LAYER

• Rešenje - kreirati srednji sloj koji je sposoban da
obavi prevođenje (prilagođavanje) komunikacionog
protokola koji koristi prvi sistem na komunikacioni
protokol koji koristi drugi sistem (i po potrebi
obrnuto). Ovaj sloj se naziva Anti Corruption Layer,
jer sprečava korupciju podataka i pogrešno
razumevanje komunikacije koje bi se potencijalno
desile.
• Nije novi koncept - Enterprise Service Bus (ESB) sa
logikom koja se u njemu može podržati se može
koristiti kao ovaj srednji sloj.

slika preuzeta sa: https://medium.com/solutions-architecture-patterns/anti-corruption-layer-pattern-bd75e1f2be7f

ŠABLONI ZA DEKOMPOZICIJU SISTEMA U SERVISE

ANTI CORRUPTION LAYER

• Rezultati primene
• Dobre strane
• Otklanjanje potrebe da se sistemi prilagođavaju svakom sistemu sa kojim komuniciraju.
Prevod protokola se dešava u ovom sloju.
• Upravljanje greškama se takođe može ugraditi u ovaj sloj.
• Funkcionalnosti (legacy) aplikacije se ostatku sveta mogu učiniti dostupnim preko nekog
standardnog protokola, čak i kada aplikacija interno koristi drugačiji način komunikacije.
• Može da olakša pronalaženje servisa.
• Loše strane:
• Dodatni sloj u arhitekturi distribuiranih sistema.
• Neophodno je razviti logiku prevođenja komunikacije.
 ŠABLONI 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)
ŠABLONI 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 ovog rešenja:
• 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.
ŠABLONI 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
ŠABLONI 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.