„Microservice Architecture“ - sužinokite, kurkite ir įdiekite „Microsoft“ paslaugas

„Microservice“ architektūra:

Nuo mano , jūs turite turėti pagrindinį supratimą apie „Microservice Architecture“.Bet, būdamas profesionalu reikės ne tik pagrindų. Šiame tinklaraštyje susipažinsite su architektūrinių koncepcijų gelmėmis ir jas įgyvendinsite naudodamiesi UBER pavyzdžiu.

Šiame tinklaraštyje sužinosite apie šiuos dalykus:

• Mikroserviso architektūros apibrėžimas
• Pagrindinės mikroserviso architektūros sąvokos
• „Microsoft“ paslaugų architektūros pliusai ir minusai
• UBER - atvejų analizė

Galite kreiptis į , suprasti pagrindinius „Microsoft“ paslaugų teikimo privalumus.

Tai bus sąžininga tik tuo atveju, jei pateiksiu „Microsoft“ paslaugų apibrėžimą.

Mikroservikų apibrėžimas

Taigi nėra tinkamo „Microservices“, dar žinomo kaip „Microservice Architecture“, apibrėžimo, tačiau galite sakyti, kad tai yra sistema, kurią sudaro mažos, individualiai diegiamos paslaugos, atliekančios skirtingas operacijas.

„Mikroservisai“ sutelkia dėmesį į vieną verslo sritį, kurią galima įdiegti kaip visiškai nepriklausomas diegiamas paslaugas, ir įdiegti jas skirtingose ​​technologijų grupėse.

Figūra 1: Skirtumas tarp monolitinės ir mikroserviso architektūros - mikroserviso architektūra

Norėdami suprasti skirtumą tarp monolitinės ir mikropaslaugų architektūros, žiūrėkite aukščiau pateiktą diagramą.Norėdami geriau suprasti abiejų architektūrų skirtumus, galite kreiptis į mano ankstesnį tinklaraštį

Kad geriau suprastumėte, leiskite man papasakoti keletą pagrindinių mikro paslaugų architektūros sąvokų.

Pagrindinės mikroserviso architektūros sąvokos

Prieš pradėdami kurti savo programas naudodami mikropaslaugas, turite aiškiai žinoti savo taikymo sritį ir funkcijas.

analizuojant xml failus Java

Toliau pateikiamos kelios gairės, kurių reikia laikytis aptariant mikropaslaugas.

Gairės projektuojant mikroservisus

• Kaip kūrėjas, kai nuspręsite sukurti programą, atskirkite domenus ir aiškiai nurodykite funkcijas.
• Kiekviena jūsų sukurta mikroservisa sutelks dėmesį tik į vieną programos paslaugą.
• Įsitikinkite, kad sukūrėte programą taip, kad kiekvieną paslaugą būtų galima pritaikyti atskirai.
• Įsitikinkite, kad ryšys tarp mikropaslaugų vyksta per serverį be pilietybės.
• Kiekviena paslauga gali būti pertvarkyta į mažesnes paslaugas, turinčias savo mikro paslaugas.

Dabar, kai projektuodami mikropaslaugas perskaitėte pagrindines gaires, supraskime mikropaslaugų architektūrą.

Kaip veikia „Microservice“ architektūra?

Tipišką „Microservice Architecture“ (MSA) turėtų sudaryti šie komponentai:

1. Klientai
2. Tapatybės teikėjai
3. Vartų API
4. Pranešimų formatai
5. Duomenų bazės
6. Statinis turinys
7. Valdymas
8. Paslaugų atradimas

Žiūrėkite toliau pateiktą diagramą.

2 paveikslas: Mikroservikų architektūra - Mikroservisų architektūra

Žinau, kad architektūra atrodo šiek tiek sudėtinga, bet tegulAšsupaprastinkite jį už jus.

1. Klientai

Architektūra prasideda nuo skirtingų tipų klientų, pradedant įvairiais įrenginiais, bandančiais atlikti įvairias valdymo galimybes, pvz., Paiešką, kūrimą, konfigūravimą ir kt.

2. Tapatybės teikėjai

Šios klientų užklausos yra perduodamos tapatybės tiekėjams, kurie patvirtina klientų užklausas ir perduoda užklausas API šliuzui. Tada užklausos perduodamos vidinėms tarnyboms per tiksliai apibrėžtą API šliuzą.

