Mikroservisu arhitektūra - uzziniet, izveidojiet un izvietojiet mikropakalpojumus

Mikroservisa arhitektūra:

No manas , jums ir jābūt pamatzināšanām par Microservice arhitektūru.Bet, būdams profesionāls ar prasīs ne tikai pamatus. Šajā emuārā jūs iegūsit arhitektūras koncepciju dziļumu un tos īstenosiet, izmantojot UBER gadījuma izpēti.

Šajā emuārā jūs uzzināsiet par sekojošo:

• Mikroservisa arhitektūras definīcija
• Mikroservisu arhitektūras galvenie jēdzieni
• Mikroservisu arhitektūras plusi un mīnusi
• UBER - gadījumu izpēte

Jūs varat atsaukties uz , lai saprastu Microsoft pakalpojumu pamatus un priekšrocības.

Tas būs taisnīgi tikai tad, ja es jums sniegšu mikropakalpojumu definīciju.

Mikroservisu definīcija

Kā tāda nav pareizas Microservices jeb Microservice Architecture definīcijas, taču jūs varat teikt, ka tā ir sistēma, kas sastāv no maziem, individuāli izvietojamiem pakalpojumiem, kas veic dažādas darbības.

Mikropakalpojumi koncentrējas uz vienu biznesa domēnu, kuru var ieviest kā pilnīgi neatkarīgus izvietojamus pakalpojumus, un tos ieviest dažādās tehnoloģiju grupās.

1. attēls: Atšķirība starp monolītu un mikropakalpojumu arhitektūru - mikropakalpojumu arhitektūra

Lai saprastu atšķirību starp monolītu un mikropakalpojumu arhitektūru, skatiet iepriekšējo diagrammu.Lai labāk izprastu abu arhitektūru atšķirības, varat atsaukties uz manu iepriekšējo emuāru

Lai jūs labāk saprastu, ļaujiet man pastāstīt dažus galvenos mikropakalpojumu arhitektūras jēdzienus.

Mikroservisu arhitektūras galvenie jēdzieni

Pirms sākat veidot savas lietojumprogrammas, izmantojot mikropakalpojumus, jums ir jābūt skaidram par lietojumprogrammas darbības jomu un funkcijām.

Šīs ir dažas vadlīnijas, kas jāievēro, apspriežot mikropakalpojumus.

Vadlīnijas, izstrādājot mikropakalpojumus

• Kad esat izstrādātājs, izlemjot izveidot lietojumprogrammu, atdaliet domēnus un skaidri norādiet funkcijas.
• Katrs jūsu izstrādātais mikropakalpojums koncentrējas tikai uz vienu lietojumprogrammas pakalpojumu.
• Pārliecinieties, vai esat izveidojis lietojumprogrammu tā, lai katrs pakalpojums būtu izvietojams atsevišķi.
• Pārliecinieties, ka saziņa starp mikropakalpojumiem notiek caur bezvalstnieku serveri.
• Katru pakalpojumu var pārveidot mazākos pakalpojumos, kuriem ir savi mikropakalpojumi.

Tagad, kad, izstrādājot mikropakalpojumus, esat izlasījis pamatnostādnes, sapratīsim mikropakalpojumu arhitektūru.

Kā darbojas Microservice arhitektūra?

Tipiskai Microservice Architecture (MSA) vajadzētu sastāvēt no šādām sastāvdaļām:

1. Klienti
2. Identitātes nodrošinātāji
3. Gateway API
4. Ziņapmaiņas formāti
5. Datu bāzes
6. Statiskais saturs
7. Vadība
8. Pakalpojuma atklāšana

Skatiet zemāk redzamo diagrammu.

2. attēls: Mikroservisu arhitektūra - Mikroservisu arhitektūra

Es zinu, ka arhitektūra izskatās mazliet sarežģīta, bet ļaujietEsvienkāršojiet to jums.

1. Klienti

Arhitektūra sākas ar dažāda veida klientiem, sākot no dažādām ierīcēm, kas mēģina veikt dažādas pārvaldības iespējas, piemēram, meklēt, veidot, konfigurēt utt.

2. Identitātes nodrošinātāji

Šie klientu pieprasījumi tiek nodoti identitātes nodrošinātājiem, kuri autentificē klientu pieprasījumus un paziņo pieprasījumus API vārtejai. Pēc tam pieprasījumi tiek nosūtīti iekšējiem pakalpojumiem, izmantojot precīzi definētu API vārteju.

