Mikroservisi intervju pitanja (Dubbo, Spring Cloud), 33 pitanja o mikroservisima (14.000 reči, 33 ručnocrtane slike), obavezno čitanje za poboljšanje intervjua👍

Sanfej8763 reči29 minuta

14.000 reči 33 ručnocrtane slike, detaljno objašnjenje 33 česta pitanja o mikroservisima (Dubbo, Spring Cloud) na intervjuu (neka učenja ne budu teška za pamćenje), kandidati koji nauče ova pitanja će zasigurno odgovoriti na intervju, verujem da je ovo sigurno (ručno dog). Organizovao: Chenmo Wang Er, pogledajte link za prepis, autor: Sanfej, pogledajte link originalnog teksta.

Pregled

1.Šta su mikroservisi?

Mikroservisi (Microservices) je arhitektonski stil softvera koji deli veliku aplikaciju na grupu malih, autonomih i loše povezanih servisa. Svaki mikroservis je odgovoran za izvršavanje specifične poslovne funkcije i sarađuje sa drugim servisima putem laganih mehanizama komunikacije (kao što je HTTP). Svaki mikroservis može se nezavisno razvijati, Deploy-ovati i proširivati, što čini aplikaciju fleksibilnijom, skalabilnijom i lakšem za održavanje.

U evoluciji mikroservis arhitekture, generalno može postojati pravac evolucije: monolitni->servisi->mikroservisi.

Monolitni servisi su generalno početni izgled svih projekata:

Monolitni servis (Monolithic Service) je tradicionalni način razvijanja softverske arhitekture gde se cela aplikacija razvija i deplojuje kao jedna jedinstvena, teško povezana jedinica. Monolitni servisi se obično sastoje od više modula koji dele istu bazu podataka i kodni repozitorijum. Međutim, kako se veličina aplikacije povećava, monolitni servisi mogu postati veliki i teški za održavanje, a deploj i proširenje su otežani.

Kasnije, monolitni servisi su postali preveliki, teški za održavanje i postepeno su evoluirali u distribuirani SOA:

SOA (Service-Oriented Architecture, servisno orijentisana arhitektura) je princip dizajniranja softverske arhitekture koji naglašava deljenje aplikacije na međusobno nezavisne servise koji komuniciraju preko standardizovanih interfejsa. SOA se fokusira na ponovnu upotrebu i kombinaciju servisa, ali ne definiše veličinu servisa.
Mikroservisi su dalji razvoj SOA-e i predstavljaju način deljenja i deploja servisa određene veličine. Arhitektura mikroservisi naglašava deljenje aplikacije na male, autonome i loše povezane servise, pri čemu se svaki servis fokusira na specifičnu poslovnu funkciju. Ova arhitektura čini aplikaciju fleksibilnijom, skalabilnijom i lakšem za održavanje.

Treba napomenuti da su mikroservisi specifičan arhitektonski stil, dok je SOA princip dizajna. Mikroservisi se mogu posmatrati kao konkretan način implementacije SOA koncepta, ali nisu identični sa SOA-om.

Razlika između mikroservisi i monolitnih servisa je u razmeri i načinu deploja. Mikroservisi dele aplikaciju na manje, autonomne servisne jedinice, pri čemu svaki servis ima svoju bazu podataka i kodni repozitorijum i može se nezavisno razvijati, testirati, deplojati i proširivati, što donosi veću fleksibilnost, održivost, proširivost i toleranciju na greške.

2.Koji izazovi donose mikroservisi?

Arhitektura mikroservisi nije univerzalno rešenje. Iako ima mnogo prednosti, treba razmotriti da li treba usvojiti arhitekturu mikroservisi ili podeliti postojeći monolitni servis, jer podela servisa može doneti određene izazove i probleme:

Povećanje složenosti sistema: Jedan servis je podeljen na više servisi, što povećava složenost celog sistema. Treba raditi na složenosti komunikacije između servisi, deploja, monitoringa i održavanja.
Troškovi komunikacije između servisi: Mikroservisi komuniciraju preko mreže, prenos podataka zahteva dodatne mrežne troškove i troškove serijalizacije, što može dovesti do performansnog uskog grla i povećanja kašnjenja sistema.
Konzistentnost podataka i upravljanje transakcijama: Svaki mikroservis ima svoju skladištenje podataka, pa konzistentnost podataka i upravljanje transakcijama preko više servisi postaje složenije. Treba dodatno rešavati probleme distribuiranih transakcija i sinhronizacije podataka.
Složenost deploja i operacija: Arhitektura mikroservisi uključuje više nezavisno deplojovanih servisi, što nameće više zahteva za deploj, monitoring i mehanizme tolerancije na greške. Treba uspostaviti odgovarajuće deploj cevi i automatizovane alate kako bi se pojednostavili procesi deploja i operacija.
Troškovi komunikacije i saradnje timova: Svaki mikroservis je odgovoran posebnog tima, što može povećati troškove komunikacije i saradnje između timova. Potrebni su efikasni kanali komunikacije i mehanizmi saradnje kako bi se osigurala koordinacija i konzistentnost između servisi.
Upravljanje servisima i upravljanje verzijama: Kako se broj mikroservisi povećava, upravljanje servisima i verzijama postaje složenije. Treba razmotriti registraciju i otkrivanje servisi, balansiranje opterećenja, monitoring i rukovanje greškama kako bi se osigurala pouzdanost i stabilnost celog sistema.
Složenost distribuiranih sistema: Arhitektura mikroservisi uključuje izgradnju i upravljanje distribuiranim sistemima, a distribuirani sistemi imaju neke inherentne izazove, kao što su mrežna kašnjenja, distribuirana konzistentnost i tolerancija na greške.

Jednostavno rečeno, usvajanje mikroservisi zahteva razmatranje ovih problema i izazova i birati odgovarajuće tehnološke rešenje prema stvarnim potrebama. Često monolitni servis može rešiti problem, ne treba praviti mikroservisi radi mikroservisi.

3.Koja su popularna rešenja za mikroservisi danas?

Trenutno postoje tri glavna otvorena rešenja za mikroservisi:

Dubbo:

Dubbo je performantni, lagani Java mikroservisni frejmvork, prvobitno ga je razvio Alibaba i 2011. godine objavio kao otvoreni kod. Pruža funkcionalnosti registracije i otkrivanja servisi, balansiranja opterećenja, tolerancije na greške, distribuiranih poziva i drugih funkcionalnosti. Kasnije je nakratko prestao sa održavanjem, ali u poslednje dve godine ponovo je počeo sa iteracijama i objavio Dubbo3.
Dubbo koristi komunikacioni model baziran na RPC (Remote Procedure Call) i ima visoke performanse i proširivost. Podržava više transportnih protokola (kao što su TCP, HTTP, Redis) i načina serijalizacije (kao što su JSON, Hessian, Protobuf) koji se mogu konfigurisati prema potrebama.
Dubbo se više smatra performantnim RPC (Remote Procedure Call) frejmvorkom, a neke funkcionalnosti upravljanja servisima zavise od komponenti trećih strana, kao što su ZooKeeper, Apollo i drugi.

Spring Cloud Netflix:

Spring Cloud Netflix je podprojekat Spring Cloud-a koji kombinuje više otvorenih komponenti kompanije Netflix, ali je Netflix 2018. godine prestao sa održavanjem i ažuriranjem Netflix OSS projekata, uključujući komponente kao što su Eureka, Hystrix, pa je i Spring Cloud Netflix postepeno ušao u režim održavanja.
Ovaj projekat uključuje mnoge popularne Netflix komponente, kao što su Eureka (registracija i otkrivanje servisi), Ribbon (klijentsko balansiranje opterećenja), Hystrix (breaker), Zuul (API gateway) i druge. Sve su to veoma proširive komponente za mikroservise potvrđene u velikoj praksi.

Spring Cloud Alibaba:

Koja je razlika između ova tri rešenja?

Razlika između tri rešenja:

Karakteristika	Dubbo	Spring Cloud Netflix	Spring Cloud Alibaba
Programski jezik	Java	Java	Java
Upravljanje servisima	Pruža potpune funkcionalnosti upravljanja servisima	Pruža delimične funkcionalnosti upravljanja servisima	Pruža potpune funkcionalnosti upravljanja servisima
Registracija i otkrivanje servisi	ZooKeeper/Nacos	Eureka/Consul	Nacos
Balansiranje opterećenja	Ugrađene strategije balansiranja opterećenja	Ribbon	Ribbon\Dubbo strategije balansiranja opterećenja
Pozivi servisi	RPC način	RestTemplate/Feign	Feign/RestTemplate/Dubbo
Breaker	Sentinel	Hystrix	Sentinel/Resilience4j
Konfiguracioni centar	Apollo	Spring Cloud Config	Nacos Config
API gateway	Higress/APISIX	Zuul/Gateway	Spring Cloud Gateway
Distribuirana transakcija	Seata	Ne podržava distribuirane transakcije	Seata
Ograničenje i degradacija	Sentinel	Hystrix	Sentinel
Distribuirano praćenje i monitoring	Skywalking	Spring Cloud Sleuth + Zipkin	SkyWalking ili Sentinel Dashboard
Mikroservisna mreža	Dubbo Mesh	Ne podržava mikroservisnu mrežu	Service Mesh (Nacos+Dubbo Mesh)
Aktivnost zajednice	Relativno visoka	Trenutno niža	Relativno visoka
Razvoj i zrelost	Raniji razvoj, veća zrelost	Veća zrelost	Noviji razvoj, ali brzo napreduje

