Microservice'i arhitektuur - õppige, koostage ja juurutage mikroteenuseid

Microservice'i arhitektuur:

Minult , peate olema Microsofti arhitektuuri põhiteadmised omandanud.Kuid olles professionaalne nõuab rohkem kui ainult põhitõdesid. Selles ajaveebis saate tutvuda arhitektuurimõistete sügavusega ja rakendada neid UBER-juhtumiuuringu abil.

Selles ajaveebis saate teada järgmist:

kuidas kasutada hoiatust javascriptis

• Mikroteenuste arhitektuuri mõiste
• Mikroteenuste arhitektuuri põhimõisted
• Plussid ja miinused mikroteenuste arhitektuuris
• UBER - juhtumiuuring

Võite viidata , Microsofti teenuste põhialuste ja eeliste mõistmiseks.

Aus on ainult siis, kui annan teile mikroteenuste definitsiooni.

Mikroteenuste määratlus

Sellisena puudub Microservice'i ehk Microservice'i arhitektuuri õige määratlus, kuid võite öelda, et see on raamistik, mis koosneb väikestest individuaalselt juurutatavatest teenustest, mis täidavad erinevaid toiminguid.

Mikroteenused keskenduvad ühele ärivaldkonnale, mida saab rakendada täiesti iseseisvate juurutatavate teenustena, ja rakendada neid erinevatele tehnoloogiapakkidele.

Joonis 1: Erinevus monoliitse ja mikroteenuse arhitektuuri vahel - Microservice'i arhitektuur

Monoliitse ja mikroteenuse arhitektuuri erinevuse mõistmiseks vaadake ülaltoodud skeemi.Mõlema arhitektuuri erinevuste paremaks mõistmiseks võite viidata minu eelmisele ajaveebile

Et teid paremini mõista, lubage mul teile öelda mõned mikroteenuste arhitektuuri põhimõisted.

Mikroteenuste arhitektuuri põhimõisted

Enne mikroteenuste abil oma rakenduste loomist peate olema selge oma rakenduse ulatuse ja funktsioonide osas.

Järgnevalt on toodud mõned juhised, mida mikroteenuste üle arutades tuleb järgida.

Juhised mikroteenuste kujundamisel

• Arendajana eraldage domeenid arendajana, kui otsustate ehitada rakenduse, ja selgitage funktsionaalsusi.
• Iga teie loodud mikroteenus keskendub ainult ühele rakenduse teenusele.
• Veenduge, et olete rakenduse kujundanud nii, et iga teenust saaks eraldi juurutada.
• Veenduge, et mikroteenuste vaheline suhtlus toimub kodakondsuseta serveri kaudu.
• Iga teenust saab edasi arendada väiksemateks teenusteks, millel on oma mikroteenused.

Nüüd, kui olete mikroteenuste kujundamisel läbi lugenud põhijuhised, mõistkem mikroteenuste arhitektuuri.

Kuidas Microservice'i arhitektuur töötab?

Tüüpiline Microservice Architecture (MSA) peaks koosnema järgmistest komponentidest:

1. Kliendid
2. Identiteedi pakkujad
3. Gateway API
4. Sõnumivormingud
5. Andmebaasid
6. Staatiline sisu
7. Juhtimine
8. Teenuse avastamine

Vaadake allolevat skeemi.

Joonis 2: Mikroteenuste arhitektuur - mikroteenuste arhitektuur

Ma tean, et arhitektuur näeb natuke keeruline välja, aga laskeMinalihtsustage seda teie jaoks.

1. Kliendid

Arhitektuur algab erinevat tüüpi klientidest, alates erinevatest seadmetest, mis üritavad teha erinevaid haldusvõimalusi, näiteks otsimine, loomine, konfigureerimine jne

2. Identiteedi pakkujad

Need klientide taotlused edastatakse seejärel identiteedipakkujatele, kes autentivad klientide taotlused ja edastavad taotlused API lüüsile. Seejärel edastatakse päringud siseteenustele täpselt määratletud API-lüüsi kaudu.

