Arhitektura mikro storitev - naučite se, zgradite in postavite mikro storitve

Arhitektura mikro storitve:

Od mojega , morate imeti osnovno znanje o arhitekturi Microservice.Ampak, biti profesionalec z zahteva več kot le osnove. V tem blogu boste poglobili arhitekturne koncepte in jih uporabili s pomočjo študije primera UBER.

V tem blogu boste izvedeli o naslednjem:

• Opredelitev arhitekture mikro storitev
• Ključni koncepti arhitekture mikro storitev
• Prednosti in slabosti arhitekture mikro storitev
• UBER - Študija primera

Lahko se sklicujete na , da bi razumeli osnove in koristi mikro storitev.

Pošteno bo le, če vam dam definicijo mikro storitev.

Opredelitev mikro storitev

Kot taka ni ustrezne opredelitve Microservices aka Microservice Architecture, lahko pa rečemo, da gre za ogrodje, ki je sestavljeno iz majhnih, posamezno razpoložljivih storitev, ki izvajajo različne operacije.

Mikro storitve se osredotočajo na eno samo poslovno domeno, ki jo je mogoče implementirati kot popolnoma neodvisne storitve, ki jih je mogoče uvesti, in jih uporabiti na različnih tehnoloških sklopih.

Slika 1: Razlika med monolitno in mikroservisno arhitekturo - mikroservisna arhitektura

Glejte zgornji diagram, da boste razumeli razliko med monolitno in mikroservisno arhitekturo.Za boljše razumevanje razlik med obema arhitekturama se lahko obrnete na moj prejšnji blog

Da boste bolje razumeli, naj vam povem nekaj ključnih konceptov arhitekture mikro storitev.

Ključni koncepti arhitekture mikro storitev

Preden začnete graditi lastne aplikacije z uporabo mikroservisov, morate biti jasni glede obsega in funkcionalnosti aplikacije.

Sledi nekaj smernic, ki jih je treba upoštevati med razpravo o mikro storitvah.

Smernice med načrtovanjem mikro storitev

• Ko se kot razvijalec odločite za izdelavo aplikacije, ločite domene in bodite jasni s funkcijami.
• Vsaka mikrostoritev, ki jo načrtujete, se osredotoči samo na eno storitev aplikacije.
• Prepričajte se, da ste aplikacijo zasnovali tako, da je vsako storitev mogoče ločeno namestiti.
• Poskrbite, da komunikacija med mikro storitvami poteka prek strežnika brez državljanstva.
• Vsako storitev je mogoče spremeniti v manjše storitve, ki imajo svoje mikro storitve.

Zdaj, ko ste prebrali osnovne smernice med načrtovanjem mikrostoritev, razumemo arhitekturo mikro storitev.

Kako deluje arhitektura Microservice?

Tipična arhitektura mikroservisov (MSA) mora biti sestavljena iz naslednjih komponent:

1. Stranke
2. Ponudniki identitet
3. API prehoda
4. Oblike sporočil
5. Zbirke podatkov
6. Statična vsebina
7. Upravljanje
8. Storitev Discovery

Glejte spodnji diagram.

Slika 2: Arhitektura mikro storitev - arhitektura mikro storitev

Vem, da je arhitektura videti nekoliko zapleteno, a najjazpoenostavite za vas.

1. Stranke

Arhitektura se začne z različnimi vrstami odjemalcev, od različnih naprav, ki poskušajo izvajati različne zmožnosti upravljanja, kot so iskanje, gradnja, konfiguriranje itd.

2. Ponudniki identitet

Te zahteve odjemalcev se nato posredujejo ponudnikom identitet, ki overjajo zahteve strank in jih sporočajo API Gatewayu. Zahteve se nato posredujejo notranjim službam prek natančno določenega API prehoda.

java najti najvišjo vrednost v matriki

3. API Gateway

Ker stranke ne kličejo storitev neposredno, API Gateway deluje kot vstopna točka za odjemalce, ki posredujejo zahteve ustreznim mikro storitvam.

Prednosti uporabe prehoda API vključujejo:

• Vse storitve je mogoče posodobiti, ne da bi stranke to vedele.
• Storitve lahko uporabljajo tudi protokole za sporočanje, ki niso prijazni do spleta.
• API Gateway lahko izvaja medsektorske funkcije, kot so zagotavljanje varnosti, uravnoteženje obremenitve itd.

Po prejemu zahtev strank notranjo arhitekturo sestavljajo mikro storitve, ki med seboj komunicirajo prek sporočil za obdelavo zahtev strank.

4. Oblike sporočil

Obstajata dve vrsti sporočil, prek katerih komunicirajo:

• Sinhrona sporočila: V primerih, ko stranke čakajo na odgovore storitve, Microservices običajno uporabljajo REST (reprezentativni državni prenos) saj se opira na brezdržavni odjemalec, odjemalski strežnik in Protokol HTTP . Ta protokol se uporablja, ker je porazdeljeno okolje, vsaka funkcionalnost pa je predstavljena z virom za izvajanje operacij
• Asinhrona sporočila: V razmerah, ko stranke ne čakajo na odgovore storitve, Microservices običajno uporabljajo protokole, kot je AMQP, STOMP, MQTT . Ti protokoli se uporabljajo pri tej vrsti komunikacije, saj je narava sporočil opredeljena in morajo biti ta sporočila med izvedbami interoperabilna.

Naslednje vprašanje, ki vam bo morda padlo na pamet, je, kako aplikacije, ki uporabljajo Microservices, ravnajo s svojimi podatki?

5. Ravnanje s podatki

