Mikroservicearkkitehtuuri - Opi, rakenna ja ota käyttöön mikropalveluja

Microservice-arkkitehtuuri:

Minulta , sinulla on oltava perustiedot Microservice-arkkitehtuurista.Mutta olla ammattilainen vaatii enemmän kuin vain perusasiat. Tässä blogissa pääset arkkitehtonisten käsitteiden syvyyteen ja toteutat ne UBER-tapaustutkimuksen avulla.

Tässä blogissa opit seuraavista:

• Määritelmä mikropalveluarkkitehtuuri
• Mikropalveluarkkitehtuurin keskeiset käsitteet
• Hyödyt ja haitat mikropalveluarkkitehtuurille
• UBER - tapaustutkimus

Voit viitata , ymmärtää mikropalvelujen perusteet ja edut.

Se on reilua vain, jos annan sinulle mikropalvelujen määritelmän.

Määritelmä mikropalvelut

Sellaisena ei ole asianmukaista määritelmää Microservices alias Microservice Architecture, mutta voit sanoa, että se on kehys, joka koostuu pienistä, erikseen asennettavista palveluista, jotka suorittavat erilaisia ​​toimintoja.

Mikropalvelut keskittyvät yhteen liiketoiminta-alueeseen, joka voidaan toteuttaa täysin itsenäisinä käyttöönotettavina palveluina ja toteuttaa ne erilaisissa teknologiapinoissa.

Kuvio 1: Ero monoliittisen ja Microservice-arkkitehtuurin välillä - Microservice Architecture

Katso yllä olevasta kaaviosta ymmärtääksesi eron monoliittisen ja mikropalveluarkkitehtuurin välillä.Saadaksesi paremman käsityksen molempien arkkitehtuurien eroista, voit viitata edelliseen blogiini

miten ottaa kuvakaappaus seleenissä

Jotta voisit ymmärtää paremmin, haluan kertoa sinulle joitain mikropalveluarkkitehtuurin keskeisiä käsitteitä.

Mikropalveluarkkitehtuurin keskeiset käsitteet

Ennen kuin aloitat omien sovellusten rakentamisen mikropalvelujen avulla, sinun on oltava selvillä sovelluksesi laajuudesta ja toiminnoista.

Seuraavassa on joitain ohjeita, joita on noudatettava keskusteltaessa mikropalveluista.

Ohjeet mikropalvelujen suunnittelussa

• Kehittäjänä, kun päätät rakentaa sovelluksen, erota toimialueet ja ole selkeä toiminnoille.
• Jokainen suunnittelema mikropalvelu tulee keskittyä vain yhteen sovelluksen palveluun.
• Varmista, että olet suunnitellut sovelluksen siten, että jokainen palvelu voidaan ottaa käyttöön erikseen.
• Varmista, että mikropalvelujen välinen tiedonsiirto tapahtuu valtiottoman palvelimen kautta.
• Kukin palvelu voidaan jakaa uudelleen pienempiin palveluihin, joilla on omat mikropalvelut.

Nyt kun olet lukenut perusohjeet mikropalveluja suunniteltaessa, ymmärretään mikropalvelujen arkkitehtuuri.

Kuinka Microservice-arkkitehtuuri toimii?

Tyypillisen Microservice Architecture (MSA): n tulisi koostua seuraavista komponenteista:

1. Asiakkaat
2. Henkilöllisyyden tarjoajat
3. Yhdyskäytävän sovellusliittymä
4. Viestintämuodot
5. Tietokannat
6. Staattinen sisältö
7. Johto
8. Palvelun löytäminen

Katso alla olevaa kaaviota.

Kuva 2: Mikropalvelujen arkkitehtuuri - Mikropalvelujen arkkitehtuuri

Tiedän, että arkkitehtuuri näyttää hieman monimutkaiselta, mutta annaMinäyksinkertaista sitä sinulle.

1. Asiakkaat

Arkkitehtuuri alkaa erityyppisistä asiakkaista, eri laitteista, jotka yrittävät suorittaa erilaisia ​​hallintatoimintoja, kuten haku, koontityö, konfigurointi jne.

2. Henkilöllisyyden tarjoajat

Nämä asiakkaiden pyynnöt välitetään sitten henkilöllisyyden tarjoajille, jotka todentavat asiakkaiden pyynnöt ja ilmoittavat pyynnöt API-yhdyskäytävälle. Pyynnöt välitetään sitten sisäisille palveluille hyvin määritellyn API-yhdyskäytävän kautta.