Spring Cloud Alibaba je još jedan podprojekat Spring Cloud-a povezan sa Alibaba-jevim frejmvorkom za razvoj distribuiranih aplikacija. Pruža kompletan set rešenja integrisanih sa Alibaba ekosistemom.
Ovaj projekat uključuje komponente kao što su Nacos (registracija i otkrivanje servisi, upravljanje konfiguracijama), Sentinel (kontrola toka, breaker i degradacija), RocketMQ (red poruka) i druge, kao i integraciju sa Alibaba Cloud (Alibaba Cloud). Pruža bogate opcije za izgradnju arhitekture mikroservisi bazirane na Spring Cloud-u.
Navodi se da je initiator projekta SpringCloud Alibaba otišao u Tencent i pokrenuo projekat SpringCloud Tecent, pa postoji zabrinuost u razvoju zajednice.

Na intervjuu se o mikroservisima generalno najviše govori o Spring Cloud Netflix-u, zatim o Spring Cloud Alibaba-u, a o Dubbo-u se više govori kao o RPC frejmvorku.

4.Koje komponente imaju mikroservisi?

Mikroservisi donose neke probleme i izazove u razvoju sistema, kao što su složenost poziva servisi, rukovanje distribuiranim transakcijama, dinamično upravljanje servisima i drugo. Kako bi se bolje rešili ovi problemi i izazovi, pojavile su se razne komponente za upravljanje mikroservisima koje služe kao kamen i podrška arhitekture mikroservisi.

Razne komponente i uobičajene implementacije mikroservisi:

Registracioni centar: Koristi se za registraciju i otkrivanje servisi, upravlja informacijama o adresama mikroservisi. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Eureka, Consul
Spring Cloud Alibaba: Nacos

Konfiguracioni centar: Koristi se za centralizovano upravljanje informacijama o konfiguraciji mikroservisi, može dinamički menjati konfiguracije bez potrebe za restartovanjem servisi. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Spring Cloud Config
Spring Cloud Alibaba: Nacos Config

Distribuirani pozivi: Koriste se za komunikaciju i saradnju između različitih mikroservisi. Uobičajene implementacije uključuju:

RESTful API: kao što su RestTemplate, Feign
RPC (Remote Procedure Call): kao što su Dubbo, gRPC

API gateway: Kao ulaz u arhitekturu mikroservisi, jedinstveno izlaže servise i pruža funkcionalnosti rutiranja, balansiranja opterećenja, bezbedne autentifikacije i drugo. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Zuul, Gateway
Spring Cloud Alibaba: Gateway, Apisix i druge

Distribuirana transakcija: Osigurava konzistentnost i atomične operacije preko više mikroservisi. Uobičajene implementacije uključuju:

Spring Cloud Alibaba: Seata

Breaker: Koristi se za sprečavanje širenja grešaka između mikroservisi, poboljšava sposobnost tolerancije na greške sistema. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Hystrix
Spring Cloud Alibaba: Sentinel, Resilience4j

Ograničenje i degradacija: Koristi se za sprečavanje preopterećenja mikroservisi, vrši ograničenje i degradaciju zahteva. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Hystrix
Spring Cloud Alibaba: Sentinel

Distribuirano praćenje i monitoring: Koristi se za praćenje i monitoring toka zahteva i performansnih metrika mikroservisi. Uobičajene implementacije uključuju:

Spring Cloud Netflix: Spring Cloud Sleuth + Zipkin
Spring Cloud Alibaba: SkyWalking, Sentinel Dashboard

Registracioni centar

5.Šta radi registracioni centar?

Registracioni centar je komponenta koja upravlja i održava adrese i metapodatke svakog servisa u distribuiranom sistemu. Prvenstveno se koristi za realizaciju funkcionalnosti otkrivanja servisi i registracije servisi.

Rezime uloga registracionog centra:

Registracija servisi: Svaki servis pri pokretanju se registruje u registracioni centar svoju mrežnu adresu, informacije o instanci servisi i druge relevantne metapodatke. Na taj način drugi servisi mogu čerez registracioni centar dobiti listu trenutno dostupnih servisi.
Otkrivanje servisi: Klijent se upituje registracioni centar za registracione informacije o određenom servisu i dobija listu dostupnih instanci servisi. Na taj način klijent može prema potrebi izabrati odgovarajući servis za poziv i ostvaruje dekuplažu između servisi.
Balansiranje opterećenja: Registracioni centar može vršiti balansiranje opterećenja između više instanci istog servisa, distribuira zahteve na različite instance i poboljšava ukupne performanse i dostupnost sistema.
Oporavak od grešaka: Registracioni centar može pratiti i otkrivati stanje servisi. Kada se instanca servisi pokvari ili isključi, može blagovremeno ažurirati registracione informacije, čime osigurava da servisi mogu raditi normalno.
Upravljanje servisima: Čerez registracioni centar se mogu vršiti operacije upravljanja konfiguracijom servisi, dinamičkog proširenja/smanjenja, rutiranja servisi, kanarih izdanja i drugo, čime se ostvaruje dinamičko upravljanje i kontrola servisi.

6.Koji registracioni centri mogu se koristiti sa SpringCloud-om?

SpringCloud može da se integriše sa više registraionih centara. Uobičajeni registracioni centri uključuju:

Eureka: Eureka je Netflix-ov otvoreni frejmvork za otkrivanje servisi sa karakteristikama visoke dostupnosti, elastičnosti i proširivosti i dobro se integriše sa Spring Cloud-om.
Consul: Consul je sistem za otkrivanje distribuiranih servisi i upravljanje konfiguracijama koji je razvio HashiCorp. Pruža funkcionalnosti registracije servisi, otkrivanja servisi, zdravstvenih provera, skladištenja ključ-vrednost i drugo, a podržava deploj u više centara za podatke.
ZooKeeper: ZooKeeper je otvorena servis za distribuiranu koordinaciju Apache fondacije i može se koristiti kao registracioni centar. Ima karakteristike visoke dostupnosti, konzistentnosti i pouzdanosti.
Nacos: Nacos je Alibaba-jeva otvorena platforma za dinamičko otkrivanje servisi, upravljanje konfiguracijama i upravljanje servisima. Pruža funkcionalnosti registracije i otkrivanja servisi, upravljanja konfiguracijama, dinamičkog DNS servisi i drugo.
etcd: etcd je CoreOS-ov otvoreni distribuirani sistem skladištenja ključ-vrednost koji može se koristiti kao registracioni centar. Ima karakteristike visoke dostupnosti, jake konzistentnosti i distribuiranog replikovanja.

7.Koja je razlika između Eureka-e, ZooKeeper-a i Nacos-a?

Karakteristika	Eureka	ZooKeeper	Nacos
Kompanija razvoja	Netflix	Apache fondacija	Alibaba
CAP	AP (dostupnost i tolerancija particija)	CP (konzistentnost i tolerancija particija)	Podržava i AP, i CP
Funkcionalnost	Registracija i otkrivanje servisi	Distribuirana koordinacija, upravljanje konfiguracijama, distribuirana brava	Registracija i otkrivanje servisi, upravljanje konfiguracijama, upravljanje servisi
Pozicioniranje	Pogodan za izgradnju arhitekture mikroservisi bazirane na HTTP	Generički frejmvork za distribuiranu koordinaciju servisi	Pogodan za mikroservise i cloud-native aplikacije
Protokol pristupa	HTTP	TCP	HTTP/DNS
Samozaštita	Podržava	\-	Podržava
Skladištenje podataka	Ugrađena baza podataka, više instanci formira klaster	Distribuirani fajl sistem sa ACID svojstvima ZAB protokol	Ugrađena baza podataka, MySQL i drugi
Provera zdravlja	Client Beat	Keep Alive	TCP/HTTP/MYSQL/Client Beat
Karakteristike	Jednostavan za upotrebu, mehanizam samozaštite	Visoke performanse, jaka konzistentnost	Dinamičko upravljanje konfiguracijama, upravljanje tokom, canary izdanja i drugo

Vidimo da je najveća razlika između Eureka-e i ZooKeeper-a ta što jedna podržava AP, a druga CP, dok Nacos podržava i AP i CP.

