OBRASCI (ŠABLONI) ZA RAZVOJ

APLIKACIJA NA MIKROSERVISNOJ
ARHITEKTURI - 3

XML i WS, Miroslav Zarić, FTN, 202

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

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

• Više instanci servisa po jednom hostu

• Jedna instanca servisa po jednom hostu
• Jedna instanca servisa na jednoj VM
• Jedna instanca servisa po kontejneru
• Implementacija bez servera (serverless deployment)
• Platforme za isporuku (deployment) servisa

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

• Ove pretpostavke važe za sva predložena rešenja
• Kontekst u kome se koriste- Aplikacija je razvijena korišćenjem mikroservisne arhitekture i sistem je skup servisa.
Svaki servis se instalira kao skup servisnih instanci kako bi se obezbedila neophodna raspoloživost i propusni opseg.
• Problem - Kako se spojedinačni servisi pakuju i isporučuju?
• Faktori koji utiču na izbor:
• Servisi su napisani na različitim jezicima i korišćenjem različitih razvojnih okvira i/ili verzija
• Svaki servis se isporučuje kroz više instanci servisnih modula
• Neophodno je obezbediti mogućnost nezavisne isporuke i skaliranja servisa.
• Pojedinačne istance servisa moraju biti međusobno izolovane
• Neophodne je obezbediti mogućnost brzog razvoja i isporuke servisa
• Neophodno je ograničiti resurse (CPU, memoriju) koje servis troši
• Neophodno je obezbediti mogućnost nadgledanja svakog servis
• Instalirani servis treba da je pouzdan
• Aplikacija treba da se isporuči maksimalno ekonomično

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

VIŠE INSTANCI SERVISA PO JEDNOM HOSTU

• Moguće rešenje - izvršavanje više instanci različitih servisa na istom host (fizičkom serveru ili
virtuelnoj mašini).
Postoji više načina da se obezbedi ovakva instalacija, neki od njih:
• instalirati pojedinačne servise kao nezavisne JVM procese (npr. jedan Tomcat server po
servisnoj instanci)
• instalirati više instanci servisa u istu JVM

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

VIŠE INSTANCI SERVISA PO JEDNOM HOSTU

• Rezultati primene
• Dobre strane:
- Dobro korišćenje raspoloživih resursa u odnosu na izbor jedne instance servisa po
hostu.
• Loše strane:
- Rizik od mogućeg utrkivanja za resurse.
- Rizik da se pojave oprečni zahtevi u pogledu verzija nekih biblioteka.
- Teško je ograničiti resurse dodelje pojedinačnim instancama servisa.
- Ukoliko je više instanci servisa instalirano u isti proces, teško je nadgledati korišćenje
resursa od strane pojedinačnih instanci, a i teško je obezbediti međusobnu izolaciju.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

JEDNA INSTANCA SERVISA PO JEDNOM HOSTU

• Moguće rešenje - Instalirati svaki servisnu instancu na sopstvenom hostu.
• Rezultati primene
• Dobre strane:
- Servisne instance su međusobno izolovane
- Nema mogućnosti za konflikte oko resursa ili oko verzija bilioteka
- Svaka instanca može konzumirati najviše onoliko resursa koliko nudi njen host
- Pojednostavljen je monitoring, reinstalacija i upravljanje svakom instancom servisa
• Loše strane:
- Potencijalno manje efikasna upotreba resura nego u slučaju više instanci servisa po hostu.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

JEDNA INSTANCA SERVISA PO JEDNOJ VM

• Moguće rešenje - Zapakovati servis kao sliku VM, i svaku servisnu instancu pokrenuti kao posebnu VM.
• Rezultati primene
• Dobre strane:
- Pojednostavljuje skaliranje servisa - prostim podizanjem nove instance VM (npr. Amazon Autoscaling Groups
ovo može obaviti automatski na osnovu opterećenja pojedinog servisa).
- VM enkapsulira tehnologiju korišćenu za razvoj servisa, Sve servisne instance se pokreću i zaustavljaju na isti
način.
- Servisne instance su međusobno izolovani.
- VM definiše limit upotrebe CPU i memorije
- IaaS rešenja (npr. AWS) obezbeđuju dobre alate za upravljanje VM (Elastic Load Balancer, Autoscaling groups)
• Loše strane:
- Proces pripreme VM je spor i zahtevan.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