3. API-yhdyskäytävä

Koska asiakkaat eivät soita palveluihin suoraan, API-yhdyskäytävä toimii lähtökohtana asiakkaille välittämään pyynnöt sopiville mikropalveluille.

API-yhdyskäytävän käytön etuja ovat:

• Kaikki palvelut voidaan päivittää ilman, että asiakkaat tietävät siitä.
• Palvelut voivat käyttää myös viestejä, jotka eivät ole web-ystävällisiä.
• API-yhdyskäytävä voi suorittaa monialaisia ​​toimintoja, kuten tarjota turvallisuutta, kuormituksen tasapainottamista jne.

Vastaanotettuaan asiakkaiden pyynnöt sisäinen arkkitehtuuri koostuu mikropalveluista, jotka kommunikoivat keskenään viestien kautta käsittelemään asiakaspyyntöjä.

4. Viestintämuodot

Viestejä on kahdenlaisia:

• Synkroniset viestit: Mikäli asiakkaat odottavat vastauksia palvelulta, Microservices yleensä käyttää REST (edustuksellinen valtion siirto) koska se perustuu kansalaisuuteen, asiakaspalvelimeen ja HTTP-protokolla . Tätä protokollaa käytetään, koska se on hajautettu ympäristö, jokainen toiminto on edustettu resurssilla toimintojen suorittamiseen
• Asynkroniset viestit: Mikäli asiakkaat eivät odota vastauksia palvelulta, Microservices käyttää yleensä protokollia, kuten AMQP, STOMP, MQTT . Näitä protokollia käytetään tämän tyyppisessä viestinnässä, koska viestien luonne on määritelty ja näiden sanomien on oltava yhteentoimivia toteutusten välillä.

Seuraava kysymys, joka saattaa tulla mieleesi, on se, miten Microservice-palveluja käyttävät sovellukset käsittelevät tietojaan?

ulottuu ja toteuttaa yhdessä java

5. Tietojen käsittely

Jokainen Microservice omistaa yksityisen tietokannan tietojen keräämiseksi ja vastaavien liiketoimintojen toteuttamiseksi, ja Microsoft-palveluiden tietokannat päivitetään myös vain niiden palvelusovellusliittymän kautta. Katso seuraava kaavio:

Kuva 3: Esitys mikropalveluista, jotka käsittelevät tietoja - Microservice Architecture

Microservicesin tarjoamat palvelut siirretään mihin tahansa etäpalveluun, joka tukee prosessien välistä viestintää eri tekniikkapinoille.

6. Staattinen sisältö

Kun mikropalvelut ovat yhteydessä toisiinsa, ne käyttävät staattista sisältöä pilvipohjaiseen tallennuspalveluun, joka voi toimittaa sen suoraan asiakkaille Sisältötoimitusverkot (CDN) .

Edellä mainittujen komponenttien lisäksi tyypillisessä Microservices-arkkitehtuurissa on joitain muita komponentteja:

7. Hallinto

Tämä komponentti on vastuussa palvelujen tasapainottamisesta solmuissa ja vikojen tunnistamisesta.

8. Palvelujen löytäminen

Toimii ohjeena mikropalveluille löytääksesi välisen kommunikaatioreitin, koska se ylläpitää luetteloa palveluista, joissa solmut sijaitsevat.

kierrosohjelma c

Tilaa youtube-kanavamme saadaksesi uusia päivityksiä ..!

Tarkastellaan nyt tämän arkkitehtuurin etuja ja haittoja saadaksemme paremman käsityksen siitä, milloin tätä arkkitehtuuria tulee käyttää.

Hyödyt ja haitat Microservice Architecture -sivustolta

Katso alla olevaa taulukkoa.

Ymmärretään lisää Microservices-palveluista vertaamalla UBER: n edellistä arkkitehtuuria nykyiseen.

UBER-TAPAUSTUTKIMUS

UBER: n edellinen arkkitehtuuri

Kuten monet startupit, UBER aloitti matkansa monoliittisella arkkitehtuurilla, joka rakennettiin yhdelle tarjoukselle yhdessä kaupungissa. Yhden koodipohjan käyttäminen tuntui tuolloin puhdistetulta ja ratkaisi UBERin ydinliiketoiminnan ongelmat. Kun UBER alkoi laajentua maailmanlaajuisesti, heillä oli kuitenkin tiukat erilaiset ongelmat skaalautuvuuden ja jatkuvan integraation suhteen.