8.Poznate li principi rada Eureka-e?

Principi rada Eureka-e mogu se posmatrati sa nekoliko aspekata:

Registracija i otkrivanje servisi: Kada se instanca servisi pokrene, ona šalje zahtev za registraciju Eureka Server-u i registruje svoje informacije u registracioni centar. Eureka Server čuva ove informacije u memoriji i pruža REST interfejs za druge servisi da ih query-ju. Potrošač servisi može putem query-ja liste instanci servisi dobiti dostupne instance providera servisi, čim ostvaruje otkrivanje servisi.
Provera zdravlja servisi: Eureka otkriva zdravstveno stanje instanci servisi putem mehanizma otkucaja srca. Instance servisi periodički šalju otkucaje srca Eureka Server-u, odnosno renew-ju, kako bi pokazale svoje stanje preživljavanja. Ako Eureka Server u određenom vremenu ne prim otkucaj srca od određene instance servisi, ona će biti označena kao nedostupna i uklonjena sa liste servisi, odnosno instanca će biti isključena.
Balansiranje opterećenja servisi: Eureka klijent pri pozivu drugih servisi dobija registracione informacije servisi iz lokalnog keša. Ako u kešu nema odgovarajućih informacija, šalje query zahtev Eureka Server-u. Eureka Server vraća klijentu listu dostupnih instanci servisi, a klijent može koristiti algoritam za balansiranje opterećenja da izabere jednu za poziv.

Ostali registracioni centri, kao što su Nacos, Consul i drugi, u pogledu registracije i otkrivanja servisi imaju principle rada koji je uglavnom isti.

9.Kako Eureka Server osigurava visoku dostupnost?

Eureka Server osigurava visoku dostupnost prvenstveno putem tri aspekta:

Deploj više instanci: Deplojanjem više Eureka Server instanci na različitim čvorovima može se ostvariti visoka dostupnost. Kada se jedna instanca pokvari, druge instance mogu i dalje pružati usluge i održavati konzistentnost registracionih informacija.
Replikovanje registracionih informacija servisi: Kada se instanca servisi registruje kod Eureka Server-a, svaka Eureka Server instanca replikuje registracione informacije drugih instanci kako bi održala konzistentnost podataka. Kada se jedna Eureka Server instanca pokvari, druge instance mogu preuzeti njen rad i osigurati normalno funkcionisanje celog sistema.
Mehanizam samozaštite: Eureka ima i mehanizam samozaštite. Kada Eureka Server čvor u određenom vremenu ne primi otkucaje srca, on ulazi u režim samozaštite. U režimu samozaštite Eureka Server više ne uklanja instance servisi iz registracione tabele, kako bi zaštitio postojeće registracione informacije. Na taj način se može sprečiti lažno uklanjanje zbog mrežnih treptanja ili drugih razloga i dodatno poboljšati stabilnost sistema.

Konfiguracioni centar

10.Zašto mikroservisi trebaju konfiguracioni centar?

Svaki servis u arhitekturi mikroservisi obično treba neke konfiguracione informacije, kao što su adrese baze podataka, portovi servisi, nivoi logovanja i drugo. Ove konfiguracije mogu zahtevati podešavanje i upravljanje zbog različitih okruženja, različitih instanci deploja ili dinamičkog runtime-a.

Instanci mikroservisi je obično veoma mnogo. Ako svaka instanca zahteva pojedinačno podešavanje ovih konfiguracija, operativni troškovi će biti veoma veliki. U tom slučaju potreban je centralizovan konfiguracioni centar za upravljanje ovim konfiguracijama.

11.Koji konfiguracioni centri mogu se koristiti sa SpringCloud-om?

Kao i kod registracionih centara, SpringCloud podržava integraciju sa više konfiguracionih centara. Uobičajeni izbori konfiguracionih centara uključuju:

Spring Cloud Config: Oficijelni preporučeni konfiguracioni centar, podržava skladištenje konfiguracionih fajlova u sistemima za kontrolu verzija kao što su Git, SVN i pruža RESTful API za pristup i upravljanje.
ZooKeeper: Otvorena distribuirana servis za koordinaciju, može se koristiti kao konfiguracioni centar. Ima karakteristike visoke dostupnosti, konzistentnosti i mehanizama obaveštavanja.
Consul: Još jedna otvorena alatka za otkrivanje distribuiranih servisi i upravljanje konfiguracijama, takođe može se koristiti kao konfiguracioni centar. Podržava više formata konfiguracionih fajlova, pruža proveru zdravlja, failover i dinamičke promene i druge funkcionalnosti.
Etcd: Distribuirani sistem skladištenja ključ-vrednost, može se koristiti kao konfiguracioni centar. Koristi mehanizam konzistentnosti baziran na Raft algoritmu i pruža garancije distribuirane konzistentnosti podataka.
Apollo: Otvoreni konfiguracioni centar kompanije Ctrip, podržava više programskih jezika i frejmvorkova. Pruža napredne funkcionalnosti kao što su fino zrnasto upravljanje pravima konfiguracije, obaveštenja o promenama konfiguracije i canary izdanja, a takođe i vizuelni interfejs za upravljanje konfiguracijama.
Nacos: Alibaba-jeva otvorena platforma za otkrivanje servisi, upravljanje konfiguracijama i upravljanje servisima, može se koristiti i kao konfiguracioni centar. Podržava registraciju i otkrivanje servisi, dinamičko upravljanje konfiguracijama, praćenje zdravlja servisi i dinamički DNS servisi i druge funkcionalnosti.

12.Poznati li principi rada Nacos konfiguracionog centra?

Konfiguracioni centar, u osnovi, je jedna rečenica: CRUD konfiguracionih informacija.

Konkretna implementacija se može podeliti na nekoliko delova:

Skladištenje konfiguracionih informacija: Nacos po default-u koristi ugrađenu bazu podataka Derby za skladištenje konfiguracionih informacija, može se koristiti i relaciona baza podataka kao što je MySQL.
Registracija konfiguracionih informacija: Pri pokretanju servisi, Nacos Client se registruje kod Nacos Server-a svoje konfiguracione informacije. Ovaj proces registracije zapravo upisuje konfiguracione informacije u skladište i generiše broj verzije.
Dobavljanje konfiguracionih informacija: Tokom rada servisi, Nacos Client dobija konfiguracione informacije sa Nacos Server-a putem API-ja. Server prema ključu pronalazi odgovarajuće konfiguracione informacije i vraća ih Client-u.
Praćenje promena konfiguracije: Nacos Client može putem registracije listener-a ostvariti praćenje konfiguracionih informacija. Kada se konfiguracione informacije promene, Nacos Server obaveštava registrovane listener-e i pokreće odgovarajuće callback metode.

13.Mehanizam dugog polling-a Nacos konfiguracionog centra?

Generalno, komunikacija između klijenta i servera može biti dva načina: guranje (Push) i vlačenje (Pull). Nacos na osnovi Pull-a koristi dugi polling za dinamičko osvežavanje konfiguracija.

U režimu dugog polling-a, klijent periodično šalje zahteve serveru da proveri da li su se konfiguracione informacije promenile. Ako nema promena, server će "zadržati" ovaj zahtev, odnosno privremeno neće vratiti rezultat, sve dok se konfiguracija ne promeni ili ne dostigne određeni timeout.

Konkretan proces implementacije je sledeći:

Klijent šalje Pull zahtev, server proverava da li su se konfiguracije promenile. Ako nema promena, postavlja se timer zadatak koji će se izvršiti posle određenog vremena i trenutna klijentska veza se dodaje u listu čekanja.
Tokom čekanja, ako se konfiguracija promeni, server će odmah vratiti rezultat klijentu i završiti jednu "push" operaciju.
Ako tokom čekanja nema promene konfiguracije, nakon što vreme čekanja dostigne predvećeni timeout, server će automatski vratiti rezultat klijentu, čak i ako konfiguracija nije promenjena.
Ako tokom čekanja, čerez Nacos Dashboard ili API izvršite izmenu konfiguracije, pokreće se mehanizam događaja, server će proći kroz listu čekanja, pronaći klijentsku vezu koja odgovara izmenjenoj stavci konfiguracije i vratiti izmenjene podatke čerez vezu, čime se završava jedna "push" operacija.

Through dugi polling, Nacos klijent može u realnom vremenu osetiti promene konfiguracije i blagovremeno dobiti najnovije konfiguracione informacije. U isto vreme, ovaj način smanjuje pritisak na server i izbegava zauzimanje memorijskih resursa velikim brojem dugih veza.

Distribuirani pozivi

14.Možete li reći koja je razlika između HTTP-a i RPC-a?

HTTP i RPC nisu stvari istog nivoa:

Sanfej poboljšanje intervjua: HTTP i RPC