3. API vartai

Kadangi klientai tiesiogiai neskambina į tarnybas, API šliuzas veikia kaip įėjimo taškas, per kurį klientai perduoda užklausas atitinkamoms mikroservikoms.

API šliuzo naudojimo pranašumai yra šie:

• Visos paslaugos gali būti atnaujintos klientams nežinant.
• Paslaugos taip pat gali naudoti žiniatinklio protokolus, kurie nėra tinkami internetui.
• API vartai gali atlikti įvairias funkcijas, tokias kaip saugumo užtikrinimas, apkrovos balansavimas ir kt.

Gavusi klientų užklausas, vidinė architektūra susideda iš mikro paslaugų, kurios pranešimais bendrauja tarpusavyje, kad tvarkytų klientų užklausas.

4. Pranešimų formatai

Yra dviejų tipų pranešimai, kuriais jie bendrauja:

• Sinchroniniai pranešimai: Tais atvejais, kai klientai laukia atsakymų iš tarnybos, „Microservices“ dažniausiai naudojasi REST (reprezentacinis valstybės perdavimas) nes jis remiasi be pilietybės, kliento-serverio ir HTTP protokolas . Šis protokolas naudojamas, nes tai yra paskirstyta aplinka, o kiekviena funkcija pateikiama su ištekliu operacijoms atlikti
• Asinchroniniai pranešimai: Tais atvejais, kai klientai nelaukia atsakymų iš tarnybos, „Microservices“ dažniausiai linkę naudoti tokius protokolus kaip AMQP, STOMP, MQTT . Šie protokolai naudojami tokio tipo ryšiams, nes apibrėžtas pranešimų pobūdis ir šie pranešimai turi būti sąveikūs tarp įgyvendinimų.

Kitas klausimas, kuris gali jums kilti, yra tai, kaip „Microsoft“ paslaugas naudojančios programos tvarko savo duomenis?

5. Duomenų tvarkymas

Na, kiekvienai „Microservice“ priklauso privati ​​duomenų bazė, kurioje kaupiami jų duomenys ir įgyvendinamos atitinkamos verslo funkcijos. Be to, „Microservices“ duomenų bazės atnaujinamos tik per jų paslaugų API. Žiūrėkite toliau pateiktą diagramą:

3 paveikslas: Duomenų tvarkymo mikroservisų pavaizdavimas - mikroserviso architektūra

„Microservices“ teikiamos paslaugos yra perkeltos į bet kurią nuotolinę tarnybą, palaikančią skirtingų procesų tarpusavio ryšius.

egzemplioriaus kintamasis Java pavyzdyje

6. Statinis turinys

Po to, kai „Microservices“ bendrauja savyje, jie statinį turinį įdiegia į debesies saugyklą, kuri gali juos pristatyti tiesiogiai klientams per Turinio pristatymo tinklai (CDN) .

Be pirmiau minėtų komponentų, tipinėje „Microservices“ architektūroje yra keletas kitų komponentų:

7. Valdymas

Šis komponentas yra atsakingas už paslaugų balansą mazguose ir gedimų nustatymą.

8. Paslaugos atradimas

Veikia kaip „Microsoft“ paslaugų vadovas, kad surastų tarpusavio ryšio būdą, nes jis tvarko paslaugų, kuriose yra mazgai, sąrašą.

Norėdami gauti naujienų, užsiprenumeruokite mūsų „YouTube“ kanalą!

Dabar pažvelkime į šios architektūros pliusus ir minusus, kad geriau suprastume, kada naudoti šią architektūrą.

„Microsoft“ paslaugų architektūros pliusai ir minusai

Žr. Toliau pateiktą lentelę.

Supraskime daugiau apie „Microservices“, palyginę ankstesnę UBER architektūrą su dabartine.

UBER ATVEJO TYRIMAS

Ankstesnė UBER architektūra

Kaip ir daugelis pradedančiųjų, UBER savo kelionę pradėjo monolitine architektūra, pastatyta už vieną pasiūlymą viename mieste. Atrodė, kad tuo metu viena kodų bazė buvo išvalyta ir išsprendė pagrindines UBER verslo problemas. Tačiau kai UBER pradėjo plėstis visame pasaulyje, jie griežtai susidūrė su įvairiomis mastelio ir nuolatinės integracijos problemomis.