No, vsaka Microservice ima zasebno bazo podatkov za zajem njihovih podatkov in izvajanje ustreznih poslovnih funkcij.Prav tako se baze podatkov Microservices posodabljajo samo prek njihovega API-ja za storitve. Glejte spodnji diagram:

Slika 3: Zastopanje mikroservisov, ki obdelujejo podatke - arhitektura mikroservisov

Storitve Microservices se prenesejo na katero koli oddaljeno storitev, ki podpira medprocesno komunikacijo za različne tehnološke sklade.

6. Statična vsebina

Ko Microservices v sebi komunicirajo, namestijo statično vsebino v storitev za shranjevanje v oblaku, ki jo lahko posreduje neposredno strankam prek Omrežja za dostavo vsebine (CDN) .

Poleg zgornjih komponent je v tipični arhitekturi mikroservisov še nekaj komponent:

7. Upravljanje

Ta komponenta je odgovorna za uravnoteženje storitev na vozliščih in prepoznavanje napak.

8. Storitev Discovery

Deluje kot vodnik po Microservices-u za iskanje poti komunikacije med njimi, saj vzdržuje seznam storitev, na katerih so vozlišča.

Naročite se na naš youtube kanal in prejemajte nove posodobitve ..!

Zdaj pa poglejmo prednosti in slabosti te arhitekture, da bomo bolje razumeli, kdaj uporabljati to arhitekturo.

Prednosti in slabosti arhitekture mikro storitev

Glejte spodnjo tabelo.

Razumejmo več o Microservices s primerjavo prejšnje arhitekture UBER s sedanjo.

ŠTUDIJA UBER PRIMERA

Prejšnja arhitektura UBER

Tako kot številni startupi je tudi UBER svojo pot začel z monolitno arhitekturo, zgrajeno za eno samo ponudbo v enem mestu. Takrat se mi je zdelo, da je bila ena kodna baza očiščena in je rešila ključne poslovne težave UBER. Ko pa se je UBER začel širiti po vsem svetu, so se dosledno soočali z različnimi težavami glede razširljivosti in stalne integracije.

Slika 4: Monolitna arhitektura UBER - arhitektura mikroservisov

kaj počne .innerhtml

Zgornji diagram prikazuje prejšnjo arhitekturo UBER.

• Prisoten je API REST, s katerim se potnik in voznik povežeta.
• Z različnimi API-ji se uporabljajo trije različni vmesniki za izvajanje dejanj, kot so zaračunavanje, plačila, pošiljanje e-pošte / sporočil, ki jih vidimo, ko rezerviramo taksi.
• Baza podatkov MySQL za shranjevanje vseh njihovih podatkov.

Torej, če tukaj opazite, so bile vse funkcije, kot so upravljanje potnikov, obračunavanje, funkcije obveščanja, plačila, upravljanje potovanj in upravljanje voznika, sestavljene v enem samem okviru.

Izjava o težavi

Medtem ko se je UBER začel širiti po vsem svetu, je takšen okvir predstavljal različne izzive. Sledi nekaj pomembnih izzivov

• Vse funkcije je bilo treba znova znova zgraditi, znova in znova preizkusiti, da posodobijo eno samo funkcijo.
• Odpravljanje napak je postalo izredno težko v enem samem skladišču, saj so morali razvijalci znova in znova spreminjati kodo.
• Razširitev funkcij hkrati z uvedbo novih funkcij po vsem svetu je bilo zelo težko rešiti skupaj.

Rešitev

Da bi se izognil tovrstnim težavam, se je UBER odločil, da bo spremenil svojo arhitekturo in sledil ostalim podjetjem s hiper rastjo, kot so Amazon, Netflix, Twitter in številna druga. Tako se je UBER odločil svojo monolitno arhitekturo razbiti na več kodnih baz in tako oblikovati arhitekturo mikro storitev.

Glejte spodnji diagram, da si ogledate arhitekturo mikro storitev UBER.

Slika 5: Microservice Architecture UBER - Microservice Architecture

• Glavna sprememba, ki jo tu opažamo, je uvedba API Gateway, prek katerega so povezani vsi vozniki in potniki. V API Gateway so povezane vse notranje točke, kot so upravljanje potnikov, upravljanje voznika, upravljanje potovanj in druge.
• Enote so samostojne ločljive enote, ki izvajajo ločene funkcije.
  • Na primer: če želite kar koli spremeniti v obračunskih mikro storitvah, potem morate razporediti samo obračunske mikro storitve, drugih pa ni treba namestiti.
• Vse funkcije so bile zdaj prilagojene posamično, tj.odstranjenost med posameznimi elementi je bila odstranjena.
  • Na primer, vsi vemo, da je število ljudi, ki iščejo kabine, bolj sorazmerno kot tistih, ki dejansko rezervirajo taksi in plačujejo. Iz tega lahko sklepamo, da je število procesov, ki delujejo na mikroservisu za upravljanje potnikov, večje od števila procesov, ki delujejo na področju plačil.

V temnačin, UBER je s premikom koristilsvojearhitektura od monolitne do mikroservisov.

Upam, da ste uživali v branju tega prispevka o Microservice Architecture.Pripravil bom več spletnih dnevnikov, ki bodo vsebovali tudi praktične blogi.
Vas zanima več o mikro storitvah?

Če se želite naučiti mikro storitev in zgraditi lastne aplikacije, si oglejte našo ki prihaja z usposabljanjem pod vodstvom inštruktorjev v živo in izkušnjami iz resničnega življenja Ta trening vam bo pomagal poglobljeno razumeti mikro storitve in vam pomagal doseči obvladovanje zadeve.

Imate vprašanje za nas? Prosimo, navedite to v oddelku za komentarje v Arhitektura mikro storitev ”In se vam oglasim.