HTTP je protokol aplikacionog sloja koji se koristi za prenos hipertekstualnih podataka, baziran na modelu zahtev-odgovor, često se koristi u Web razvoju, API pozivi i drugim scenama.

RPC je protokol za Distribuirano poziv procedura koji se koristi za realizaciju komunikacije između različitih čvorova u distribuiranom sistemu, baziran na modelu poziva metoda, često se koristi za izgradnju servisno orijentisane arhitekture mikroservisi.

U arhitekturi mikroservisi, Feign i Dubbo su frejmvorci za realizaciju distribuiranih poziva, Feign je baziran na HTTP protokolu, Dubbo na RPC protokolu.

Ako se Hard mora reći razlike, sledeće:

-	HTTP	RPC
Definicija	HTTP (HyperText Transfer Protocol) je protokol za prenos hiperteksta.	RPC (Remote Procedure Call) je protokol za realizaciju komunikacije između različitih čvorova u distribuiranom sistemu.
Način komunikacije	Baziran na modelu zahtev-odgovor, klijent šalje zahtev, server vraća odgovor.	Baziran na modelu poziva metoda, klijent poziva udaljenu metodu i čeka rezultat.
Transportni protokol	Baziran na TCP protokolu, može se koristiti i drugi transportni protokoli kao TLS/SSL za bezbedno kriptovanje.	Može koristiti razne transportne protokole, kao TCP, UDP i druge.
Format podataka	Baziran na tekstu, češći formati podataka su JSON, XML i drugi.	Može koristiti razne formate podataka, kao binary, JSON, Protocol Buffers i druge.
Definicija interfejsa	Koristi RESTful stil za definisanje interfejsa, češće metode su GET, POST, PUT, DELETE i drugi.	Koristi IDL (Interface Definition Language) za definisanje interfejsa, kao Protocol Buffers, Thrift i druge.
Međujezičnost	Podržava međujezičnu komunikaciju, može se koristiti HTTP kao komunikacioni protokol za realizaciju komunikacije između različitih jezika.	Podržava međujezičnu komunikaciju, može se koristiti IDL za generisanje klijentskog i serverskog koda različitih jezika.
Fleksibilnost	Više fleksibilan, pogodan za različite tipove aplikacijskih scena, kao Web razvoj, API pozive i drugo.	Više efikasan, pogodan za distribuirane sisteme koji zahtevaju visoke performanse i nisko kašnjenje.

Da li poznajete RPC?

RPC (Remote Procedure Call) je protokol za udaljeni poziv procedura koji se koristi za realizaciju komunikacije između različitih čvorova u distribuiranom sistemu. Baziran je na modelu poziva metoda i dozvoljava klijentu da poziva metodu udaljenog servisa i čeka povratak rezultata.

Kao gRPC, Dubbo, Thrift i drugi su RPC frejmvorci, oni pružaju IDL (Interface Definition Language) za definisanje servisnih interfejsa, kao i protokole serijalizacije za prenos podataka.

15.A koja je razlika između Feign-a i Dubbo-a?

Ova dva su stvari koje se mogu uporediti:

-	Feign	Dubbo
Definicija	Feign je deklarativni veb servis klijent koji pojednostavljuje pozive HTTP API-ja.	Dubbo je frejmvork za distribuirane servise za izgradnju servisno orijentisane arhitekture mikroservisi.
Način komunikacije	Baziran na HTTP protokolu, koristi RESTful stil za definisanje i pozive interfejsa.	Baziran na RPC protokolu, podržava više protokola serijalizacije kao gRPC, Hessian i druge.
Otkrivanje servisi	Obično se kombinuje sa registraionim centrom (kao Eureka, Consul) za otkrivanje i balansiranje opterećenja servisi.	Čerez ZooKeeper, Nacos i druge vrši registraciju i otkrivanje servisi i pruža funkcionalnost balansiranja opterećenja.
Upravljanje servisima	Ne pruža direktno funkcionalnosti upravljanja servisima, treba se kombinovati sa drugim komponentama ili frejmvorcima za upravljanje servisima.	Pruža funkcionalnosti registracije i otkrivanja servisi, balansiranja opterećenja, mehanizma tolerancije na greške, degradacije servisi i drugo.
Međujezičnost	Podržava međujezičnu komunikaciju, može se koristiti HTTP kao komunikacioni protokol za realizaciju komunikacije između različitih jezika.	Podržava međujezičnu komunikaciju, čerez Dubbo-jev IDL generiše klijentski i serverski kod različitih jezika.
Ekosistem	Integrisan sa Spring Cloud ekosistemom, bezdežno se integriše sa Spring Boot-om.	Poseduje kompletan ekosistem, uključujući registraione centre, konfiguracione centre, monitoring centre i druge komponente.
Prikladne scene	Pogodan za izgradnju RESTful arhitekture mikroservisi, posebno pogodan za HTTP mikroservis pozive.	Pogodan za izgradnju servisno orijentisane arhitekture mikroservisi, pruža kompletnije upravljanje servisima i mehanizme tolerancije na greške.

Treba napomenuti da Feign i Dubbo nisu međusobno isključivi. U stvari, Dubbo može koristiti HTTP protokol kao način komunikacije, a Feign se može integrisati sa RPC protokolom za distribuirane pozive. Izbor načina distribuiranog poziva zavisi od konkretnih poslovnih potreba i izbora tehnološkog steka.

16.Možete li reći nešto o Feign-u?

Feign je deklarativni veb servis klijent koji pojednostavljuje razvoj korišćenja udaljenih servisi baziranih na HTTP-u.

Feign je dalja kompletacija na osnovu RestTemplate-a i Ribbon-a, koristi RestTemplate za realizaciju Http poziva, koristi Ribbon za balansiranje opterećenja.

Glavne karakteristike i funkcionalnosti Feign-a uključuju:

Deklarativni API: Feign dozvoljava programerima da koriste jednostavne anotacije za definisanje i opisivanje pristupa udaljenim servisima. Through korišćenje anotacija, programeri mogu jednostavno specificirati URL, HTTP metod, parametre zahteva, zaglavlja zahteva i druge informacije, čime su distribuirani pozivi veoma intuitivni i laki za razumevanje.