3. API lüüs

Kuna kliendid ei helista otse teenustesse, toimib API lüüs klientide sisenemispunktina päringute edastamiseks asjakohastele mikroteenustele.

API-lüüsi kasutamise eelised hõlmavad järgmist:

• Kõiki teenuseid saab ajakohastada ilma klientide teadmata.
• Teenused saavad kasutada ka sõnumside protokolle, mis pole veebisõbralikud.
• API värav võib täita valdkondadevahelisi funktsioone, näiteks turvalisuse pakkumine, koormuse tasakaalustamine jne.

Pärast klientide päringute saamist koosneb sisemine arhitektuur mikroteenustest, mis suhtlevad üksteisega sõnumite kaudu kliendipäringute käsitlemiseks.

4. Sõnumivormingud

Suhtlust on kahte tüüpi:

• Sünkroonsed sõnumid: Olukorras, kus kliendid ootavad teenuse vastuseid, kipuvad Microservices tavaliselt kasutama REST (riigi esindusülekanne) kuna see tugineb kodakondsuseta kliendiserverile ja HTTP-protokoll . Seda protokolli kasutatakse, kuna see on hajutatud keskkond ja iga funktsioon on operatsioonide teostamiseks ressursiga esindatud
• Asünkroonsed sõnumid: Olukorras, kus kliendid ei oota teenuse vastuseid, kipuvad Microservices tavaliselt kasutama selliseid protokolle nagu AMQP, STOMP, MQTT . Neid protokolle kasutatakse seda tüüpi suhtluses, kuna sõnumite olemus on määratletud ja need teated peavad rakenduste vahel olema koostalitlusvõimelised.

Järgmine küsimus, mis võib teile pähe tulla, on see, kuidas Microservice'i kasutavad rakendused oma andmeid käsitsevad?

5. Andmete käitlemine

Noh, igale Microservice'ile kuulub oma andmete hõivamiseks ja vastava ärifunktsionaalsuse rakendamiseks privaatne andmebaas. Samuti värskendatakse Microservice'i andmebaase ainult nende teenuse API kaudu. Vaadake allolevat skeemi:

Joonis 3: Andmete käitlemise mikroteenuste esindamine - mikroteenuste arhitektuur

Microservicesi pakutavad teenused viiakse üle igasse kaugteenusesse, mis toetab protsesside vahelist suhtlemist erinevate tehnoloogiate jaoks.

6. Staatiline sisu

Pärast seda, kui mikroteenused endas suhtlevad, juurutavad nad staatilise sisu pilvepõhisesse salvestusteenusesse, mis saab selle otse klientidele edastada Sisuvõrgud (CDN) .

java system.exit (1)

Lisaks ülaltoodud komponentidele on tüüpilises Microservice'i arhitektuuris mõned muud komponendid:

7. Juhtimine

See komponent vastutab sõlmedes teenuste tasakaalustamise ja rikete tuvastamise eest.

8. Teenuse avastamine

Tegutseb mikroteenuste juhendina, et leida nende vahelise kommunikatsiooni marsruut, kuna see haldab loendit teenustest, kus sõlmed asuvad.

Uute värskenduste saamiseks tellige meie youtube'i kanal ..!

Nüüd uurime selle arhitektuuri plusse ja miinuseid, et paremini mõista, millal seda arhitektuuri kasutada.

Microservice'i arhitektuuri plussid ja miinused

Vaadake allolevat tabelit.

Mõistame mikroteenuste kohta rohkem, võrreldes UBERi varasemat arhitektuuri praegusega.

UBERI JUHTUMIUURING

UBERi eelmine arhitektuur

Nagu paljud idufirmad, alustas UBER teekonda monoliitse arhitektuuriga, mis ehitati ühe pakkumise jaoks ühes linnas. Ühe koodibaasi olemasolu tundus tol ajal puhastatud ja lahendas UBERi põhitegevuse probleemid. Kuid kui UBER hakkas laienema kogu maailmas, seisid nad rangelt silmitsi erinevate probleemidega seoses mastaapsuse ja pideva integreerimisega.