3. API vārteja

Tā kā klienti tieši nezvana uz pakalpojumiem, API vārteja darbojas kā ieejas punkts, lai klienti pārsūtītu pieprasījumus atbilstošiem mikropakalpojumiem.

API vārtejas izmantošanas priekšrocības ir šādas:

klienta servera ligzdas programmēšana Java

• Visus pakalpojumus var atjaunināt, klientam nezinot.
• Pakalpojumi var izmantot arī ziņojumapmaiņas protokolus, kas nav piemēroti tīmeklim.
• API vārteja var veikt transversālas funkcijas, piemēram, nodrošināt drošību, slodzes līdzsvarošanu utt.

Pēc klientu pieprasījumu saņemšanas iekšējā arhitektūra sastāv no mikropakalpojumiem, kas savā starpā sazinās ar ziņojumu starpniecību, lai apstrādātu klienta pieprasījumus.

4. Ziņapmaiņas formāti

Ir divu veidu ziņojumi, ar kuriem viņi sazinās:

• Sinhronie ziņojumi: Situācijā, kad klienti gaida atbildes no pakalpojuma, parasti parasti izmanto Microsoft pakalpojumus REST (pārstāvības valsts nodošana) jo tas balstās uz bezvalstnieku, klienta serveri un HTTP protokols . Šis protokols tiek izmantots, jo tā ir izplatīta vide, un katra funkcionalitāte tiek attēlota ar resursu darbību veikšanai
• Asinhronie ziņojumi: Situācijā, kad klienti negaida atbildes no pakalpojuma, Microservices parasti mēdz izmantot tādus protokolus kā AMQP, STOMP, MQTT . Šie protokoli tiek izmantoti šāda veida saziņā, jo ir definēts ziņojumu raksturs, un šiem ziņojumiem jābūt savietojamiem starp ieviešanu.

Nākamais jautājums, kas jums varētu ienākt prātā, ir tas, kā lietojumprogrammas, kas izmanto Microservices, apstrādā savus datus?

5. Datu apstrāde

Katram Microservice pieder privāta datu bāze, lai tvertu savus datus un ieviestu attiecīgo biznesa funkcionalitāti. Turklāt Microservice datu bāzes tiek atjauninātas, izmantojot tikai to pakalpojumu API. Skatiet šo diagrammu:

3. attēls: Mikroservisu apstrādes datu attēlojums - mikropakalpojumu arhitektūra

Microservices sniegtie pakalpojumi tiek pārnesti uz jebkuru attālo pakalpojumu, kas atbalsta starpprocesu komunikāciju dažādām tehnoloģiju kopām.

6. Statiskais saturs

Pēc tam, kad mikropakalpojumi sazinās savā starpā, viņi izvieto statisko saturu uz mākoņa bāzes krātuves pakalpojumu, kas tos var piegādāt tieši klientiem, izmantojot Satura piegādes tīkli (CDN) .

Bez iepriekš minētajiem komponentiem tipiskajā Microservices arhitektūrā ir daži citi komponenti:

7. Vadība

Šis komponents ir atbildīgs par pakalpojumu līdzsvarošanu mezglos un kļūmju identificēšanu.

8. Pakalpojuma atklāšana

Darbojas kā ceļvedis mikropakalpojumiem, lai atrastu savstarpējās saziņas maršrutu, jo tas uztur pakalpojumu sarakstu, kuros atrodas mezgli.

Abonējiet mūsu youtube kanālu, lai iegūtu jaunus atjauninājumus ..!

Apskatīsim šīs arhitektūras plusus un mīnusus, lai labāk izprastu, kad izmantot šo arhitektūru.

Mikroservisu arhitektūras plusi un mīnusi

Skatiet tabulu zemāk.

Ļaujiet mums vairāk saprast par Microservices, salīdzinot UBER iepriekšējo arhitektūru ar pašreizējo.

UBER LIETU PĒTĪJUMS

UBER iepriekšējā arhitektūra

Tāpat kā daudzi jaunizveidotie uzņēmumi, UBER sāka savu ceļu ar monolītu arhitektūru, kas būvēta par vienu piedāvājumu vienā pilsētā. Šķita, ka tajā laikā viena koda bāze bija iztīrīta un atrisināja UBER pamatdarbības problēmas. Tomēr, kad UBER sāka paplašināties visā pasaulē, viņi stingri saskārās ar dažādām problēmām saistībā ar mērogojamību un nepārtrauktu integrāciju.