@FeignClient(name = "example", url = "https://api.example.com")
 public interface ExampleService {
    @GetMapping("/endpoint"
    String getEndpointData();
 }

Integrisano balansiranje opterećenja: Feign je integrisao Ribbon balanceer opterećenja i može automatski ostvariti klijentsko balansiranje opterećenja. Može vršiti dinamičko rutiranje prema nazivu servisi i dostupnim instancama i distribuirati zahteve na različite instance servisi, čime poboljšava dostupnost i proširivost sistema.
Mehanizam tolerancije na greške: Feign podržava integraciju sa Hystrix frejmvorkom za toleranciju na greške i može pružati funkcionalnosti tolerancije i breakera pri pozivu udaljenih servisi. Kada udaljeni servis nije dostupan ili vreme odgovora je predugačko, Feign može brzo fails-ati i vratiti predefinisani rezultat, čim se izbegava kaskadno refuse na ceo sistem.

17.Zašto Feign-ov prvi poziv traje dugo?

Glavni razlog je Ribbon-ov mehanizam lazy loading-a. Kada se prvi put pozove, Feign će pokrenuti Ribbon-ov proces učitavanja, uključujući dobavljanje liste servisi iz registraionog centra, uspostavljanje pool-a konekcija i druge operacije. Ovaj proces učitavanja će povećati vreme prvog poziva.

ribbon:
   eager-load:
     enabled: true
       clients: service-1

Kako se rešava ovaj problem?

Može se pri pokretanju aplikacije pretopiti Feign klijent, automatski pokrenuti jedan nevažan poziv kako bi se unapred učitali Ribbon i druge srodne komponente. Na taj način se unapred vrši prvi poziv.

18.Kako Feign realizuje prenošenje autentifikacije?

Veoma uobičajen način je korišćenje interceptora za prenošenje autentifikacionih informacija. Može se implementirati interfejs RequestInterceptor za definisanje interceptora, u interceptoru se dodaju autentifikacione informacije u zaglavlje zahteva, zatim se registruje u Feign konfiguraciji.

@Configuration
 public class FeignClientConfig {

    @Bean
    public RequestInterceptor requestInterceptor() {
        return new RequestInterceptor() {
            @Override
            public void apply(RequestTemplate template) {
                // Dodavanje autentifikacionih informacija u zaglavlje zahteva
                template.header("Authorization", "Bearer " + getToken());
            }
        };
    }

    private String getToken() {
        // Logika za dobavljanje autentifikacionih informacija, može se dobiti iz SecurityContext ili drugih mesta
        // Povratak autentifikacionih informacija u string formatu
        return "your_token";
    }
 }

19.Kako Feign radi balansiranje opterećenja? Ribbon?

U Feign-u se balansiranje opterećenja realizuje through integraciju sa Ribbon-om.

Ribbon je Netflix-ov otvoreni klijentski balanceer opterećenja i može se bezdežno integrisati sa Feign-om, kako bi Feign-u dao sposobnost balansiranja opterećenja.

Ribbon dobija listu dostupnih servisi iz registraionog centra i through algoritam balansiranja opterećenja bira odgovarajuću instancu servisi za prosleđivanje zahteva, čim ostvaruje klijentsko balansiranje opterećenja.

20.Koji algoritmi balansiranja opterećenja postoje?

Uobičajeni algoritmi balansiranja opterećenja uključuju sledeće:

Algoritam kruglog rasporeda (Round Robin): Algoritam kruglog rasporeda je jedan od najjednostavnijih algoritama balansiranja opterećenja. On raspoređuje zahteve redom na svaki backend server, kružno. Kada stigne zahtev, balanceer opterećenja bira sledeći server prema unapred definisanom redosledu. Algoritam kruglog rasporeda je pogodan za scene gde backend serveri imaju istu sposobnost obrade i performanse.
Algoritam težinskog kruglog rasporeda (Weighted Round Robin): Algoritam težinskog kruglog rasporeda dodaje koncept težine na osnovu algoritma kruglog rasporeda. Svaki backend server dodeljuje se vrednost težine, što je veća težina, veća je verovatnoća da će biti izabran. Na taj način se može prema sposobnosti obrade i performansi servera podesiti raspodela zahteva, kako bi serveri sa višim performansama mogli obraditi više zahteva.
Algoritam nasumičnog izbora (Random): Algoritam nasumičnog izbora nasumično dodeljuje zahteve backend serverima. Svaki backend server ima jednaku verovatnoću izbora, bez razmatranja stvarnog opterećenja servera. Ovaj algoritam je jednostavan i brz, pogodan za scene gde performanse backend serveri su slične i ne treba razmatrati sposobnost obrade zahteva.
Algoritam težinskog nasumičnog izbora (Weighted Random): Algoritam težinskog nasumičnog izbora uvodi koncept težine na osnovu algoritma nasumičnog izbora. Svaki backend server dodeljuje se vrednost težine, što je veća težina, veća je verovatnoća da će biti izabran. Na taj način se može prema sposobnosti obrade i performansi servera podesiti raspodela zahteva.
Algoritam najmanje veze (Least Connection): Algoritam najmanje veze odlučuje o raspodeli zahteva prema trenutnom broju konekcija backend servera. Balanceer opterećenja će izabrati server sa najmanje brojem trenutnih veza za raspodelu zahteva, kako bi osigurao balans opterećenja backend servera. Ovaj algoritam je pogodan za scene gde sposobnosti obrade backend serveri su različite ili vremena obrade zahteva su različita.
Haš algoritam (Hash): Haš algoritam izračunava haš vrednost prema određenom specifičnom svojstvu zahteva (kao IP adresa klijenta, URL zahteva i drugo), zatim prema haš vrednosti bira odgovarajući backend server.

Uobičajeni balanceeri opterećenja, kao Ribbion, Gateway i drugi, generalno podržavaju ove algoritme balansiranja opterećenja.

Oko Dubbo-a će kasnije posebno izaći jedan broj.

Tolerancija na greške servisi

21.Šta je lavina servisi?

U mikroservisima, ako se jedan ili više servisi pokvare, u tom slučaju, ako zavisni servisi i dalje neprestano šalju zahteve ili retry-ju, pritisak ovih zahteva će se neprestano nakupljati u downstream-u, što dovodi do drastičnog povećanja opterećenja downstream servisi. Through neprestano nakupljanje može dovesti do daljeg pogoršanja kvarova, može doći do kaskadnog refuse, čak i do urušavanja celog sistema, to se zove lavina servisi.

Generalno, za sprečavanje lavine servisi mogu se koristiti sledeće mere:

Visoka dostupnost deploja servisi: Osigurati da svaki servis ima visoku dostupnost, through redundantni deploj, failover i druge načine kako bi se smanjio uticaj jednostrukih tačaka kvarova.
Ograničenje i breaker: Vršiti ograničenje i breaker zahteva između servisi kako bi se sprečilo da previše zahteva uđe u backend servis i učini ga nedostupnim.
Keš i degradacija: Razumno koristiti keš kako bi se smanjilo opterećenje backend servisi i po potrebi vršiti degradaciju servisi kako bi se osigurala dostupnost ključnih funkcionalnosti.

22.Šta je breaker servisi? Šta je degradacija servisi?

Šta je breaker servisi?

Breaker servisi je mehanizam tolerancije na greške u arhitekturi mikroservisi koji se koristi za zaštitu sistema od uticaja kvarova ili abnormalnih stanja servisi. Kada se neki servis pokvari ili pojavi abnormalno stanje, breaker servisi može brzo izolovati taj servis i osigurati da sistem bude stabilan i dostupan.

Through praćenje stanja poziva servisi, kada stopa grešaka ili vreme odgovora pređe prag, pokreće se mehanizam breakera, kasniji zahtevi će vratiti default vrednost ili informaciju o grešci, čime se izbegavaju gubitak resursa i urušavanje sistema.

Breaker servisi takođe podržava automatsko oporavakljanje i ponovni pokušaj poziva servisi sa greškama, osiguravajući da se nakon oporavka servisi nastavi koristiti.

Šta je degradacija servisi?

Degradacija servisi je takođe mehanizam tolerancije na greške u arhitekturi mikroservisi koji se koristi za osiguravanje dostupnosti ključnih funkcionalnosti kada su resursi sistema napeti ili se servisi pokvare.

Kada se u sistemu pojave abnormalne situacije, degradacija servisi će aktivni blokirati neke ne-ključne ili opcionalne funkcionalnosti, a pružati samo najosnovnije funkcionalnosti, kako bi se osiguralo stabilno funkcionisanje sistema. Through smanjenje zavisnosti od resursa, degradacija servisi može osigurati dostupnost i performanse sistema.

Može prema poslovnim potrebama i stanju sistema definisati strategije, na primer zameniti dugotrajne operacije, vratiti default odgovor, vratiti statičku stranicu greške i drugo.

Koja implementaciona rešenja za breaker i degradaciju postoje?

Trenutno postoji nekoliko uobičajenih implementacionih rešenja za breaker i degradaciju servisi:

Frejmvork	Implementaciono rešenje	Karakteristike
Spring Cloud	Netflix Hystrix	\- Pruža izolaciju thread-ova, degradaciju servisi, keš zahteva, spajanje zahteva i druge funkcionalnosti

\- Može se bezdežno integrisati sa drugim Spring Cloud komponentama

\- Zvanično je najavljeno da se prestalo sa održavanjem, preporučuje se korišćenje Resilience4j| |Spring Cloud|Resilience4j|\- Lagani frejmvork za breaker servisi

\- Pruža funkcionalnosti slične Hystrix-u

\- Ima bolje performanse i jednostavniji API

\- Može se bezdežno integrisati sa drugim Spring Cloud komponentama| |Spring Cloud Alibaba|Sentinel|\- Alibaba-jev otvoreni komponent za kontrolu toka i breaker degradaciju

\- Pruža realtime monitoring, kontrolu toka, breaker degradaciju i druge funkcionalnosti

\- Tesno integrisan sa Spring Cloud Alibaba ekosistemom| |Dubbo|Dubbo ugrađeni mehanizam breaker degradacije|\- Mehanizam breaker degradacije koji sam Dubbo frejmvork pruža

\- Može se through konfiguracija realizovati breaker servisi i degradacija

\- Tesno integrisan sa Dubbo-jevim RPC frejmvorkom|

23.Kako Hystrix realizuje toleranciju na greške servisi?

Iako se više ne ažurira, Hystrix je veoma klasična otvorena biblioteka za toleranciju na greške servisi, pruža više mehanizama za zaštitu sistema:

Hystrix šest glavnih mehanizama tolerancije na greške servisi

Breaker servisi (Circuit Breaker): Hystrix through postavljanje pragova prati stopy grešaka ili vremena odgovora servisi. Kada stopa grešaka ili vreme odgovora pređe predviđeni prag, breaker će se otvoriti, kasniji zahtevi neće biti poslati na stvarnog providera servisi, već će vratiti predefinisanu default vrednost ili informaciju o grešci. Na taj način se može brzo izolovati servis sa greškama, sprečiti širenje grešaka i poboljšati stabilnost i dostupnost sistema.
Degradacija servisi (Fallback): Kada se breaker otvori, Hystrix može pružiti rezervni metod degradacije ili vratiti default vrednost kako bi se osiguralo da se sistem nastavi normalno raditi. Programeri mogu definisati logiku degradacije, na primer return keširanih podataka, izvršavanje pojednostavljene logike ili poziv drugih pouzdanih servisi, kako bi se pružile ograničene ali dostupne funkcionalnosti.

import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand;

 /**
  * Primer degradacije servisi
 **/
 @Service
 public class MyService {

    @HystrixCommand(fallbackMethod = "fallbackMethod")
    public String myServiceMethod() {
        // Stvarna logika poziva servisi
        // ...
    }

    public String fallbackMethod() {
        // Logika metode degradacije, izvršiće se kada poziv servisi fails
        // Može vratiti default vrednost ili izvršiti drugu rezervnu logiku
        // ...
    }
 }

Keširanje zahteva (Request Caching): Hystrix može keširati rezultate istog zahteva, kada se sledeći put zatraže isti podaci, direktno ih dobija iz keša, čime se izbegavaju ponovljeni mrežni zahtevi i poboljšavaju performanse i brzina odgovora sistema.
Spajanje zahteva (Request Collapsing): Hystrix može spojiti više konkurentnih zahteva u jedan batch zahtev, čim se smanjuju mrežni troškovi i zauzimanje resursa. Ovo može efikasno smanjiti broj zahteva u nekim scenama visoke konkurencije i poboljšati performanse sistema.
Realtime monitoring i metrika (Real-time Monitoring and Metrics): Hystrix pruža funkcionalnosti realtime monitoringa i metrika koji mogu prati i statistički obrađivati stanje izvršavanja servisi, uključujući stopy grešaka, vremena odgovora, konkurentnost i druge metrike. Through monitoring podatke se mogu blagovremeno otkriti i rešiti problemi kvarova ili performansi servisi.
Izolacija thread pool-a (Thread Pool Isolation): Hystrix stavlja zahteve svakog zavisnog servisa u nezavisne thread pool-ove za izvršavanje, čime se izbegava da se zbog greška jednog servisa potroše svi thread resursi celog sistema. Through izolaciju thread pool-a može se poboljšati stabilnost i dostupnost sistema.

24.Kako Sentinel vrši ograničenje toka?

Sentinel through dinamičko upravljanje pravilima ograničenja toka, prema definisanim pravilima vrši ograničenje toka zahteva. Konkretni koraci implementacije su sledeći:

Definisanje resursa: U Sentinel-u, resursi mogu biti URL, metode i drugi, koriste se za identifikaciju zahteva koji treba ograničiti.

// Originalna poslovna metoda.
 @SentinelResource(blockHandler = "blockHandlerForGetUser")
 public User getUserById(String id) {
    throw new RuntimeException("getUserById command failed");
 }

 // blockHandler funkcija, poziva se kada se originalna metoda blokira (ograniči/degradira/sistemska zaštita)
 public User blockHandlerForGetUser(String id, BlockException ex) {
    return new User("admin");
 }

Konfigurisanje pravila ograničenja toka: U konfiguracionom fajlu Sentinel-a definišu se pravila ograničenja toka resursa. Pravila mogu uključivati naziv resursa, prag ograničenja toka, režim ograničenja (token bucket ili leaky bucket) i drugo.

private static void initFlowQpsRule() {
    List<FlowRule> rules = new ArrayList<>();
    FlowRule rule1 = new FlowRule();
    rule1.setResource(resource);
    // Set max qps to 20
    rule1.setCount(20);
    rule1.setGrade(RuleConstant.FLOW_GRADE_QPS);
    rule1.setLimitApp("default");
    rules.add(rule1);
    FlowRuleManager.loadRules(rules);
 }

Praćenje toka: Sentinel prati stanje toka svakog resursa, uključujući QPS zahteva (broj zahteva po sekundi), broj thread-ova, vreme odgovora i drugo.

Kontrola ograničenja toka: Kada stigne zahtev, Sentinel će prema pravilima ograničenja toka resursa odrediti da li treba vršiti ograničenje toka. Ako zahtev pređe prag ograničenja toka, može se ograničiti, odbiti ili izvršiti druge radnje degradacije.

Sentinel ukupni frejmvork-izvor zvanični sajt

Koji algoritam ograničenja toka Sentinel koristi?

Sentinel koristi algoritam ograničenja toka kliznog prozora za realizaciju ograničenja toka.

Algoritam ograničenja toka kliznog prozora je algoritam ograničenja toka baziran na vremenskom prozoru. On deli period vremena na više vremenskih prozora i u svakom vremenskom prozoru broji broj zahteva. Through dinamičko podešavanje veličine vremenskog prozora i koraka klizanja može se preciznije kontrolisati stopy prolaza zahteva.

Ograničenje toka kliznim prozorom može pogledati prethodni deo o distribuiranim sistemima.

Kako Sentinel realizuje klasterno ograničenje toka?

Sentinel koristi mehanizam Token Server i Token Client za realizaciju klasternog ograničenja toka.

Nakon što se omogući klasterno ograničenje toka, Client šalje zahtev Token Server-u, Token Server prema konfigurisanim pravilima odlučuje da li će ograničiti tok.

Servisni gateway

25.Šta je API gateway?

API Gateway je vrsta middleware servera koji se koristi za centralizovano upravljanje, zaštitu i rutiranje pristupa backend servisima. Djeluje kao tačka ulaza između klijenta i backend servisi i pruža jedinstvene interfejse za upravljanje i kontrolu pristupa API-jima.

Glavne funkcionalnosti API gateway-a uključuju:

Rutiranje i prosleđivanje: API gateway prema URL putanji zahteva ili drugim identifikatorima router zahteve u odgovarajuće backend servise. Through konfigurisanje pravila rutiranja može se fleksibilno distribuirati zahteve na različite backend servise.
Balansiranje opterećenja: API gateway može između backend servisi realizovati balansiranje opterećenja, prosečno distribuira zahteve na više instanci i poboljšava propustnost i proširivost sistema.
Bezbedna autentifikacija i avtorizacija: API gateway može centralizovano obrađivati autentifikaciju i avtorizaciju, osiguravajući da samo autentifikovani klijenti mogu pristupati backend servisima. Može se integrisati sa providere identiteta (kao OAuth, OpenID Connect) za obavljanje korisničke autentifikacije i avtorizacije.
Keširanje: API gateway može keširati odgovore backend servisi, smanjiti broj zahteva backend servisi i poboljšati performanse i brzinu odgovora sistema.
Monitoring i logovanje: API gateway može prikupljati i beležiti metrike i logove zahteva, pružati realtime praćenje i analizu, pomažući programerima i operaterima pri troubleshoo-tingu i optimizaciji performansi.
Transformacija podataka i protokolska konverzija: API gateway može između klijenta i backend servisi vršiti konverziju formata podataka i konverziju protokola, na primer konvertovanje zahteva iz HTTP u WebSocket, ili konvertovanje parametara zahteva kako bi se zadovoljile potrebe backend servisi.
Upravljanje verzijama API-ja: API gateway može upravljati različitim verzijama API-ja, dozvoljava istovremeno postojanje više API verzija i through pravila rutiranja ispravno router zahteve u odgovarajuću API verziju.

……

Through korišćenje API gateway-a može se pojednostaviti interakcija između frontenda i backend servisi, pružiti uniformne interfejse i garancije bezbednosti, a takođe olakšati upravljanje servisima i monitoring. To je jedna od ključnih komponenti za izgradnju arhitekture mikroservisi i realizaciju upravljanja API-jima.

26.Koji API gateway mogu se koristiti sa SpringCloud-om?

Za razvoj sa SpringCloud-om mogu se koristiti sledeći API gateway izbori:

Netflix Zuul (prestao sa ažuriranjem): Netflix Zuul je default API gateway koji se pružao u ranim verzijama Spring Cloud-a. Baziran je na Servlet tehnologiji, može vršiti rutiranje, filtriranje, balansiranje opterećenja i druge funkcionalnosti. Međutim, od decembra 2020. godine, Netflix je najavio prestanak održavanja Zuul 1 i prešao na podršku novog projekta API gateway-a.
Spring Cloud Gateway: Spring Cloud Gateway je oficijelni preporučeni API gateway kompanije Spring Cloud, zamenio je Netflix Zuul. Baziran je na neblokirajućem WebFlux frejmvorku, punu iskorišćuje prednosti reactive programiranja i pruža funkcionalnosti rutiranja, filtriranja, breakera, ograničenja toka i drugo. Spring Cloud Gateway takođe podržava integraciju sa drugim Spring Cloud komponentama, kao što su otkrivanje servisi, balansiranje opterećenja i drugo.
Kong: Kong je nezavisan, cloud-native API gateway i platforma za upravljanje servisima, može se integrisati sa Spring Cloud-om. Kong je baziran na Nginx-u, pruža moćne mogućnosti rutiranja, autentifikacije, avtorizacije, monitoringa i proširivosti. Podržava razne plugin-e i proširenja, može zadovoljiti različite potrebe upravljanja API-jima.
APISIX: APISIX je razvijen na osnovu Nginx-a i Lua-e, ima moćne funkcionalnosti rutiranja, kontrole toka, proširenja plugin-a i drugo. APISIX podržava fleksibilne načine konfigurisanja, može prema potrebama vršiti dinamičko rutiranje, balansiranje opterećenja i ograničenje toka i druge operacije.

……

27.Ključni koncepti Spring Cloud Gateway-a?

U Spring Cloud Gateway-u postoje tri ključne komponente:

Route (ruta): Ruta je osnovna gradivna jedinica Spring Cloud Gateway-a, definiše pravila podudaranja zahteva i metu prosleđivanja. Through konfigurisanje ruta može se mappirati zahteve na instance backend servisi ili URL-e. Pravila ruta se mogu podudarati prema uslovima kao što su putanja, metod, zaglavlja zahteva i drugo, i specifcirati metu URI za prosleđivanje.
Predicate (predikat): Predikat se koristi za podudaranje uslova zahteva, ako zahtev zadovoljava uslove predikata, biće primenjen konfigurisani filter. Spring Cloud Gateway pruža više ugrađenih predikata, kao Path (podudaranje putanje), Method (podudaranje metoda), Header (podudaranje zaglavlja) i drugi, a takođe podržava custom predikate.
Filter (filter): Filter se koristi za obradu i transformaciju zahteva, može menjati zahtev, odgovor i izvršavati druge custom logike. Spring Cloud Gateway pruža više ugrađenih filtera, kao što su prosleđivanje zahteva, retry zahteva, ograničenje toka zahteva i drugi. Takođe podržava custom filtere, prema potrebama se može napisati vlastita logika filtera.

Hajmo da ćemo još pogledati konkretni tok rada Spring Cloud Gateway-a:

SpringCloud tok rada-izvor zvanična dokumentacija

Postoje još dve relativno važne koncepte:

Gateway Handler (gateway procesor): Gateway Handler je ključna komponenta Spring Cloud Gateway-a, odgovorna za prosleđivanje zahteva na podudarajuću rutu. On vrši podudaranje ruta prema konfiguraciji ruta i uslovima predikata, bira odgovarajuću rutu za prosleđivanje zahteva. Gateway Handler takođe primenjuje lanak konfigurisanih filtera redom kako bi obradio i transformisao zahtev.
Gateway Filter Chain (lanak filtera gateway-a): Lanac filtera gateway-a se sastoji od niza filtera koji se izvršavaju redom prema konfiguraciji. Svaki filter može obraditi pre zahteva, posle zahteva ili kdo se zahtev pokvari. Izvršavanje lanca filtera može menjati zahtev, odgovor i izvršavati druge custom logike.

Praćenje lanca

28.Zašto treba koristiti praćenje lanca mikroservisi?

U mikroservisima, neki downstream može biti desetak servisi, ako se jedna karika pokvari, troubleshootng je veoma težak, stoga treba vršiti praćenje lanca kako bi se pomaglo pri rešavanju problema.

Through praćenje lanca može se vizuelno prati tok poziva iz jednog mikroservisa na drugi. Pored rešavanja problema, praćenje lanca takođe može pomoći pri optimizaciji performansi, vizuelizaciji odnosa zavisnosti, monitoringu servisi i alarm-ovima.

29.Koja rešenja za praćenje lanca mikroservisi mogu se koristiti sa SpringCloud-om?

Spring Cloud pruža više rešenja za praćenje lanca mikroservisi. Neka od uobičajenih rešenja su:

Zipkin: Zipkin je otvoreni sistem za realtime distribuirano praćenje koji je razvio Twitter i dao otvorenoj zajednici. Spring Cloud Sleuth pruža integraciju sa Zipkin-om, može through dodavanje odgovarajućih zavisnosti i konfiguracija u mikroservise slali informacije praćenja Zipkin serveru i through Zipkin UI vršiti vizuelni prikaz i query.

Jaeger: Jaeger je Uber-ov otvoreni sistem za distribuirano praćenje, takođe je uključen u održavanje CNCF-a (Cloud Native Computing Foundation). Through korišćenje Spring Cloud Sleuth i Jaeger klijent biblioteka može se slati informacije praćenja Jaeger-u i vršiti vizuelni prikaz i query.
SkyWalking: Apache SkyWalking je otvoreni sistem za monitoring i analizu performansi aplikacija, pruža podršku za Java, .NET i Node.js i druge jezike. Može se integrisati sa Spring Cloud Sleuth-om, slati podatke praćenja na SkyWalking server za vizuelni prikaz i analizu.

Pinpoint: Pinpoint je Naver-ov otvoreni sistem za monitoring performansi distribuiranih aplikacija, podržava Java i .NET. Pruža integraciju sa Spring Cloud Sleuth-om, može slati podatke praćenja na Pinpoint server i through njegov UI vršiti analizu i monitoring.

Sva ova rešenja mogu se integrisati sa Spring Cloud Sleuth-om, Spring Cloud Sleuth je komponenta u Spring Cloud-u koja pruža sposobnost generisanja informacija praćenja pri pozivu mikroservisi.

Distribuirane transakcije

Distribuirane transakcije mogu pogledati prethodni deo o distribuiranim osnovama.

30.Koje modove distribuiranih transakcija podržava Seata?

Seata podržava nekoliko modova distribuiranih transakcija:

AT (Atomikos) mod: AT mod je default mod koji Seata podržava i jedan od najčešće korišćenih. U AT mod-u, Seata through ugrađivanje konteksta transakcija u poslovni kod ostvaruje upravljanje i koordinaciju distribuiranih transakcija. Seata će interceptirati i parsirati SQL naredbe u poslovnom kodu, through interceptor i proxy konekcije baze podataka ostvariti upravljanje i koordinaciju transakcija.

TCC (Try-Confirm-Cancel) mod: TCC mod je mod distribuiranih transakcija baziran na mehanizmu kompenzacije. U TCC mod-u poslovna logika treba da implementira operacije tri faze: Try, Confirm i Cancel. Seata through pozive Try, Confirm i Cancel metoda u poslovnom kodu i beleženje logova o operacijama u svakoj fazi ostvaruje konzistentnost distribuiranih transakcija.

SAGA mod: SAGA mod je mod distribuiranih transakcija baziran na event-driven načinu. U SAGA mod-u svaki servis može objavljivati i pretplatiti događaje, through prenos i obradu događaja ostvaruje konzistentnost distribuiranih transakcija. Seata pruža SAGA frejmvork kompatibilan sa SAGA mod-om za upravljanje i koordinaciju različitih faza distribuiranih transakcija.

XA mod: XA mod je mod distribuiranih transakcija baziran na protokolu Two-Phase Commit. U XA mod-u Seata through interakciju sa XA transakcijskim protokolom baze podataka ostvaruje upravljanje i koordinaciju distribuiranih transakcija. XA mod zahteva da sama baza podataka podržava XA transakcije i u aplikaciji treba konfigurisati odgovarajući XA dataSource.

31.Poznate li principi implementacije Seata-e?

Principi implementacije Seata-e uglavnom uključuju tri ključne komponente: koordinator transakcija (Transaction Coordinator), menadžer transakcija (Transaction Manager) i menadžer resursa (Resource Manager).

Koordinator transakcija (Transaction Coordinator): Koordinator transakcija je odgovoran za koordinaciju i upravljanje celim procesom distribuirane transakcije. Prima zahteve za početak i kraj transakcije i prema stanju transakcije vrši koordinaciju i obradu. Koordinator transakcije takođe odgovoran za beleženje i upravljanje globalnim ID-om transakcije (Global Transaction ID) i ID-om grana transakcije (Branch Transaction ID).
Menadžer transakcija (Transaction Manager): Menadžer transakcije je odgovoran za upravljanje i kontrolu globalnih transakcija. Koordinira commit ili rollback svake grane transakcije i osigurava konzistentnost i izolaciju distribuiranih transakcija. Menadžer transakcije takođe komunicira sa koordinatorom transakcija i trajno beleži promene stanja transakcije.
Menadžer resursa (Resource Manager): Menadžer resursa je odgovoran za upravljanje i kontrolu operacija transakcije svakog učesnika (Participant). Komunicira sa menadžerom transakcija i prema instrukcijama menadžera transakcije izvršava odgovarajuće operacije transakcije, uključujući commit i rollback.

Principi implementacije Seata-e su bazirani na Two-Phase Commit protokolu, konkretni mehanizmi su sledeći:

Jedna faza: Tokom procesa commit transakcije, prvo se vrši faza pre-commit. Koordinator transakcije šalje pre-commit zahtev svakom menadžeru resursa, menadžeri resursa izvršavaju odgovarajuće operacije transakcije i vraćaju rezultate izvršenja. U ovoj fazi se poslovni podaci i logovi rollback-a upisuju u istoj lokalnoj transakciji i oslobađaju se lokalne brave i resursi konekcije.
Dve faze: Nakon uspešne pre-commit faze, ulazi se u pravu commit fazu. Ova faza uglavnom uključuje dva koraka: asinhronu commit i obratnu kompenzaciju rollback-a:

Asinhrona commit: Koordinator transakcije šalje stvarni commit zahtev, svi menadžeri resursi izvršavaju konačnu commit operaciju. Operacije ove faze su veoma brze kako bi se osigurala efikasnost commit transakcije.
Obratna kompenzacija rollback-a: Ako bilo koji menadžer resursa u pre-commit fazi vrati neuspešan rezultat, koordinator transakcije šalje rollback zahtev, svi menadžeri resursi izvršavaju rollback operacije, koristeći logove rollback-a iz jedne faze za obratnu kompenzaciju.

Kakav je tok izvršavanja transakcije u Seata-i?

Tok izvršavanja transakcije u Seata-i može se kratko rezimirati u sledeće korake:

Inicijator transakcije (Transaction Starter) pokreće globalnu transakciju: Inicijator transakcije je aplikacija ili servis koji pokreće distribuiranu transakciju. Šalje zahtev za početak globalne transakcije Seata-inom koordinatoru transakcije, generiše globalni ID transakcije (Global Transaction ID).
Koordinator transakcije kreira zapis globalne transakcije: Nakon što koordinator transakcije primi zahtev za početak globalne transakcije, kreira odgovarajući zapis globalne transakcije i generiše ID grane transakcije (Branch Transaction ID).
Registracija grane transakcije: Inicijator transakcije šalje globalni ID transakcije i ID grane transakcije svakom učesniku (Participant), odnosno menadžeru resursa. Učesnici registruju ID grane transakcije kod lokalnog menadžera transakcija i vraćaju rezultat izvršenja transakcije koordinatoru transakcije.
Izvršavanje poslovne logike: U kontekstu distribuirane transakcije svaki učesnik izvršava svoju lokalnu transakciju, to je izvršavanje poslovne logike i operacija nad bazom podataka.
Faza pre-commit: Inicijator transakcije šalje pre-commit zahtev koordinatoru transakcije, koordinator transakcije šalje pre-commit zahtev svakom učesniku.
Izvršavanje potvrde lokalne transakcije: Nakon što učesnik primi pre-commit zahtev, izvršava operaciju potvrde lokalne transakcije i vraća rezultat izvršenja lokalne transakcije koordinatoru transakcije.
Commit ili rollback globalne transakcije: Koordinator transakcije prema rezultatima povratnika učesnika odlučuje, ako su sve lokalne transakcije učesnika uspešno izvršene, koordinator transakcije šalje stvarni commit zahtev učesnicima, učesnici izvršavaju konačnu commit operaciju; ako bilo koja lokalna transakcija učesnika fails, koordinator transakcije šalje rollback zahtev učesnicima, učesnici izvršavaju rollback operacije.
Završavanje globalne transakcije: Nakon što koordinator transakcije primi rezultat commit ili rollback učesnika, prema rezultatu ažurira stanje globalne transakcije i obaveštava inicijatora transakcije o konačnom rezultatu globalne transakcije.

Kako se prenose globalni ID transakcije i ID grane transakcije?

Globalni ID transakcije i ID grane transakcije se u distribuiranim transakcijama prenose through prenos context-a. Uobičajeni načini prenosa uključuju prenos parametara, prenos context-a thread-a i prenos through middleware poruka. Konkretan način prenosa može se izabrati i podesiti prema poslovnim scenama i tehnološkom izboru.

Kako se vrši rollback transakcije u Seata-i?

Rollback transakcije u Seata-i se vrši through logove rollback-a. Svaki učesnik tokom lokalne transakcije generiše logove rollback-a koji beleže operacije izmena podataka.

Kada se treba izvršiti rollback transakcije, koordinator transakcije šalje rollback zahtev učesnicima, učesnici through informacije u logovima rollback-a izvršavaju operacije opoziva, vraćaju podatke u stanje pre početka transakcije.

Upravljanje i skladištenje logova rollback-a je ključni mehanizam Seata-e, može se izabrati skladištenje logova u različitim medijumima. Through trajno skladištenje i oporavak logova rollback-a, Seata osigurava konzistentnost i oporavljivost transakcija.

Monitoring servisi

32.Kako vršite monitoring i alarm-ove svojih servisi?

Mi koristimo Prometheus i Grafana za realizaciju monitoringa i alarm-ova celog klastera mikroservisi:

Prometheus: Prometheus je otvoreni sistem za monitoring sa fleksibilnim modelom podataka i moćnim query jezikom, može prikupljati i skladištiti time-series podatke. Može through HTTP protokol periodično povlačiti metričke podatke mikroservisi i pružati proširivo skladištenje i query mogućnosti.
Grafana: Grafana je alatka za vizuelne dashboard-e koja se može koristiti sa Prometheus-om za kreiranje realnih i istorijskih dashboard-a podataka. Grafana pruža bogate grafikone i opcije vizuelizacije, pomaže korisnicima da bolje razumeju i analiziraju performanse i stanja mikroservisi.

33.Kako vršite prikupljanje logova svojih servisi?

Postoji više rešenja za prikupljanje logova, mi koristimo ELK:

Elasticsearch: Elasticsearch je distribuirani sistem za pretragu i analizu engine za skladištenje i indeksiranje velikih količina log podataka. Pruža brzu pretragu i agregacione funkcionalnosti, može efikasno obrađivati velike količine log podataka.
Logstash: Logstash je alatka za prikupljanje, filtriranje i prosleđivanje log podataka. Može prikupljati log podatke iz različitih izvora (kao fajlovi, mreža, red poruka i drugi), obrađivati i transformisati podatke, zatim ih slati u Elasticsearch za skladištenje i indeksiranje.
Kibana: Kibana je alatka za vizuelizaciju i analizu log podataka. Pruža bogate grafikone, dashboard-e i search funkcionalnosti, može pomoći korisnicima da u realnom vremenu monitoriju i analiziraju log podatke, otkrivaju potencijalne probleme i trendove.

Jednostavno rečeno, u ova tri dela Elasticsearch pruža sposobnost skladištenja i pretrage podataka, Logstash je odgovoran za prikupljanje logova u ES, Kibana je odgovoran za vizuelnu analizu log podataka.

Opšti tok korišćenja ELK-a za prikupljanje logova mikroservisi je sledeći:

Konfigurisanje izlaza logova u svakom mikroservisu: Izlaz logova mikroservisi se šalje na standardni izlaz (stdout) ili u fajl logova.
Korišćenje Logstash-a za prikupljanje logova: Konfiguriše se Logstash kolektor, through konfigurisanje input plugin-a (kao input fajla, network input i drugi) sluša izlaz logova mikroservisi i vrši filtriranje i obradu.
Slanje log podataka u Elasticsearch: Konfiguriše se output plugin Logstash-a, obrađene log podatke se šalju u Elasticsearch za skladištenje i indeksiranje.
Korišćenje Kibana-e za vizuelizaciju i analizu: Through Kibana povezivanje na Elasticsearch, kreiraju se dashboard-i, grafikoni i query-ji, u realnom vremenu se monitoriju i analiziraju log podaci mikroservisi.

Pored najšire primenjenog ELK-a, postoje i druga rešenja kao Fluentd, Graylog, Loki, Filebeat, neki cloud provideri takođe pružaju plaćena rešenja, na primer Alibaba Cloud-ov sls.

13.000 reči 33 ručnocrtane slike, detaljno objašnjenje 33 česta pitanja o mikroservisima (Dubbo, Spring Cloud) na intervjuu (neka učenja ne budu teška za pamćenje), kandidati koji nauče ova pitanja će zasigurno odgovoriti na intervju, verujem da je ovo sigurno (ručno dog). Organizovao: Chenmo Wang Er, pogledajte link za prepis, autor: Sanfej, pogledajte link originalnog teksta.

Ništa me ne zadržava – osim cilja, i pored toga što na obali ima ruža, hladovine, mirne luke, ja sam brod bez sidra.

Serijski sadržaj:

GitHub-ov repozitorijum sa više od 17.000 zvezda "Poboljšanje intervjua" drugo izdanje PDF konačno je stiglo! Uključuje Java osnove, Java kolekcioni frejmvork, Java konkurentno programiranje, JVM, Spring, Redis, MyBatis, MySQL, operativni sistem, računarne mreže, RocketMQ, distribuirane sisteme, mikroservise, design patterns, Linux, OpenClaw i drugo, ukupno više od 320.000 reči, više od 500 ručnocrtanih slika, može se reći da je jednostavno i razumljivo, zanimljivo i humorno…… Detalji: PDF izdanje Poboljšanje intervjua 2.0 objavljeno, obavezno za Java backend programere, možda najbolja klasična pitanja za 2026. godinu