Konteksti

Kehität palvelinpuolen yrityssovellusta. Sen on tuettava useita erilaisia asiakkaita, kuten työpöydän selaimet, mobiiliselaimet ja alkuperäiset mobiilisovellukset.Sovellus saattaa myös paljastaa API: n kolmansien osapuolten kulutettavaksi.Se voi myös integroitua muihin sovelluksiin joko verkkopalveluiden tai viestivälittäjän kautta.Sovellus käsittelee pyynnöt (HTTP-pyynnöt ja viestit) suorittamalla liiketoimintalogiikkaa pääsy tietokantaan; viestien vaihto muiden järjestelmien kanssa; ja palautetaan HTML / JSON / XML-vastaus. On olemassa loogisia komponentteja, jotka vastaavat sovelluksen eri toiminnallisia alueita.

Ongelma

Mikä on sovelluksen asennusarkkitehtuuri?

Voimat

• Sovellusta kehittää joukko kehittäjiä
• Uusien tiimin jäsenten on nopeasti tullut tuottavia
• Sovelluksen on oltava helppo ymmärtää ja muokkaa
• Haluat harjoitella sovelluksen jatkuvaa käyttöönottoa
• Sinun on suoritettava useita sovelluksen esiintymiä useilla koneilla skaalautuvuus- ja käytettävyysvaatimusten täyttämiseksi
• Haluat hyödyntää uusia tekniikoita (kehykset, ohjelmointikielet jne.)

Ratkaisu

Määritä arkkitehtuuri, joka rakentaa sovelluksen joukoksi löyhästi kytkettyjä, yhteistyöpalvelut.Tämä lähestymistapa vastaa Scale Cuben Y-akselia. Jokainen palvelu on:

• erittäin huollettava ja testattava – mahdollistaa ra pidkä ja säännöllinen kehittäminen ja käyttöönotto
• Löyhästi yhdistettynä muihin palveluihin – antaa tiimille mahdollisuuden työskennellä itsenäisesti suurimman osan ajasta palveluissaan ilman, että muut muutokset vaikuttavat muihin palveluihin ja vaikuttamatta muihin palveluihin
• Itsenäisesti käyttöönotettava – mahdollistaa tiimin käyttöön palvelunsa ilman, että hänen on koordinoitava muiden tiimien kanssa
• Pienet tiimit pystyvät kehittämään – välttämätöntä korkean tuottavuuden kannalta välttämällä suurten viestintäjohtajien korkeaa tasoa joukkueet

Palvelut kommunikoivat joko synkronisilla protokollilla, kuten HTTP / REST, tai asynkronisilla protokollilla, kuten AMQP. Palveluja voidaan kehittää ja ottaa käyttöön toisistaan riippumatta. Jokaisella palvelulla on oma tietokanta Palvelujen välinen tietojen yhdenmukaisuus ylläpidetään Saga-mallin avulla.

Lue lisätietoja palvelun luonteesta lukemalla tämä artikkeli.

Esimerkkejä

Fiktiivinen sähköisen kaupankäynnin sovellus päällä

Kuvitelkaamme, että rakennat verkkokauppasovellusta, joka ottaa asiakkailta tilauksia, tarkistaa varaston ja käytettävissä olevat luottotiedot sekä toimittaa ne. Sovellus koostuu useista komponenteista, mukaan lukien StoreFrontUI, joka toteuttaa käyttöliittymän. yhdessä joidenkin taustapalvelujen kanssa luottojen tarkistamiseksi, varaston ylläpitämiseksi ja toimitustilausten suorittamiseksi.Sovellus koostuu joukosta palveluita.

Näytä koodi

Katso Chris Richardsonin kehittämiä esimerkkisovelluksia. Nämä Githubin esimerkit havainnollistavat mikropalveluarkkitehtuurin eri näkökohtia.

Tuloksellinen konteksti

Edut

Tällä ratkaisulla on useita etuja:

• Mahdollistaa suurten, monimutkaisten sovellusten jatkuvan toimituksen ja käyttöönoton.
  • Parannettu ylläpidettävyys – jokainen palvelu on suhteellisen pieni, joten sitä on helpompi ymmärtää ja muuttaa
  • Parempi testattavuus – palvelut ovat pienempiä ja testattavia nopeammin
  • Parempi käyttöönotto – palvelut voidaan ottaa käyttöön itsenäisesti
  • Sen avulla voit organisoida kehitystyön useiden itsenäisten tiimien ympärille. Jokainen (ns. Kaksi pizzaa) joukkue omistaa yhden tai useamman palvelun ja on vastuussa niistä. Jokainen joukkue voi kehittää, testata, ottaa käyttöön ja laajentaa palveluitaan itsenäisesti kaikista muista tiimeistä.
• Jokainen mikropalvelu on suhteellisen pieni:
  • Helpompi kehittäjä ymmärtää
  • IDE nopeuttaa kehittäjien tuottavuutta
  • Sovellus käynnistyy nopeammin, mikä tekee kehittäjistä tuottavampia ja nopeuttaa käyttöönottoa