JEDNA INSTANCA SERVISA PO JEDNOM KONTEJNERU
• Moguće rešenje - Zapakovati servise kao (Docker) sliku kontejnera (container image), pokretati svaku servisnu instancu kao
kontejner. Postoje i okruženja za upravljanje klasterima kontejnera (Kuberneti, AWS EC2 Container Services, Marathon/
Mesos)
• Rezultati primene
• Dobre strane:
- Pojednostavljeno je skaliranje servisa (naviše i naniže) - promenom broja aktivnih instanci kontejnera (servisnih
instanci).
- Kontejner enkapsulira sve tehnološke detalje servisa. Pokretanje i zaustavljanje svih servisa radi se na isti način.
- Izolacija svake servisne instance.
- Kontejner postavlja limite na raspoložive resurse za svaku servisnu instancu.
- Kontejneri se brzo grade i pokreću. Vreme pripreme kontejnerske slike, instalacije i pokretanja kontejnera je
višestruko brže od VM.
• Loše strane:
- Infrastrukturni alati za upravljanje kontejnerima su nešto manje bogati nego oni za upravljanje VM.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

IMPLEMENTACIJA BEZ SERVERA (SERVERLESS DEPLOYMENT)
• Moguće rešenje - koristiti neku od postojećih infrastruktura za isporuku servisnih
aplikacija. One “sakrivaju” koncept servera (rezervaciju resursa ili alokaciju resursa po
unapred zadatim uzorcima - zauzimanje fizičkog ili virtuelnog servera, ili kontejnera).
Sama infrastruktura prihvata KOD servisa i izvršava ga. Naplaćuje se po upućenim
zahtevima ka datom servisu.
Da bi se servis isporučio na ovaj način kod se pakuje, uploaduje na deployment
infrastrukturu i zadaju se željene specifikacije u pogledu performansi.
Deployment infrastruktura je uslužni servis koji nude ponuđač usluga računarstva u
oblaku (cloud provder-i). TIpično koriste bilo VM ili kontejnere za izolaciju pojedinih
servisa. Ali ovo je skriveno od krajnjeg korisnika. Nijedan korisnik ovakve usluge nije
zadužen da vodi računa o infrastrukturnim rešenjima (OS, VM…)




OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE
IMPLEMENTACIJA BEZ SERVERA (SERVERLESS DEPLOYMENT)
• Primeri: AWS Lambda, Google Cloud Functions, Azure Functions.
Svi nude slične funkcionalnosti mada je AWS lambda najraznovrsnija. AWS Lambda funkcija je stateless
komponenta koja se poziva da obradi određeni događaj. Kod za AWS Lambda funkciju se može napisati kao
NodeJS, Java, Python i uploaduje se kao .zip datoteka.
Kada se dogodi očekivani događaj AWS Lambda pronalazi slobodnu instancu funkcije (ili pokreće novu) i
izvršava njen kod. Uvek se obezbeđuje potreban broj instanci da se podrži opterećenje koje korisnici
stvaraju.
Funkciju je moguće trigerovati:
• događajem iz samog AWS-a (reagovati na neki od događaja koji generiše neki od AWS servisa),
• konfigurisanjem da se određeni HTTP zahtevi rutiraju na AWS Lambda funkciju putem AWS Lambda
Gatewaya,
• eksplicitnim pozvivom preko AWS Lambda Web Service API-ja,
• cron-like mehanizmom koji automatski poziva funkcije po unapred utvrđenom vremenskom rasporedu.



OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

IMPLEMENTACIJA BEZ SERVERA (SERVERLESS DEPLOYMENT)
• Rezultati primene
• Dobre strane:
- Uklanja potrebu da se obavlja zahtevno konfigurisanje infrastrukturnih detalja.
- Infrastruktura za podršku ovakvoj isporuci je jako elastična. Automatski se skalira u skladu sa potrebama.
- Plaća se po izvršenom zahtevu, a ne kao većina drugih po rezervisanim resursima (koji se možda i ne koriste u punoj meri uvek
npr. VM sa malo opterećenja).
• Loše strane:
- Ozbiljna ograničenja - mnogo veća nego kod VM ili kontejnera. Npr. podrška samo za nekoliko programskih jezika. Pogodne su
samo za stateless implementacije, nisu pogodne za statefull aplikacije koje bi se dugo izvršavale.
- Ograničen broj “ulaza” - lambde mogu reagovati samo na određene događaje iz određenih izvora.
- Aplikacija podržana na ovaj način mora jako brzo da se startuje - nisu pogodni za servise kojima treba mnogo vremena da se
dovedu u operativno stanje.
- Postoji rizik od relativno velike latentnosti - vreme koje je infrastrukturi potrebno da instancira funkciju, kao i vreme njene
inicijalizacije može biti osetno za krajnjeg korisnika. Infrastruktura za podršku funkcijama može samo reaktivno delovati na
povećanje opterećenja, ne može se delovati proaktivno (unapred rezervisati više instanci). Zbog toga je moguće osetno
povećanje kašnjenja u momentima kada se naglo poveća opterećenje.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

