SLAJD 1 - UVOD

U poslednje vreme se kod nas usvaja trend arhitekture mikroservisa i to

je tehnologija o kojoj se najvise prica u poslednje vreme.
Prihvacena je od strane mnogih vodecih organizacija sirom sveta.
Prvobitno je bila razvijena da resi ogranicenja monolitnih sistema i
karakterise je povecana skalabilnost, fleksibilnost i performanse.

Posto se aplikacije zasnovane na mikroservisima sastoje od nekoliko

razlicitih servisa cesto je potreban zajednicki interfejs ili gateway da
bismo pozvali sve servise.
Upravo za ovo koristimo api gateway. Ova prezentacija govori o
konceptima oko arhitekture mikroservisa i kako mozemo da radimo sa
api gatewayem da bismo imali dosledan nacin povezivanja
sa mikroservisima.

SLAJD 2 - STA JE MIKROSERVISNA ARHITEKTURA

Mikroservisna arhitektura je varijanta arhitekture orjentisana na servise

u kojoj aplikacija sadrzi kolekciju manjih, labavo povezanih, modularnih
servisa.
Servisi mogu biti izgradjeni za izvrsavanje na razlicitim platformama i
mogu biti nezavisno razvijeni, testirani i rasporedjeni.
Mikroservisna arhitektura moze da zameni dugotrajne, komplikovane,
monolitne sisteme koji zahtevaju znacajne resurse i troskove
upravljanja.

SLAJD 3 - STA JE GATEWAY API

Prilikom izrade aplikacija zasnovanih na mikroservisima, api gateway je

neophodan da bi imao centralno mesto gde se implementira
autentifikacija, orkestracija itd..
Bez api gatewaya obicno bismo morali da implementiramo svaki od njih
u svaki servis sto nam povecava troskove implementacije i odrzavanja.
Api Gateway odvaja servise od korisnika obezbedjujuci sloj za
bezbednost posto ne moramo direktno da izlazemo svoje servise.
Cim primi zahtev, moze da ga razbije na vise zahteva ako je potrebno i
onda da usmerava do nizvodnog mikroservisa.
Mozemo da iskoristimo prednosti Api Gatewaya da bismo
centralizovali, upravljali i nadgledali nefunkcionalne zahteve aplikacije,
orkestrirali visefunkcionalne mikroservise i smanjili
saobracaj. Dobrim upravljanjem zahtevima, api gateway moze pomoci u
smanjenju kasnjenja i poboljsanju bezbednosti.

Slika ispod ilustruje API gateway koji se koristi za povezivanje dva

nizvodna mikroservisa

SLIKA
Obicno korisnici mikroservisa ne komuniciraju direktno sa njim.
Umesto toga, Api Gateway obezbedjuje jednu ulaznu tacku za
usmeravanje saobracaja na razlicite mikroservise, kao sto je prikazano
na slici. Stoga klijenti nemaju nikakav direktni
pristup servisima i ne mogu ih koristiti. Ako je nas Api Gateway iza
firewall-a, mozemo dodati dodatni sloj zastite.

Api Gateway pattern izveden je iz 2 dizajn patterna. Facade i Adapter.

Kao i Facade pattern, api Gateway obezbedjuje Api korisnicima dok
enkapsulira internu arhitekturu.
Sa druge strane API Gateway omogucava komunikaciju kao u Adapter
dizajn patternu cak iako su interfejsi nekompatibilni.

SLAJD 4 - ZASTO NAM JE POTREBAN API GATEWAY

Ovde su glavni benefiti Gateway Apija:

1. Bolja izolacija - Api gateway obezbedjuje izolaciju sprecavanjem

direktnog pristupa internim problemima. Takodje APi Gateway
omogucava da dodamo vise mikroservisa ili da menjamo
granice bez uticaja na korisnike.
2. Poboljsana bezbednost - Api Gateway obezbedjuje bezbednosni sloj
za mikroservise koji moze pomoci u sprecavanju raznih napada (sql
injection, dos) itd.
U nasem slucaju Api Gateway moze da se koristi za autentifikaciju
korsnika. Ako na primer jednom korisniku potrebni podaci iz vise
mikroservisa, mi korisnika autentifikujemo samo jednom.
Tako smanjujemo kasnjenje i cinimo da nas mehanizam autentifikacije
bude isti na nivou cele aplikacije.

3. Metrika performansi - Posto je Api Gateway jedna komponenta kroz

koju teku svi requestovi i responsovi, to je odlicno mesto za prikupljanje
metrike. Na primer mozemo da merimo
broj i vreme izvrsenja zahteva koji su prosledjeni nizvodnim
mikroservisima.

4. Smanjena slozenost - Mikroservisi imaju specificne zajednicke