• Parempi vianeristys. Esimerkiksi, jos yhdessä palvelussa on muistivuoto, se vaikuttaa vain kyseiseen palveluun, muut palvelut jatkavat pyyntöjen käsittelyä, verrattuna siihen, että monoliittisen arkkitehtuurin yksi väärin toimiva osa voi kaataa koko järjestelmän.
• Poistaa pitkäaikaisen sitoutumisen tekniikkapinoihin. Kun kehität uutta palvelua, voit valita uuden tekniikkapinon. Samalla tavalla, kun teet suuria muutoksia olemassa olevaan palveluun, voit kirjoittaa sen uudella tekniikkapinolla.

Haitat

Tällä ratkaisulla on useita haittoja:

• Kehittäjien on käsiteltävä hajautetun järjestelmän luomisen monimutkaisuutta:
  • Kehittäjien on otettava käyttöön palvelujen välinen viestintämekanismi ja puututtava osittaiseen epäonnistumiseen
  • Useita palveluita kattavien pyyntöjen toteuttaminen on vaikeampi
  • Palvelujen välisten vuorovaikutusten testaaminen on helpompaa vaikea
  • Useita palveluja kattavien pyyntöjen toteuttaminen vaatii tiimien huolellista koordinointia
  • Kehittäjien työkalut / IDE: t ovat suuntautuneet monoliittisten sovellusten rakentamiseen eivätkä tarjoa nimenomaista tukea hajautettujen sovellusten kehittämiseen. / li>
• Käyttöönoton monimutkaisuus. Tuotannossa on myös toiminnallista monimutkaisuutta monista eri palveluista koostuvan järjestelmän käyttöönotossa ja hallinnassa.
• Lisääntynyt muistin kulutus. Mikropalveluarkkitehtuuri korvaa N monoliittista sovellusinstanssia NxM-palveluinstansseilla. Jos jokainen palvelu toimii omalla JVM: llä (tai vastaavalla), mikä on yleensä välttämätöntä esiintymien eristämiseksi, niin M: n yleiskustannukset ovat niin monta kertaa kuin JVM: n ajon. Lisäksi, jos jokainen palvelu toimii omalla virtuaalikoneellaan (esim. EC2-esiintymä), kuten Netflixissä tapahtuu, yleiskustannukset ovat vielä korkeammat.

Ongelmat

On olemassa monia asioita, jotka sinun on käsiteltävä.

Milloin mikropalveluarkkitehtuuria käytetään?

Yksi haaste tämän lähestymistavan käytössä on päättää, milloin on järkevää käyttää sitä. sovelluksessa sinulla ei usein ole ongelmia, jotka tämä lähestymistapa ratkaisee. Lisäksi kehittyneen, hajautetun arkkitehtuurin käyttö hidastaa kehitystä. tämä voi olla suuri ongelma startup-yrityksille, joiden suurin haaste on usein liiketoimintamallin nopea kehittyminen ja siihen liittyvä Y-akselin halkeamien käyttäminen saattaa vaikeuttaa nopeaa iterointia. Myöhemmin kuitenkin, kun haasteena on mittakaava ja sinun on käytettävä toiminnallista hajotusta, sotkeutuneet riippuvuudet saattavat vaikeuttaa monoliittisen sovelluksen hajottamista joukko palveluja.

Kuinka hajottaa sovellus palveluihin?

Toinen haaste on päättää, miten järjestelmä ositetaan mikropalveluihin. Tämä on hyvin taidetta, mutta monia strategioita voi auttaa:

• Hajoaa liiketoimintakyvyn mukaan ja määritä liiketoiminnan ominaisuuksia vastaavat palvelut.
• Hajoaa toimialueella toimivan suunnittelun aliverkkotunnuksen avulla.
• Hajoaa verbillä tai käyttötapauksella ja määritä palvelut, jotka ovat vastuussa tietyistä toimista. . esimerkiksi. Shipping Service, joka vastaa kokonaisten tilausten toimittamisesta.
• Hajoaa substantiivien tai resurssien mukaan määrittelemällä palvelu, joka vastaa kaikista tietyn yksikön / resurssien toiminnoista. tyyppi. esimerkiksi. Account Service, joka vastaa käyttäjätilien hallinnoinnista.

Ihannetapauksessa jokaisella palvelulla tulisi olla vain pieni joukko vastuita. (Setä) Bob Martin puhuu luokkien suunnittelusta yhden vastuun periaatteen (SRP) avulla. SRP määrittelee luokan vastuun syynä muutokseen ja toteaa, että luokalla pitäisi olla vain yksi syy muuttaa. on järkevää soveltaa SRP: tä palvelun suunnitteluun samoin.

Toinen analogia, joka auttaa palvelujen suunnittelussa, on Unix-apuohjelmien suunnittelu. Unix tarjoaa suuren määrän apuohjelmia, kuten grep, cat ja find. Jokainen apuohjelma tekee täsmälleen yhden asian, usein poikkeuksellisen hyvin, ja se on tarkoitettu yhdistettäväksi muiden apuohjelmien kanssa käyttämällä komentosarjakomentosarjaa monimutkaisten tehtävien suorittamiseen.

Kuinka ylläpitää tietojen johdonmukaisuutta?