PLATFORME ZA ISPORUKU (DEPLOYMENT) SERVISA
• Moguće rešenje - Koristiti platforme za instalaciju servisa. One obezbeđuju apstrakciju
servisa - dobija se skup imenovanih, visokodostupnih (load balasiranih) instanci servisa.
• Primeri:
- okviri za orkestraciju Docker kontejnera (Docker Swarm, Kubernetes)
- Serverless platforme kao prethodno pomenuta AWS Lambda
- PaaS ponude kao npr. Cloud Foundry ili AWS Elastic Beanstalk

 OBRASCI ZA PRONALAŽENJE SERVISA

• Pronalaženje od strane klijenta (client-side discovery)
• Pronalaženje od strane servera (server-side discovery)
• Registar servisa
• Samoregistracija servisa
• Registracija posredstvom treće strane

 OBRASCI ZA PRONALAŽENJE SERVISA

• Ove pretpostavke važe za pronalaženje servisa i od strane klijenta i od strane servera
• Kontekst u kome se koriste - Servisi po pravilu imaju potrebu da međusobno komuniciraju (da pozivaju jedni druge).
U monolitnoj aplikaciji servisi mogu da pozovu usluge drugog servisa koristeći direktne pozive metoda na nivou
programskog jezika. U tradicionalnom distribuiranom sistemu, servisi rade na fiksnim dobro poznatim lokacijama (host/
port) i mogu lako pozvati jedan drugog preko RPC ili HTTP/REST poziva. U modernoj mikroservisnoj arhitekturi broj
instanci pojedinog servisa koji su na raspolaganju i njihova lokacija su promenljivi.
Mora postojati mehanizam koji omogućava klijentima da upute zahtev dinamički promenljivom skupu servisnih instanci.

• Problem - Kako klijent nekog servisa (API gateway ili neka druga servisna
komponenta koja nastupa u ulozi klijenta) može otkriti lokaciju servisne
instance servisa koji joj je potreban?
• Faktori koji utiču na izbor:
• Svaka instanca servisa ima javno dostupana API preko neke pristupne tačke
(HTTP/REST ili neki drugi protkol) na određenoj lokaciji (host i port)
• Broj instanci određenog servisa i njihova lokacija se menjaju tokom vremena
• VM i kontejneri po pravilu dobijaju dinamički dodaljene adrese.
slika preuzeta sa: https://microservices.io/patterns/server-side-discovery.html

OBRASCI ZA PRONALAŽENJE SERVISA

PRONALAŽENJE OD STRANE KLIJENTA (CLIENT-SIDE DISCOVERY)
• Moguće rešenje - Kada se poziva servis, klijent lokaciju servisa dobija tako što kontaktira servisni
registar, koji ima ažuran spisak lokacija na kojima je moguće pristupiti instancama servisa. Obično ovu
funkcionalnost obezbeđuje razvojni okvir za razvoj mikroservisnih aplikacija.
• Rezultati primene
• Dobre strane:
- Manji broj komponenti čije se lokacije menjaju
• Loše strane:
- Stvara se jaka zavisnost klijenta od servisnog registra.
- Neophodno je implementirati logiku pronalaženja
servisa u sam klijent, i to za svaki programski jezik
koji je korišćen za razvoj klijentskih aplikacija.

slika preuzeta sa: https://microservices.io/patterns/client-side-discovery.html

OBRASCI ZA PRONALAŽENJE SERVISA