probleme koji ukljucuju evidentiranje, ogranicavanje brzine,
bezbednost itd
Trebace nam vise vremena da razvijemo ove funkcionalnosti u svakom
mikroservisu. Api Gateway moze eliminisati ovo dupliciranje koda cime
se smanjuje napor potreban za kreiranje novih
funkcionalnost.

SLAJD 5 - Reverse proxy i Gateway Api

Iako na prvi pogled deluju slicni, postoje velike razlike izmedju ova dva
pristupa.
Reverse proxy serveri uglavnom sede iza firewalla i usmeravaju zahteve
od klijenta do odgovarajuceg backend servera.
Reverse proxy je lagani gateway koji sadrzi nekoliko osnovnih
bezbednosnih i nadzornih mogucnosti. Dakle ako nam je potreban api
gateway sa osnovnim funkcijama, reverse proxy bi bio
dovoljan za nas. U tom slucaju moramo imati na umu to da reverse
proxy nije u stanju da izvrsi transformaciju ili orkestraciju.

Sa druge strane, api gateway se nalazi izmedju klijenta i skupa

pozadinskih mikroservisa i pruza mnogo opseznije mogucnosti
bezbednosti i nadgledanja u odnosu na reverse proxy.
Api Gateway pruza podrsku za sveobuhvatnu orkestraciju,
transformaciju i posredovanje. Takodje nudi i opseznu podrsku za
bezbednost transporta - mogo vise od jednostavnog proxyja.

SLAJD 6 - UVOD U OCELOT

U ovom primeru korisicemo Ocelot APi Gateway. Lagan, skalabilan i brz

API Gateway zasnovan na .Net Core i specijalno dizajniran za
arhitekturu mikroservisa.
U osnovi, to je skup middlewarea dizajniranog za rad sa Asp.Net Core.
Ima nekoliko funkcija kao sto su rutiranje, kesiranje, bezbednost,
ogranicavanje brzine itd...
SLAJD 7 - Read i Write API Aplikacija

Hajde da sada onda primenimo koncepte iz prethodnih slajdova

primenom konkretnog primera.
U ovom primeru cemo razmotriti minimalisticku aplikaciju zasnovanu
na mikroservisima. Ova aplikacija ce sadrzati Api Gateway i dva apija -
jedan za pisanje u bazu i drugi za citanje iz iste

====================================================PREZEN
TACIJA APLIKACIJE
==========================================================
=

SLAJD 8 - OCELOT Rate Limit

1. Client WhiteList - Niz koji se koristi da se specificiraju klijenti koji nece

biti afektnovani rate limitom
2. Enable RateLimit - Ukljuciti ili iskljuciti rate limit na nivou gatewaya
3. HttpStatusCode - Http status code koji se vraca korisniku kada se
predje rate limit
4. Period setting - Odredjuje vreme na koje se afektuje rate limit - ako u
okviru ovog tranjanja korisnik uputi vise zahteva nego sto je dozvoljeno,
morace da saceka trajanje navedeno u
period timespanu
5. Period Timespan - koristi se za odredjivanje trajanja nakon kojeg
korisnik moze ponovo da pokusa da se poveze na servis
6. Limit - maksimalan broj zahteva koji su navedeni u trajanju
navedenom u periodu

SLIKA PRIMER===

SLAJD 9 - KESIRANJE

Kesiranje je siroko popularna tehnika koja se koristi u veb aplkacijama

za cuvanje podataka u memoriji tako da se istim podacima moze brzo
pristupiti kada to aplikacija zahteva.
Ocelot pruza podrsku za osnovno kesiranje. Da bismo to iskoristili
trebalo bi da instaliramo Ocelot.Cache.CacheManager nuget paket.

SLAJD 10 - Auth0

Obezbedjivanje ASP.Net Core aplikacija pomocu Auth0 je jednostavno i

donosi mnogo sjajnih funkcija.
Sa Auth0 moramo da napisemo samo nekoliko redova koda da bismo
dobili solidno resenje za upravljanje identitetom, single sign on,
podrsku za provajdere sa drustvenih mreza
i podrsku za enterprice identity providere kao sto su aktivni
direktorijum, ldap, saml ili neki svoj custom.
SLAJD 11 - ZAKLJUCAK

Odabir prave arhitekture za potrebe naseg poslovanja je prvi i najvazniji

korak u izgradnji aplikacija koje su fleksibilne, skalabilne i visokih
performansi.
Jedna od najznacajnijih prednosti arhitekture mikroservisa je njena
podrska za heterogene platforme i tehnologije.

Nas Api Gatevay moze da upravlja problemima kao sto su bezbednost,

ogranicenje brzine, performanse i skalabilnost. Medjutim trebalo bi da
budemo svesni kompleksnosti svega toga.

PREDLOG
Prevod na engleski
Slide 4 – Validation I identity service