Arhitektura mikroservisa - naučite, izgradite i postavite mikroservise

Arhitektura mikroservisa:

Od mog , morate imati osnovno razumijevanje arhitekture Microservice.Ali, biti profesionalac s zahtijevat će više od samo osnova. Na ovom blogu ući ćete u dubinu arhitektonskih koncepata i implementirati ih pomoću studije slučaja UBER.

Na ovom blogu naučit ćete o sljedećem:

• Definicija arhitekture mikroservisa
• Ključni koncepti arhitekture mikro usluga
• Za i protiv arhitekture mikroservisa
• UBER - Studija slučaja

Možete se pozvati na , kako bi se razumjele osnove i prednosti mikroservisa.

Pošteno će biti samo ako vam dam definiciju mikrousluga.

Definicija mikrousluga

Kao takva, ne postoji ispravna definicija Microservices aka Microservice Architecture, ali možete reći da je to okvir koji se sastoji od malih, pojedinačno raspoloživih usluga koje izvode različite operacije.

Mikroservisi se usredotočuju na jednu poslovnu domenu koja se može implementirati kao potpuno neovisne usluge za raspoređivanje i primijeniti ih na različitim tehnološkim hrpama.

java na snagu operatora

Slika 1: Razlika između monolitne i mikroservisne arhitekture - arhitektura mikrousluga

Pogledajte gornji dijagram kako biste razumjeli razliku između monolitne i mikroservisne arhitekture.Da biste bolje razumjeli razlike između obje arhitekture, možete se obratiti mom prethodnom blogu

Da biste bolje razumjeli, dopustite mi da vam kažem neke ključne koncepte arhitekture mikro usluga.

Ključni koncepti arhitekture mikro usluga

Prije nego što započnete s izradom vlastitih aplikacija pomoću mikroservisa, morate biti jasni o opsegu i funkcionalnostima svoje aplikacije.

Slijede neke smjernice kojih se treba pridržavati tijekom rasprave o mikrouslugama.

Smjernice tijekom dizajniranja mikrousluga

• Kao programer, kada odlučite izraditi aplikaciju, odvojite domene i budite jasni sa funkcionalnostima.
• Svaka mikrousluga koju dizajnirate koncentrirat će se samo na jednu uslugu aplikacije.
• Provjerite jeste li dizajnirali aplikaciju na takav način da se svaka usluga može pojedinačno rasporediti.
• Pobrinite se da se komunikacija između mikroservisa vrši putem servera bez državljanstva.
• Svaka usluga može se pretvoriti u manje usluge koje imaju vlastite mikroservise.

Sada, kad ste pročitali osnovne smjernice tijekom dizajniranja mikro usluga, shvatimo arhitekturu mikro usluga.

Kako djeluje arhitektura Microservice?

Tipična arhitektura mikroservisa (MSA) trebala bi se sastojati od sljedećih komponenata:

1. Klijenti
2. Davatelji identiteta
3. Gateway API
4. Formati poruka
5. Baze podataka
6. Statični sadržaj
7. Upravljanje
8. Otkrivanje usluge

Pogledajte donji dijagram.

Slika 2: Arhitektura mikrousluga - Arhitektura mikrousluga

Znam da arhitektura izgleda pomalo složeno, ali nekaJapojednostavite ga za vas.

1. Klijenti

Arhitektura započinje s različitim vrstama klijenata, od različitih uređaja koji pokušavaju izvršiti razne mogućnosti upravljanja poput pretraživanja, izrade, konfiguriranja itd.

2. Davatelji identiteta

Ti se zahtjevi od klijenata zatim prosljeđuju pružateljima identiteta koji provjeravaju autentičnost zahtjeva klijenata i prenose zahtjeve API Gatewayu. Zahtjevi se zatim prenose internim službama putem dobro definiranog API pristupnika.

3. API pristupnik

Budući da klijenti ne pozivaju usluge izravno, API Gateway djeluje kao ulazna točka za klijente za prosljeđivanje zahtjeva odgovarajućim mikroservisima.

Prednosti upotrebe API pristupnika uključuju:

• Sve se usluge mogu ažurirati, a da klijenti to ne znaju.
• Usluge također mogu koristiti protokole za razmjenu poruka koji nisu prilagođeni webu.
• API Gateway može obavljati presječne funkcije kao što su pružanje sigurnosti, uravnoteženje opterećenja itd.

Nakon primanja zahtjeva klijenata, unutarnja se arhitektura sastoji od mikroservisa koji međusobno komuniciraju porukama za obradu zahtjeva klijenta.

4. Formati poruka

Postoje dvije vrste poruka putem kojih komuniciraju:

• Sinkrone poruke: U situaciji kada klijenti čekaju odgovore usluge, Microservices obično koriste REST (reprezentativni državni transfer) jer se oslanja na apatrid, klijent-poslužitelj i HTTP protokol . Ovaj se protokol koristi jer je distribuirano okruženje, a svaka funkcionalnost predstavljena je resursom za izvršavanje operacija
• Asinkrone poruke: U situaciji kada klijenti ne čekaju odgovore usluge, Microservices obično koriste protokole poput AMQP, STOMP, MQTT . Ovi se protokoli koriste u ovoj vrsti komunikacije jer je definirana priroda poruka i te poruke moraju biti međusobno kompatibilne između implementacija.

Sljedeće pitanje koje vam može pasti na pamet je kako aplikacije koje koriste Microservices obrađuju svoje podatke?

5. Rukovanje podacima

Pa, svaka Microservice posjeduje privatnu bazu podataka kako bi uhvatila njihove podatke i implementirala odgovarajuću poslovnu funkcionalnost. Također, baze podataka Microservicesa ažuriraju se samo kroz njihov API usluge. Pogledajte donji dijagram:

Slika 3: Zastupljenost mikroservisa koji rukuju podacima - Arhitektura mikroservisa

Usluge koje pružaju Microservices prenose se na bilo koju udaljenu uslugu koja podržava međuprocesnu komunikaciju za različite tehnološke pakete.

6. Statični sadržaj

Nakon što Microservices međusobno komuniciraju, raspoređuju statički sadržaj u uslugu pohrane u oblaku koja ih može izravno dostaviti klijentima putem Mreže za isporuku sadržaja (CDN) .

Osim gore navedenih komponenata, postoje i neke druge komponente koje se pojavljuju u tipičnoj arhitekturi mikro usluga:

7. Menadžment

Ova je komponenta odgovorna za uravnoteženje usluga na čvorovima i prepoznavanje kvarova.

8. Otkrivanje usluge

Djeluje kao vodič za Microservices kako bi pronašao put komunikacije između njih jer održava popis usluga na kojima se nalaze čvorovi.

Pretplatite se na naš youtube kanal da biste dobivali nova ažuriranja ..!

Sada, pogledajmo prednosti i nedostatke ove arhitekture kako bismo stekli bolje razumijevanje kada koristiti ovu arhitekturu.

Prednosti i nedostaci arhitekture mikroservisa

Pogledajte donju tablicu.

Razumijemo više o Microservices uspoređujući prethodnu UBER-ovu arhitekturu sa današnjom.

ISTRAŽIVANJE UBER SLUČAJA

UBER-ova prethodna arhitektura

Poput mnogih startupa, UBER je svoje putovanje započeo monolitnom arhitekturom izgrađenom za jednu ponudu u jednom gradu. Imati jednu bazu koda u to se vrijeme činilo očišćenom i riješilo osnovne poslovne probleme UBER-a. Međutim, kako se UBER počeo širiti širom svijeta, rigorozno su se suočavali s različitim problemima s obzirom na skalabilnost i kontinuiranu integraciju.

Slika 4: Monolitna arhitektura UBER-a - Arhitektura mikroservisa

Gornji dijagram prikazuje prethodnu arhitekturu UBER-a.

• Prisutan je REST API s kojim se povezuju suvozač i vozač.
• Tri različita adaptera koriste se s API-jem u njima za obavljanje radnji poput naplate, plaćanja, slanja e-pošte / poruka koje vidimo kad rezerviramo taksi.
• MySQL baza podataka za pohranu svih njihovih podataka.

Dakle, ako ovdje primijetite sve značajke kao što su upravljanje putnicima, naplata, značajke obavijesti, plaćanja, upravljanje putovanjem i upravljanje vozačem sastavljene su u jednom okviru.

Izjava o problemu

Iako se UBER počeo širiti širom svijeta, ovakva vrsta okvira dovela je do različitih izazova. Slijede neki od istaknutih izazova

• Sve značajke morale su se ponovno graditi, postavljati i testirati iznova i iznova kako bi se ažurirala jedna značajka.
• Ispravljanje programskih pogrešaka postalo je izuzetno teško u jednom spremištu jer su programeri morali iznova mijenjati kôd.
• Skaliranje značajki istovremeno s uvođenjem novih značajki širom svijeta bilo je prilično teško riješiti zajedno.

Riješenje

Da bi izbjegao takve probleme, UBER je odlučio promijeniti svoju arhitekturu i slijediti ostale tvrtke s hiper-rastom poput Amazona, Netflixa, Twittera i mnogih drugih. Stoga je UBER odlučio razbiti svoju monolitnu arhitekturu u više baza koda kako bi oblikovao arhitekturu mikro usluga.

Pogledajte donji dijagram da biste pogledali UBER-ovu arhitekturu mikro usluga.

Slika 5: Arhitektura mikroservisa UBER - Arhitektura mikroservisa

• Glavna promjena koju ovdje uočavamo je uvođenje API Gateway-a preko kojeg su povezani svi vozači i putnici. Iz API Gateway-a povezane su sve unutarnje točke, poput upravljanja putnicima, upravljanja vozačima, upravljanja putovanjima i drugima.
• Jedinice su pojedinačne odvojene jedinice za raspoređivanje koje izvode zasebne funkcionalnosti.
  • Na primjer: Ako želite promijeniti bilo što u naplatnim mikrouslugama, tada jednostavno morate razmjestiti samo naplate mikrousluge, a ne morate raspoređivati ​​ostale.
• Sve su značajke sada pojedinačno skalirane, tj. Uklonjena je međuovisnost između svake značajke.
  • Na primjer, svi znamo da je broj ljudi koji traže kabine razmjerno veći od onih koji stvarno rezerviraju taksi i izvršavaju uplate. To nam daje zaključak da je broj procesa koji rade na mikroservisu za upravljanje putnicima veći od broja procesa koji rade na plaćanjima.

U ovomeput, UBER je profitirao pomicanjemsvojearhitektura od monolitne do mikroservisa.

Nadam se da ste uživali čitajući ovaj članak o Microservice Architecture.Smislit ću još blogova koji će sadržavati i praktične tekstove.
Zanima vas više o mikroservisima?

Ako želite naučiti mikroservise i izraditi vlastite programe, pogledajte naše koja dolazi s treningom uživo pod vodstvom instruktora i iskustvom u stvarnom životu. Ovaj trening pomoći će vam da dublje razumijete mikrousluge i pomoći vam da postignete ovladavanje tom temom.

Imate pitanje za nas? Molimo spomenite to u odjeljku za komentare ' Arhitektura mikroservisa ”I javit ću vam se.