PRONALAŽENJE OD STRANE SERVERA (SERVER-SIDE DISCOVERY)
• Moguće rešenje - Kada se poziva servis, klijent zahtev šalje posredstvom rutera (ima i ulogu balansiranja
opterećenja) kojem se pristupa preko dobro poznate adrese. Ruter proziva servisni registar kako bi saznao
stvarne adrese dostupnih instanci servisa. Primeri: AWS Elastic Load Balancer, Proxyji u Kubernetes…
• Rezultati primene
• Dobre strane:
- Pojednostavljen klijentski kod
- Ponuđači cloud usluga često nude ovu funkcionalnost
• Loše strane:
- Osim ako se koristi cloud okruženje, ruter je nova komponenta
koja se mora dodati u sistem i konfigurisati, a mora biti i
repliciran za obezbeđenje visoke dostupnosti i pouzdanosti.
- Ruter mora podržavati sve potrebne protokole.
- VIše mrežnih koraka između klijenta i servera.

slika preuzeta sa: https://microservices.io/patterns/server-side-discovery.html

OBRASCI ZA PRONALAŽENJE SERVISA

REGISTAR SERVISA
• Kontekst u kome se koriste - Klijent koristi mehanizam otkrivanja servisa (klijentski
ili serverski) kako bi pronašao lokaciju servisne instance servisa koji mu treba.
• Problem - Kako klijent(u slučaju pronalaženja od strane klijenta) i/ili ruteri (u slučaju
pronačlaženja od strane servera) može da utvrdi tačnu lokaciju raspoloživog servisa?
• Faktori koji utiču na izbor:
• Svaka instanca servisa svoj pristupni API (npr. HTTP/REST) mora učiniti dostupnim
na nekoj mrežnoj lokaciji.
• Broj servisnih instanci i njihova mrežna lokacija mogu da se menjaju.
• VM i kontejneri dobijaju dinamičke IP adrese.

OBRASCI ZA PRONALAŽENJE SERVISA

REGISTAR SERVISA
• Moguće rešenje - Implementirati registar servisa, u vidu baze podataka servisa, njihovih instanci i njihvoih
lokacija. Klijenti servisa vrše upit nad ovim registrom kako bi saznali tačne lokacije instanci servisa koji su im
potrebni. Sam registar može pozivati poseban API na servis instancama kako bi se uverio da su “žive i zdrave”.
Primer ovakvog registra je recimo Netflix Eureka.
• Rezultat primene
• Dobre strane
- Klijent je u mogućnosti da lako pronađe adresu dinamički alociranih servisnih instanci
• Loše strane
- Osim ako je registar deo servisne infrastrukture, ova komponenta se mora dodati u sistemsko rešenje,
podesiti i održavati.
- Servisni registar (ako se ništa ne preduzme) je kritična tačka sistema.
- Klijenti ne znaju unapred adrese pojedinačnih servisa, ali moraju znati adresu na kojoj se nalazi registar.
• Neophodno je dodatno razmotriti mehanizam registracije servisa u registar

OBRASCI ZA PRONALAŽENJE SERVISA

PROBLEM REGISTRACIJE SERVISA

• Kontekst u kome se koriste - Implementiran je neki od mehanizama za pronalaženje
servisa i postoji registar servisa. Instance servisa moraju se registrovati kod servisnog
registra po završetku svog pokretanja i odraditi deregistraciju prilikom zaustavljanja.
• Problem - Kako registrovati instance servisa na registru dostupnih servisnih instanci. I
kako ih odjaviti iz registra.
• Faktori koji utiču na izbor:
• Instance servisa moraju se registrovati prilikom pokretanja i odjaviti prilikom
zaustavljanja.
• Instanca servisa koja se tokom rada srušila mora se odjaviti iz registra.
• Servisne instance koje još uvek rade ali nisu u stanju da obrađuju zahteve, takođe
treba da se odjave iz registra.

OBRASCI ZA PRONALAŽENJE SERVISA

SAMOREGISTRACIJA SERVISA
• Moguće rešenje - Servisna instanca je sama odgovorna za prijavljivanje (registrovanje) kod registra servisa. Prilikom
pokretanja, u momentu kada je spremna da prihvati zahteve, servisna instanca se prijavljuje registru (saopštavajući svoju
adresu i port) što je čini vidljivom za proces pronalaženja. Klijent mora povremeno da obnovi registraciju čime se potvrđuje da
je još uvek aktivan (živ). Prilikom zaustavljanja servisna instanca se sama odjavljuje iz registra. Netflix Eureka koristi ovaj princip.
• Rezultat primene
• Dobre strane
- Instanca servisa zna svoje sopstveno stanje tako da jemoguće implementirati model stanja koji je detaljniji od prostog
UP/DOWN (STARTING, AVAILABLE, …)
• Loše strane
- Sam servis i servisni registar su jako spregnuti.
- Neophodno je implementirati kompletnu logiku za registraciju i odjavljivanje u svakom servisu (a to znači i u svakom
jeziku koji je korišćen za pisanje servisne komponente)
- Instanca servisa koja je pokrenuta, ali nije dostupna i sposobna za procesiranje zahteva vrlo često toga nije sama
svesna pa neće ni odraditi odjavu sa registra.