Joonis 4: UBERi monoliitne arhitektuur - Microservice'i arhitektuur

Ülaltoodud skeem kujutab UBERi eelmist arhitektuuri.

• Olemas on REST API, millega reisija ja juht saavad ühendust.
• API-s kasutatakse kolme erinevat adapterit selliste toimingute tegemiseks nagu arveldamine, maksed, e-kirjade / sõnumite saatmine, mida näeme kabiini broneerimisel.
• MySQL-i andmebaas kõigi nende andmete salvestamiseks.

Seega, kui märkate siin kõiki funktsioone, nagu reisijate haldamine, arveldamine, teavitamisfunktsioonid, maksed, reisihaldus ja juhihaldus, koosnesid ühes raamistikus.

Probleemipüstituses

Kui UBER hakkas kogu maailmas laienema, pakkus selline raamistik mitmesuguseid väljakutseid. Järgnevalt on välja toodud mõned silmapaistvad väljakutsed

• Ühe funktsiooni värskendamiseks tuli kõik funktsioonid uuesti üles ehitada, juurutada ja neid uuesti ja uuesti testida.
• Vigade parandamine muutus ühes hoidlas äärmiselt keeruliseks, kuna arendajad pidid koodi uuesti ja uuesti muutma.
• Funktsioonide skaleerimine samaaegselt uute funktsioonide kasutuselevõtuga kogu maailmas oli koos käsitsemine üsna keeruline.

Lahendus

Selliste probleemide vältimiseks otsustas UBER oma arhitektuuri muuta ja järgida teisi hüpermaailma ettevõtteid nagu Amazon, Netflix, Twitter ja paljud teised. Seega otsustas UBER mikroteenuse arhitektuuri moodustamiseks jagada oma monoliitse arhitektuuri mitmeks koodibaasiks.

UBER-i mikroteenuste arhitektuuri vaatamiseks vaadake allolevat skeemi.

Joonis 5: UBERi mikroteenuste arhitektuur - Microservice Architecture

• Suurim muudatus, mida siin täheldame, on API Gateway kasutuselevõtt, mille kaudu on ühendatud kõik juhid ja reisijad. API-lüüsi kaudu on ühendatud kõik sisemised punktid, näiteks reisijate haldamine, juhihaldus, reisihaldus ja muud.
• Üksused on eraldi eraldi kasutatavad üksused, mis täidavad eraldi funktsioone.
  • Näide: kui soovite arveldavas mikroteenuses midagi muuta, peate lihtsalt juurutama ainult arveldavaid mikroteenuseid ja teisi ei pea juurutama.
• Kõiki funktsioone skaleeriti nüüd eraldi, s.t eemaldati iga funktsiooni omavaheline sõltuvus.
  • Näiteks teame kõik, et kabiini otsivate inimeste arv on suhteliselt suurem kui tegelikult kabiini broneerivate ja makseid sooritavate inimeste arv. See annab meile järelduse, et reisijate haldamise mikroteenuses töötavate protsesside arv on suurem kui maksetega töötavate protsesside arv.

Sellestee, UBER sai vahetamisest kasusellearhitektuur monoliitsest mikroteenuseni.

Loodan, et teile on meeldinud seda postitust Microservice'i arhitektuuris lugeda.Tulen välja veel ajaveebidega, mis sisaldavad ka praktilisi näpunäiteid.
Kas soovite rohkem teada saada mikroteenustest?

Kui soovite õppida mikroteenuseid ja luua oma rakendusi, vaadake meie mis on varustatud juhendajate juhitud elava koolituse ja reaalse elu projektikogemusega. See koolitus aitab teil mikroteenuseid põhjalikumalt mõista ja aitab teil selle teema üle meisterlikkust saavutada.

Kas teil on meile küsimus? Palun mainige seda kommentaaride jaotises ” Microservice'i arhitektuur ”Ja pöördun teie poole tagasi.