4 paveikslas: Monolitinė UBER architektūra - „Microservice Architecture“

Aukščiau pateiktoje diagramoje pavaizduota ankstesnė UBER architektūra.

„java“ programos „fibonacci“ serijoms

• Yra REST API, su kuria susisiekia keleivis ir vairuotojas.
• Trys skirtingi adapteriai yra naudojami su API jose, norint atlikti tokius veiksmus kaip atsiskaitymas, mokėjimai, el. Laiškų / pranešimų siuntimas, kuriuos matome užsisakydami kabiną.
• „MySQL“ duomenų bazė, kurioje saugomi visi jų duomenys.

Taigi, jei pastebėsite čia visas funkcijas, tokias kaip keleivių valdymas, atsiskaitymas, pranešimų funkcijos, mokėjimai, kelionės valdymas ir vairuotojų valdymas, sudarė viena sistema.

Problemos pareiškimas

Nors UBER pradėjo plėstis visame pasaulyje, tokia sistema kėlė įvairių iššūkių. Toliau pateikiami keli svarbiausi iššūkiai

• Norint atnaujinti vieną funkciją, reikėjo iš naujo sukurti, įdiegti ir išbandyti visas funkcijas.
• Ištaisyti klaidas tapo labai sunku vienoje saugykloje, nes kūrėjams reikėjo vėl ir vėl pakeisti kodą.
• Funkcijų mastelio keitimas kartu su naujų funkcijų įdiegimu visame pasaulyje buvo gana sunkus kartu.

Sprendimas

Siekdamas išvengti tokių problemų, UBER nusprendė pakeisti savo architektūrą ir sekti kitas hiperaugančias įmones, tokias kaip „Amazon“, „Netflix“, „Twitter“ ir daugelį kitų. Taigi UBER nusprendė suskaidyti savo monolitinę architektūrą į kelias kodų bazes, kad suformuotų mikropaslaugų architektūrą.

Žiūrėkite žemiau esančią diagramą, kad pažvelgtumėte į UBER mikropaslaugų architektūrą.

5 paveikslas: UBER mikro paslaugų architektūra - Microservice architektūra

• Pagrindinis mūsų pastebimas pokytis yra „API Gateway“ įvedimas, per kurį visi vairuotojai ir keleiviai yra sujungti. Iš „API Gateway“ yra susieti visi vidiniai taškai, tokie kaip keleivių valdymas, vairuotojų valdymas, kelionių valdymas ir kiti.
• Padaliniai yra atskiri atskiri dislokuojami vienetai, atliekantys atskiras funkcijas.
  • Pavyzdys: Jei norite ką nors pakeisti atsiskaitymo „Microsoft“ paslaugose, tiesiog turite diegti tik atsiskaitymo „Microsoft“ paslaugas ir nereikia diegti kitų.
• Dabar visos funkcijos buvo masto atskirai, t. Y. Buvo panaikinta kiekvienos savybės tarpusavio priklausomybė.
  • Pavyzdžiui, mes visi žinome, kad žmonių, ieškančių kabinų, yra daugiau nei žmonių, kurie iš tikrųjų užsisako kabiną ir moka. Tai leidžia daryti išvadą, kad procesų, dirbančių su keleivių valdymo mikroservisa, skaičius yra didesnis nei su mokėjimais susijusių procesų skaičius.

Šiamebūdu, UBER gavo naudos dėl perėjimojosarchitektūra nuo monolitinės iki mikropaslaugų.

Tikiuosi, kad jums patiko skaityti šį įrašą „Microservice Architecture“.Aš sugalvosiu daugiau tinklaraščių, kuriuose taip pat bus praktinių žinių.
Norite sužinoti daugiau apie mikroservisus?

Jei norite išmokti „Microsoft“ paslaugų ir kurti savo programas, peržiūrėkite mūsų kuris ateina su instruktorių vedamomis tiesioginėmis treniruotėmis ir realių projektų patirtimi. Šie mokymai padės jums išsamiau suprasti „Microsoft“ paslaugas ir padės įsisavinti šį dalyką.

Turite mums klausimą? Prašau paminėti tai komentarų skiltyje “ Mikroserviso architektūra “Ir aš susisieksiu su jumis.