OBRASCI ZA PRONALAŽENJE SERVISA

REGISTRACIJA POSREDSTVOM TREĆE STRANE

• Moguće rešenje - Pomoćna (3rd party) komponenta koja služi kao registrator preuzima odgovornost za pravovremenu
registraciju instance servisa na registar i odjavljivanje instanci kada postanu nedostupne. Kada se instanca servisa pokrene,
registrtor prijavi tu instancu u registar, kada se instanca zaustavi registrator ukloni podatke o toj instanci iz registra. Netflix
Prana i AWS Autoscaling Group, kao i različiti alati za upravljanje klasterima ontejnera koriste ovaj princip.
• Rezultat primene
• Dobre strane
- Kod samog servisa se pojednostavljuje u odnosu na situaciju kada se radi sasmoregistracija.
- Regitrator može povremeno da proveri “zdravlje” servisa i da ga odjavi kada on prestane da se odaziva.
• Loše strane
- Registrator može da ima samo površno saznanje o internom stanju servisa, pa može biti uskraćen za informaciju da li
servis koji je RUNNING stvarno i sposoban da obrađuje zahteve koji mu se upute. Ipak ovo može da se prevaziđe
redovnom proverom “zdravlja” servisa.
- Osim u slučaju da je sam registrator deo infrastrukture - to je još jedna komponenta koju je potrebno dodati u sistem,
održavati i konfigurisati. A mora biti i visoko dostupan, jer njegov otkaz ceo sistem može učiniti nefunkcionalnim.

 CROSS CUTTING CONCERNS ŠABLONI

• Mikroservices chassis (mikroservisna šasija)
• Externalizacija konfiguracije

CROSS-CUTTING CONCERNS

MIKROSERVICES CHASSIS
• Kontekst u kome se koriste - Tokom razvoja aplikacije često se troši dosta vremena da se u sistem dodaju mehanizmi koji
obezbeđuju pomoćne funkcionalnosti, ali koji se moraju konfigurisati i povezati sa projektnim kodom.
• Konfigurisanje eksternih servisa (kredencijali, loakcije eksternih servisa - baza, message broker-a)
• Logovanje - konfigurisanje okvira za logovanje (log4j ili logback)
• Provera “zdravlja” komponenti - podešavanje monitoring servisa da može da prati rad određenih komponenti
• Metrika - podešavanje očitavanja raznih parametara koje omogućavaju merenje stanja aplikacije (utroška resursa,
performansi…)
• Praćenje eksternih pristupa
Podešavanje svega ovoga za veliku monolitnu aplikaciju čiji razvoj traje dugo je samo mali deo vremena koji će biti potrošen na
razvoj aplikacije, ali podešavanje svega ovoga pri razvoju neke mikroservisne arhitekture za svaki servis koji se razvija može
predstavljati neprihvatljivo veliki procenat uloženog truda u odnosu na razvoj samog rešenja.
• Problem - Kako obezbediti efikasno uključivanje ovakvih mehanizama u razvoj mikroservisa?
• Faktori koji utiču na izbor:
• Kreiranje mikroservisa trebalo bi biti lako i jednostavno i brzo.
• Neophodno je obezbediti podršku za neke od ovih mehanizama.

OBRASCI ZA INSTALACIJU (ISPORUKU - DEPLOYMENT) APLIKACIJE

MIKROSERVICES CHASSIS
• Moguće rešenje - Za razvoj mikroservisne aplikacije treba koristiti neki razvojni
okvir koji pruža podršku za pomenute mehanizme.
Primeri: Java Spring Boot, Spring Cloud, Go kit…
• Rezultat primene
• Dobre strane
- Osnovna prednost je što se omogućava brz i jednostavan start razvoja
mikroservisne aplikacije.
• Loše strane
- Neophodno je imati odgovarajući okvir za svaki programski jezik koji se koristi
za razvoj mikroservisnih modula.