4. attēls: UBER monolītā arhitektūra - Microservice arhitektūra

Iepriekš redzamā diagramma attēlo UBER iepriekšējo arhitektūru.

• Ir REST API, ar kuru savienojas pasažieris un vadītājs.
• Trīs dažādi adapteri tiek izmantoti kopā ar API, lai veiktu tādas darbības kā norēķini, maksājumi, e-pastu / ziņojumu sūtīšana, kuras mēs redzam, rezervējot kabīni.
• MySQL datu bāze visu viņu datu glabāšanai.

Tātad, ja šeit pamanāt visas funkcijas, piemēram, pasažieru vadība, rēķinu izrakstīšana, paziņojumu funkcijas, maksājumi, ceļojumu vadība un vadītāju vadība, tika izveidotas vienā sistēmā.

Problēmas izklāsts

Kamēr UBER sāka paplašināties visā pasaulē, šāda veida sistēma radīja dažādas problēmas. Tālāk ir minēti daži no nozīmīgākajiem izaicinājumiem

• Visas funkcijas bija jāpārbūvē, jāizvieto un jāpārbauda atkal un atkal, lai atjauninātu vienu funkciju.
• Kļūdu labošana vienā krātuvē kļuva ārkārtīgi sarežģīta, jo izstrādātājiem kods bija jāmaina atkal un atkal.
• Funkciju mērogošana vienlaikus ar jaunu funkciju ieviešanu visā pasaulē bija diezgan grūta, lai to varētu apstrādāt kopā.

Risinājums

Lai izvairītos no šādām problēmām, UBER nolēma mainīt savu arhitektūru un sekot citiem hiper izaugsmes uzņēmumiem, piemēram, Amazon, Netflix, Twitter un daudziem citiem. Tādējādi UBER nolēma sadalīt savu monolīto arhitektūru vairākās koda bāzēs, lai izveidotu mikropakalpojumu arhitektūru.

marķiera saskarne java piemērā

Skatiet zemāk redzamo diagrammu, lai apskatītu UBER mikropakalpojumu arhitektūru.

5. attēls: UBER mikropakalpojumu arhitektūra - Microservice Architecture

• Galvenās izmaiņas, ko mēs šeit novērojam, ir API Gateway ieviešana, caur kuru ir savienoti visi autovadītāji un pasažieri. No API vārtejas ir savienoti visi iekšējie punkti, piemēram, pasažieru vadība, vadītāju vadība, ceļojumu vadība un citi.
• Vienības ir atsevišķas atsevišķas izvietojamas vienības, kas veic atsevišķas funkcijas.
  • Piemēram: Ja vēlaties kaut ko mainīt norēķinu mikropakalpojumos, jums vienkārši jāizvieto tikai norēķinu mikropakalpojumi, bet citi nav jāizvieto.
• Visas funkcijas tagad tika mērogotas atsevišķi, t.i., tika noņemta savstarpējā atkarība starp katru funkciju.
  • Piemēram, mēs visi zinām, ka cilvēku skaits, kas meklē kabīnes, ir salīdzinoši lielāks nekā to cilvēku skaits, kuri faktiski rezervē kabīni un veic maksājumus. Tas ļauj secināt, ka procesu skaits, kas strādā ar pasažieru vadības mikropakalpojumu, ir lielāks nekā procesu skaits, kas strādā ar maksājumiem.

Šajāveidā, UBER guva labumu no maiņastāarhitektūra no monolīta līdz mikropakalpojumiem.

Es ceru, ka jums patika lasīt šo ierakstu vietnē Microservice Architecture.Es nākšu klajā ar vairākiem emuāriem, kuros būs arī praktiski.
Vai vēlaties uzzināt vairāk par mikropakalpojumiem?

Ja vēlaties apgūt mikropakalpojumus un izveidot savas lietojumprogrammas, apskatiet mūsu vietni kas nāk ar instruktoru vadītu tiešraides apmācību un reālās dzīves projektu pieredzi. Šīs apmācības palīdzēs jums padziļināti izprast mikropakalpojumus un palīdzēs jums apgūt priekšmetu.

Vai mums ir jautājums? Lūdzu, pieminējiet to komentāru sadaļā Mikroservisa arhitektūra ”Un es sazināšos ar jums.