Löysän kytkennän varmistamiseksi jokaisella palvelulla on oma Palvelujen välisen tietojen yhdenmukaisuuden ylläpitäminen on haaste, koska kaksi vaiheen sitoutumista / hajautettua tapahtumaa ei ole vaihtoehto useille sovelluksille. sovelluksen on sen sijaan käytettävä Saga-mallia. palvelu julkaisee tapahtuman, kun sen tiedot muuttuvat. muut palvelut kuluttavat tapahtumaa ja päivittävät tiedot. on useita tapoja päivittää tietoja luotettavasti ja julkaista tapahtumia, mukaan lukien tapahtumien hankinta ja Tapahtumalokin räätälöinti.

Kuinka kyselyitä toteutetaan?

Toinen haaste on sellaisten kyselyjen toteuttaminen, joiden on haettava useiden palveluiden omistamat tiedot.

• Sovellusliittymä Sommittelun ja komentokyselyn vastuullisuuden erottelumallit (CQRS).

Mikropalvelukuvioon liittyy monia kuvioita. Monoliittinen arkkitehtuuri on vaihtoehto mikropalveluarkkitehtuurille.Muut mallit korjaavat ongelmat, joita kohtaat käyttäessäsi mikropalveluarkkitehtuuria.

• Hajoamismallit
  • Hajoavat liiketoimintakyvyn mukaan
  • Hajoavat aliverkkotunnuksen mukaan
• Palvelukohtainen tietokanta kuvaa, miten kukin palvelulla on oma tietokanta löysän kytkennän varmistamiseksi.
• API-yhdyskäytävän malli määrittelee, miten asiakkaat pääsevät palveluihin mikropalveluarkkitehtuurissa.
• Asiakaspuolen etsintä- ja palvelinpuolen etsintämalleja käytetään asiakkaan pyyntöjen reitittämiseen käytettävissä oleva palvelujärjestelmä mikropalveluarkkitehtuurissa.
• Viestintä- ja etäkäytäntöjen kutsumallit ovat kahta eri tapaa, joilla palvelut voivat kommunikoida.
• Yksi palvelu isäntää kohti ja useita palveluja isäntää kohti ovat kaksi erilaista käyttöönottostrategiaa.
• Monialaiset huolenaiheet: Microservice-alustakuvio ja ulkoistettu kokoonpano
• Testausmallit: Palvelukomponenttitesti ja Palvelun integrointisopimustesti
• Piiri Katkaisija
• Pääsykoodi
• Havaittavuusmallit:
  • Lokien yhdistäminen
  • Sovellustiedot
  • Tarkastusloki
  • Hajautettu jäljitys
  • Poikkeusten seuranta
  • Terveystarkastus-sovellusliittymä
  • Loki käyttöönotot ja muutokset
• Käyttöliittymämallit:
  • Palvelinpuolen sivun fragmenttien koostumus
  • Asiakaspuolen käyttöliittymän koostumus

Tunnetut käyttötarkoitukset

Suurin osa laajamittaisista verkkosivustoista, mukaan lukien Netflix, Amazon ja eBay, on kehittynyt monoliittisesta arkkitehtuurista mikropalveluarkkitehtuuriksi.

Netflix, joka on erittäin suosittu videoiden suoratoistopalvelu, joka on vastuussa jopa 30% Internet-liikenteestä, sillä on laajamittainen, palvelukeskeinen arkkitehtuuri. He käsittelevät yli miljardi puhelua päivässä videoiden suoratoistosovellusliittymään yli 800 erilaisesta laitteesta. Jokainen API-puhelufani keskimäärin kuuteen puhelut taustapalveluihin.

Amazon.comilla oli alun perin kaksitasoinen arkkitehtuuri. Mittakaavassa ne siirtyivät palvelusuuntautuneeseen arkkitehtuuriin, joka koostui sadoista backend-palveluista. Useat sovellukset kutsuvat näitä palveluja, mukaan lukien sovellukset jotka toteuttavat Amazon.com-verkkosivuston ja verkkopalvelun sovellusliittymän. Amazon.com-verkkosovellus soittaa 100-150 palveluun saadakseen tiedot, joita aiemmin käytettiin verkkosivun rakentamiseen.

Huutokauppasivusto ebay.com kehittyi myös monoliittisesta arkkitehtuurista palvelukeskeiseksi arkkitehtuuriksi. Sovellustaso koostuu useista itsenäisistä sovelluksista. Jokainen sovellus toteuttaa liiketoimintalogiikan jokainen sovellus käyttää X-akselin halkeamia ja jotkut sovellukset, kuten haku, käyttävät Z-akselin jakoja. Ebay.com käyttää myös X-, Y- ja Z-tyylisen skaalauksen yhdistelmää tietokantataso.

On olemassa monia muita esimerkkejä yrityksistä, jotka käyttävät mikropalveluarkkitehtuuria.

Chris Richardsonilla on esimerkkejä mikropalvelupohjaisista sovelluksista.

Katso myös

Katso Code Freeze 2018 -puheenvuoroni, joka tarjoaa hyvän johdannon mikropalveluarkkitehtuuriin.