CROSS-CUTTING CONCERNS

EKSTERNALIZACIJA KONFIGURACIJA
• Kontekst u kome se koriste - Aplikacija tipično koristi jedan ili više eksternih servisa
(registar servisa, baza podataka, email server, ….)
• Problem - Kako obezbediti mogućnost da se isti servis pokrene u različitim okruženjima
bez potrebe da se konfiguracija ovih servisa modifikuje u samom kodu projekta?
• Faktori koji utiču na izbor:
• Servis se mora isporučiti sa podešenom konfiguracijom za pristup eksternim servisima.
• Servis mora biti moguće pokrenuti u različitim okruženjima, bez potrebe da se
modifikuje i rekompajlira.
• Različita okruženja koriste različite instance eksternih servisa (različite baze i
kredencijale za njih, testno orkuženje nasuprot produkcionom…)

CROSS-CUTTING CONCERNS

EKSTERNALIZACIJA KONFIGURACIJA
• Moguće rešenje - Eksternalizovati sve konfiguracione podatke, Prilikom pokretanja servis
učitava konfiguraciju iz nekog eksternog izvora (OS varijable, property fajlovi i sl…). Npr.
korisšćenje servisnog registra rešava problem pronalaženja u runtime-u odgovarajućeg
servisa, ali i konfiguraciju servisnog registra treba sačuvati u nekom eksternalizovanom obliku.
• Rezultat primene
• Dobre strane
- Servis je moguće pokrenuti u različitim okruženjima bez potrebe da se modifikuje ili
rekompajlira.
• Loše strane
- Kako osigurati da kada se aplikacija pokrene u novom okruženju konfiguracija sadrži
sve neophodne podatke.

 OBRASCI ZA EKSTERNE API-JE

• API Gateway
• Backend for Frontend

 OBRASCI ZA EKSTERNE API-JE

• Kontekst u kome se koriste - Razvoj mikroservisne aplikacije koja da obezbedi više verzija za prikaz podataka krajnjim
korisnicima, npr. HTML kroz web aplikaciju za korisnike desktop i mobilnih browsera, i REST interfejs za korisnike koji
pristupaju aplikaciji preko native klijentskih aplikacija na iOS ili Androidu, a potrebno je obezbediti i REST API za klijente
razvijene nezavisno od same aplikacije.
Često je za prikaz podataka kranjem korisniku neophodno pristupiti podacima koji su u nadležnosti različitih
mirkoservisa.
• Problem - Kako klijenti mirkosesrvisne aplikacije pristupaju pojedinim servisima unutar nje?
• Faktori koji utiču na izbor:
• Granularnost API-ja mikroservisa se često ne podudara sa onim što klijent očekuje.
• Različiti klijenti očekuju različite podatke.
• Mrežni protok je potencijalno jako različit za različite tipove klijenata.
• Broj servisnih instanci i njihova lokacija se dinamički menjaju.
• Podela na servise se može tokom vremena promeniti, ali bi ta činjenica trebala biti sakrivena od krajnjih klijenata.
• Servisi mogu koristiti različite protokole, od kojih neki možda i nisu pogodni za krajnje klijente.

OBRASCI ZA EKSTERNE API-JE

API GATEWAY
• Moguće rešenje - Implementirati API Gateway koji je jedinstvena pristupna tačka za sve klijente. API
gateway može zahteve procesirati na dva načina:
- Neki od zahteva se samo proslede do odgovarajućih servisa.
- Druge zahteve obrađuje tako što na osnovu njih napravi više zahteva ka više različitih servisa.
Umesto da se pokuša obezbediti isti api za sve (one-size-fits-all), API gateway može “prikazati” različit
API za svaki tip klijenta. Na API gatewayu se mogu implementirati i sigurnosni mehanizmi.
• Rezultat primene
• Dobre strane
- Servis je moguće pokrenuti u različitim okruženjima bez potrebe da se modifikuje ili rekompajlira.
• Loše strane
- Kako osigurati da kada se aplikacija pokrene u novom okruženju konfiguracija sadrži sve
neophodne podatke.

OBRASCI ZA EKSTERNE API-JE