Kuva 4: UBER: n monoliittinen arkkitehtuuri - Microservice Architecture

Yllä oleva kaavio kuvaa UBER: n edellistä arkkitehtuuria.

• REST-sovellusliittymä on läsnä, johon matkustaja ja kuljettaja muodostavat yhteyden.
• API: n sisällä käytetään kolmea erilaista sovitinta, jotta voidaan suorittaa toimintoja, kuten laskutus, maksut, sähköpostien / viestien lähettäminen, jotka näemme varaamalla taksin.
• MySQL-tietokanta kaikkien tietojen tallentamiseen.

Joten, jos huomaat täällä, kaikki ominaisuudet, kuten matkustajien hallinta, laskutus, ilmoitusominaisuudet, maksut, matkanhallinta ja kuljettajien hallinta, koostettiin yhdessä kehyksessä.

Ongelma

Vaikka UBER alkoi laajentua maailmanlaajuisesti, tällainen kehys toi mukanaan erilaisia ​​haasteita. Seuraavassa on joitain merkittävimpiä haasteita

• Kaikki ominaisuudet oli rakennettava uudelleen, otettava käyttöön ja testattava uudestaan ​​ja uudestaan ​​yhden ominaisuuden päivittämiseksi.
• Virheiden korjaamisesta tuli erittäin vaikeaa yhdessä arkistossa, kun kehittäjien oli vaihdettava koodia uudestaan ​​ja uudestaan.
• Ominaisuuksien skaalaus samanaikaisesti uusien ominaisuuksien käyttöönoton kanssa kaikkialla maailmassa oli melko vaikeaa käsitellä yhdessä.

Ratkaisu

Tällaisten ongelmien välttämiseksi UBER päätti muuttaa arkkitehtuuriaan ja seurata muita hyperkasvuyrityksiä, kuten Amazon, Netflix, Twitter ja monet muut. Siksi UBER päätti jakaa monoliittisen arkkitehtuurinsa useisiin kooditukiin mikropalveluarkkitehtuurin muodostamiseksi.

Katso alla olevasta kaaviosta UBER: n mikropalveluarkkitehtuuri.

Kuva 5: UBER: n mikropalveluarkkitehtuuri - Microservice -arkkitehtuuri

• Suurin muutos, jonka havaitsemme tässä, on API-yhdyskäytävän käyttöönotto, jonka kautta kaikki kuljettajat ja matkustajat ovat yhteydessä toisiinsa. API-yhdyskäytävästä on kytketty kaikki sisäiset pisteet, kuten matkustajien hallinta, kuljettajien hallinta, matkanhallinta ja muut.
• Yksiköt ovat yksittäisiä erillisiä käyttöönotettavia yksiköitä, jotka suorittavat erillisiä toimintoja.
  • Esimerkki: Jos haluat muuttaa mitään laskutusmikro-palveluissa, sinun on vain otettava käyttöön vain laskutusmikro-palvelut eikä sinun tarvitse ottaa muita käyttöön.
• Kaikkia ominaisuuksia skaalattiin nyt erikseen, eli kunkin ominaisuuden välinen riippuvuus poistettiin.
  • Esimerkiksi, me kaikki tiedämme, että ohjaamoja etsivien ihmisten määrä on verrattain enemmän kuin henkilöiden, jotka todella varaavat taksin ja suorittavat maksuja. Tästä voimme päätellä, että matkustajien hallinnan mikropalvelussa työskentelevien prosessien määrä on enemmän kuin maksujen parissa työskentelevien prosessien määrä.

Tässätapa, UBER hyötyi siirtymisestäsenarkkitehtuuri monoliittisesta mikropalveluihin.

Toivottavasti olet nauttinut tämän viestin lukemisesta Microservice Architecture -sivustolla.Tulen tulemaan lisää blogeja, jotka sisältävät myös käytännön.
Haluatko tietää enemmän mikropalveluista?

Jos haluat oppia mikropalveluja ja rakentaa omia sovelluksiasi, tutustu meidän joka sisältää ohjaajan vetämän live-koulutuksen ja tosielämän projektikokemuksen. Tämä koulutus auttaa sinua ymmärtämään mikropalveluja perusteellisesti ja saavuttamaan aiheen hallinnan.

Onko sinulla kysymys meille? Mainitse se kommenttiosassa ” Mikropalveluarkkitehtuuri ”Ja palaan takaisin sinuun.