API GATEWAY
• Moguće rešenje - Implementirati API Gateway koji je
jedinstvena pristupna tačka za sve klijente. API gateway može
zahteve procesirati na dva načina:
- Neki od zahteva se samo proslede do odgovarajućih
servisa.
- Druge zahteve obrađuje tako što na osnovu njih napravi
više zahteva ka više različitih servisa.
Umesto da se pokuša obezbediti isti api za sve (one-size-fits-
all), API gateway može “prikazati” različit API za svaki tip
klijenta. Na API gatewayu se mogu implementirati i sigurnosni
mehanizmi.

slika preuzeta sa: https://microservices.io/patterns/apigateway.html

OBRASCI ZA EKSTERNE API-JE

BACKENDS FOR FRONTENDS

• Moguće rešenje - Varijacija API
gatewaya kod koje se za svaki tip klijenta
obezbeđuje poseban API gateway.

slika preuzeta sa: https://microservices.io/patterns/apigateway.html

OBRASCI ZA EKSTERNE API-JE

OBRASCI ZA EKSTERNE API-JE

• Rezultat primene
• Dobre strane
- Klijent se izoluje od strukture podele aplikacije na mikroservise.
- Klijent se izoluje od problema utvrđivanja lokacije servisnih instanci.
- Omogućava da se svakom klijentu ponudi optimalan API.
- Redukuje broj zahteva - ukoliko bi klijent morao sam da skuplja podatke sa svakog mikroservisa to bi iziskivalo više round-
trip mrežnog saobraćaja.
- Pojednostavljuje klijentske aplikacije jer se logika složenih zahteva razrešava u API gatewayu, umesto da klijent mora da
sam proziva više servisa.
- Omogućava prevođenje standardnih protokola u bilo koji koji servisi koriste interno.
• Loše strane
- Povećava kompleksnost.
- Povećava vreme odziva.
• Dodatni problem
- Kako implementirati sam API gateway? Događajima vođen pristup (reactive) je dobro rešenje.

 OBRASCI STILOVA KOMUNIKACIJE

• Remote Procedure Invocation • Domain-specific protocol
• Messaging • Idempotent Consumer

• Kontekst u kome se koriste - implementirana je mikroservisna arhitektura. Servisi moraju

obraditi klijentske zahteve. Servisi povremeno moraju i sarađivati (servis poziva servis). Mora se
koristiti neki komunikacioni protokol između servisa.
• Problem - Kakav stil komunikacije (protokol) koristiti za komunikaciju sa servisom?
• Faktori koji utiču na izbor:
• Servisi često imaju potrebu da pozivaju jedan drugog (sarađuju).
• Sinhrona komunikacija često rezultuje čvrstom vremenskom međuzavisnošću servisa - tokom
izvršavanja zahteva i servis i klijent moraju biti dostupni.

OBRASCI STILOVA KOMUNIKACIJE

REMOTE PROCEDURE INVOCATION

• Moguće rešenje - Koristiti RPI stil za interservisnu komunikaciju. Klijent koristi request/reply
(response) baziran protokol kako bi komunicirao sa servisom. Primeri: REST, gRPC, Apache Thrift
• Rezultat primene
• Dobre strane
- Jednostavna i dobro poznat
- Request/reply je jednostavan princip
- Jednostavniji sistem jer nema potrebe za message broker komponentama.
• Loše strane
- Obično se podržava samo request/reply, ali ne i drugi vidovi razmene poruka (notifikacije,
request/async response, publish/subscribe, publish/async response)
- Smanjuje dostupnost servisa jer su i klijent i server zauzeti tokom interakcije.

OBRASCI STILOVA KOMUNIKACIJE

SLANJE PORUKA (MESSAGING)

• Moguće rešenje - koristiti asinhronu razmenu poruka za interservisnu komuinikaciju. Ovo je moguće obezbediti na različite načine:
• Request/response - servis šalje zahtev i očekuje da dobije odgovor brzo
• Notifications - pošiljalac šalje poruku primaocu, ali ne očekuje odgovor, niti se nešto takvo šalje od strane primaoca.
• Request/asynchronous response - servis šalje zahtev primaocu i očekuje da nekad dobije odgovor
• Publish/subscribe - servis obajvljuje poruku na komunikacionom kanalu koju može preuzeti 0 ili više primaoca
• Publish/asynchronous response - servis objavljuje poruku na komunikacionom kanalu za 0 ili više priamoca, i očekuje da će neko
vratiti odgovor
Primeri su Apache Kafka, Rabbit MQ
• Rezultat primene
• Dobre strane
- Slaba međuzavisnost servisa
- Poboljšana dostupnost, jer message broker baferuje poruke
- Podržava više komunikacionih obrazaca
• Loše strane
- Povećana kompleksnost zbog logike u dodatnim komponentama

OBRASCI STILOVA KOMUNIKACIJE

DOMENSKI SPECIFIČAN PROTOKOL

• Moguće rešenje - Koristiti neki domenski specifičan protokol koji odgovara domenu u kome se
koriste servisi. Primeri: SMTP, RMTP…
• Rezultat primene
- omogućava da se koriste protokoli posebno prilagođeni određenoj nameni

OBRASCI STILOVA KOMUNIKACIJE

IDEMPOTENTNI PRIMALAC PORUKA

• Problem - Kako se primalac poruke ponaša kada primi duplikat neke poruke?
• Moguće rešenje - Implementirati idemopotentnog primaoca poruke, koji sadrži logiku za
obradu poruka koje su duplirane (ima logiku kojom može utvrditi da je ta poruka duplikat).
Neki korisnici poruka su po prirodi idempotentni, ali neki moraju pratiti neke specifične
osobine poruke da bi utvrdili da se radi o duplikatu i uklonili ga iz dalje obrade.

 OBRASCI POUZDANOSTI SISTEMA

• Circuit Breaker (osigurač)

• Kontekst u kome se koristi - Implementirana je mikroservisna arhitektura

aplikacije. Servisi tokom obrade klijentskih zahteva obavljaju interservisnu
komunikaciju. Pri tome moguće je da servis koji je pozvan bude privremeno
nedostupan ili jako usporen. U toj situaciji dragoceni resursi su možda nepotrebno
zauzeti jer onaj ko je pozvao servis čeka odgovor. Ukoliko se desi više ovakvih
poziva i pozivajući servis može postati nedostupan. Pad jednog servisa može
izazvati kaskadno urušavanje ostalih.
OBRASCI POUZDANOSTI SISTEMA

CIRCUIT BREAKER (OSIGURAČ)

• Problem - Kako sprečiti da pad jednog servisa ili mreže kaskadno sruši i ostale?
• Moguće rešenje - Klijenti servisu treba da pristupaju putem proxyja koji funkcioniše slično kao osigurač.
Kada je broj uzastopnih neuspelih poziva veći od nekog postavljenog praga, on sprečava sve dalje
pozive tom servisu za vreme trajanja timeout-a. Nakon tog vremena manji broj zahteva se propušta ka
servisu i ako oni uspeju nastavlja se normalan rad, u suprotnom počinje novi timeout period.
• Rezultat primene
• Dobre strane
- Servisi imaju mogućnost da obrade otkaze drugih servisa.
• Loše strane
- Često je dosta nezgodno utvrditi odgovarajuće vreme trajanja timeouta, a da to ne izaziva lažne
“pozitivne” detekcije neresponzivnosti servisa i time unese nepotrebno kašnjenje.

 OBRASCI SIGURNOSTI SISTEMA

• Access token (pristupni žeton)

• Kontekst u kome se koristi - Implementirana je mikroservisna arhitektura i

obrazac API gatewaya. Aplikacija se sastoji od brojnih servisa. API gateway je
jedina pristupna tačka za klijentske zahteve. On autentifikuje zahteve i prosleđuje
ih drugim servisima, koji opet mogu proslediti zahtev i nekom sledećem servisu.
OBRASCI SIGURNOSTI SISTEMA

ACCESS TOKEN (PRISTUPNI ŽETON)

• Problem - Kako obezbediti prosleđivanje identiteta korisnika koji je kreirao inicijalni zahtev u situaciji
kada se zahtev prosleđuje drugim servisima.
• Faktori koji utiču na izbor rešenja
• Pojedinačni servisi često treba da verifikuju da je određeni korisnik autorizovan da izvrši određenu
operaciju.
• Moguće rešenje - API Gateway autentifikuje korisnika i prosleđuje access token (npr. JSON Web Token)
koji identifikuje korisnika prilikom svakog zahteva servisima. Servis ovaj access token može uključiti i u
zahteve koje prosleđuje drugim servisima.
• Rezultat primene
• Identitet korisnika se na siguran način prosleđuje kroz sistem.
• Servisi mogu verifikovati ko je kreirao zahtev i proveriti da li je autorizovan da obavi određene
operacije.