Lähes jokainen tietokonejärjestelmä suorittaa useita tehtäviä käyttämällä jaettuja resursseja, ja yksi tietokoneohjelmoinnin kysymyksistä on se, kuinka tiiviisti nämä tehtävät suorittavat koodibitit tulisi sitoa toisiinsa. Yhä suositumpi vastaus on mikropalvelun käsite—pieni, erillinen toiminto, joka on vuorovaikutuksessa muiden mikropalveluiden kanssa suuremman järjestelmän luomiseksi.
Vaikka perusajatus tällaisten erillisten komponenttien käytöstä ei ole uusi, tapa, jolla mikropalvelut toteutetaan, tekee niistä luonnollisen perustan molemmille nykyaikaisille pilvipohjaisille sovelluksille. Mikropalvelut sopivat yhteen myös devops-filosofian kanssa, joka kannustaa nopeasti ja jatkuvasti kehittämään uusia toimintoja.
Mitä ovat mikropalvelut?
Mikropalvelujen "mikro" tarkoittaa, että nämä ovat pieniä sovelluksia. Se on joskus totta, mutta parempi tapa ajatella heitä on, että heidän pitäisi olla vain niin suuria kuin tarvitaan yhden tietyn asian tekemiseksi tai tietyn ongelman ratkaisemiseksi. Tämän ongelman tulisi olla käsitteellinen, ei tekninen. Kuten Microsoft sanoo, "mikropalvelut tulisi suunnitella liiketoiminnan ominaisuuksien, ei horisontaalisten tasojen, kuten tietojen saatavuuden tai viestien, ympärille." He kommunikoivat muiden mikropalvelujen ja ulkopuolisten käyttäjien kanssa suhteellisen vakaiden sovellusliittymien kautta suuremman sovelluksen luomiseksi.
Siten yksittäisen mikropalvelun sisäistä toiminnallisuutta voidaan säätää tai päivittää radikaalisti vaikuttamatta muuhun järjestelmään. Tämä puolestaan liittyy siihen, miten devops-kaupat pyrkivät toimimaan: Jos suuremman sovelluksen erityiset toiminnot jaetaan erillisiin, itsenäisesti toimiviin koodikappaleisiin, on helpompaa elää CI / CD: n devops-mantraa (jatkuva integrointi ja jatkuva toimitus) . Hyvin määriteltyjen sovellusliittymien avulla mikropalvelut on helppo testata helposti.
Mikropalveluarkkitehtuuri vs. monoliittinen arkkitehtuuri
Kuulet usein, että mikropalveluista puhutaan "mikropalveluarkkitehtuurina".” Tämä lause ei sisällä vain itse mikropalveluja, vaan komponentteja hallintaan ja palvelujen löytämiseen sekä API-yhdyskäytävän, joka hoitaa mikropalvelujen ja ulkomaailman välistä viestintää.
"Monoliittinen sovellus" on päinvastainen mikrosähköpalvelujen kanssa. Se on hakusana sovellukselle, jossa kaikki koodi on yhdessä suuressa binäärisessä suoritettavassa tiedostossa. Kuten TechTarget selittää, monoliittista sovellusta on vaikea laajentaa ja sitä on vaikea parantaa. Mutta koska se on rakennettu yhtenä yhtenäisenä sovelluksena, se ei vaadi yhtä paljon hallintaa kuin mikropalveluarkkitehtuuri.
Rajoitetut käsitteet: Kuinka määritellä mikropalvelu
Palataan hetkeksi aikaisempaan käskyyn, jonka mukaan mikropalvelujen tulisi tehdä yksi tietty asia. Se on helppo sanoa, mutta käytännössä toiminnallisuus on usein sekaisin, ja jakojen piirtäminen on vaikeampi kuin miltä näyttää. Verkkotunnusanalyysi ja toimialueohjattu suunnittelu ovat teoreettisia lähestymistapoja, jotka auttavat sinua karsimaan erilliskokoisen tehtävän erillisiksi ongelmiksi, jotka mikropalvelu voi ratkaista. Tässä prosessissa, joka on kuvattu valaisevassa Microsoftin blogiviestisarjassa, luot abstraktin mallin yrityksesi verkkotunnuksesta ja löydät prosessin yhteydessä rajatut kontekstit, joka ryhmittää toiminnot, jotka ovat vuorovaikutuksessa maailman kanssa tietyllä tavalla.
Sinulla voi olla esimerkiksi yksi rajoitettu konteksti toimitukselle ja toinen tileille. Tosielämän fyysisellä esineellä olisi tietysti sekä hinta että paikka, johon sen on mentävä, mutta rajatut kontekstit edustavat erityisiä tapoja, joilla sovelluksesi ajattelee ja on vuorovaikutuksessa niiden kanssa. Jokaisen mikropalvelun tulisi olla kokonaan yhdessä rajoitetussa kontekstissa, vaikka jotkin rajatut kontekstit saattavat sisältää useamman kuin yhden mikropalvelun.
Mikropalvelut vs. palvelukeskeinen arkkitehtuuri vs. verkkopalvelut
Jos olet IT-ammattilainen, joka on ollut alalla jonkin aikaa, saatat ajatella, että tämä kuulostaa tutulta. Ajatus pienistä yksittäisistä ohjelmista yhdessä saattaa muistuttaa sinua sekä SOA: sta (palvelukeskeinen arkkitehtuuri) että verkkopalveluista, kaksi muotisanaa 2000-luvun huimaavasta Web 2.0 -päivästä. Vaikka yhdessä mielessä auringon alla ei todellakaan ole mitään uutta, näiden käsitteiden ja mikropalvelujen välillä on merkittäviä eroja. Datamationilla on eritelmät hyvin jaoteltu, mutta tässä on lyhyt versio:
- Palvelukeskeisessä arkkitehtuurissa yksittäiset komponentit ovat suhteellisen tiukasti kytkettyinä, usein jakamalla resursseja, kuten tallennustilaa, ja ne kommunikoivat erikoistietojärjestelmän kautta, jota kutsutaan yrityksen tallennusväyläksi.. Mikropalvelut ovat itsenäisempiä, jakavat vähemmän resursseja ja kommunikoivat kevyempien protokollien kautta. On syytä huomata, että mikropalvelut syntyivät SOA-ympäristöstä, ja niitä pidetään joskus eräänlaisena SOA: na tai konseptin seuraajana.
- Verkkopalvelu on julkisesti suunnattu toimintojen joukko, jota muut sovellukset voivat käyttää verkon kautta. luultavasti yleisin esimerkki on Google Maps, jonka ravintolan verkkosivusto voisi upottaa tarjoamaan ohjeita asiakkaille. Tämä on paljon löyhempi yhteys kuin mitä näisit mikropalveluarkkitehtuurissa.
Mikropalvelujen viestintä
Mikropalveluarkkitehtuureista usein kuulemmassana on, että niissä tulisi olla "älykkäät päätepisteet ja tyhmät putket". Toisin sanoen, mikropalvelujen tulisi pyrkiä käyttämään perustietoja ja vakiintuneita viestintämenetelmiä monimutkaisen ja tiukan integroinnin sijaan. Kuten huomautettiin, tämä on toinen asia, joka erottaa mikropalvelut SOA: sta.
Yleensä mikropalvelujen välisen viestinnän tulee olla asynkronista, siinä mielessä, että koodiketjut eivät ole estetty vastausten odottamisessa. (On silti hienoa käyttää synkronisia tiedonsiirtoprotokollia, kuten HTTP, vaikka asynkroniset protokollat, kuten AMQP (Advanced Message Queuing Protocol), ovat myös yleisiä mikropalveluarkkitehtuureissa.) Tällainen löysä kytkentä tekee mikropalveluarkkitehtuurista joustavamman vian edessä verkon yksittäisten komponenttien tai osien käyttö, mikä on keskeinen etu.
Mikropalvelut, Java ja Spring Boot and Spring Cloud
Jotkut ensimmäisistä työstä mikropalveluissa syntyivät Java-yhteisössä; Martin Fowler oli varhainen kannattaja. Puolassa vuonna 2012 järjestetyssä Java-konferenssissa esiteltiin yksi tärkeimmistä aihealueista, nimeltään “Micro services - Java, the Unix Way.” Se suositteli periaatteiden soveltamista, jotka ohjaivat 1970-luvun ensimmäisten Unix-sovellusten kehitystä (“Write ohjelmat, jotka tekevät yhden asian ja tekevät sen hyvin. Kirjoita ohjelmat toimimaan yhdessä ”) Java-kehitykseen.
Tämän historian seurauksena on paljon Java-kehyksiä, joiden avulla voit rakentaa mikropalveluja. Yksi suosituimmista on Spring Boot, joka on suunniteltu erityisesti mikropalveluihin; Käynnistystä laajentaa Spring Cloud, mikä, kuten nimestä voi päätellä, antaa sinun ottaa nämä palvelut käyttöön myös pilvessä. Springin kehittäjällä Pivotal Software on hyvä opastus mikropalvelukehityksen aloittamiseen näiden kehysten avulla.
Mikropalvelut ja kontit: Docker, Kubernetes ja muualla
Taustalla oleva tekniikka, joka on mennyt pisimmälle kohti mikropalvelujen saamista valtavirtaan, on kontit. Säilö on samanlainen kuin virtuaalikoneen esiintymä, mutta sen sijaan, että se sisältäisi koko itsenäisen käyttöjärjestelmän, säilö on vain eristetty käyttäjätila, joka käyttää isäntäkäyttöjärjestelmän ydintä, mutta muuten pitää koodin suorittamisen sisällä itsenäisenä. Säiliöt ovat paljon pienempiä kuin virtuaalikoneiden esiintymät, ja ne on helppo ottaa nopeasti käyttöön joko paikallisesti tai pilvessä, ja ne voidaan pyörittää ylös tai alas vastaamaan kysyntää ja käytettävissä olevia resursseja.
Mikropalvelujen säiliöiden houkuttelevuuden tulisi olla ilmeistä: Jokainen yksittäinen mikropalvelu voi toimia omassa säiliössään, mikä vähentää huomattavasti palvelujen hallinnan yleiskustannuksia. Useimmissa konttitoteutuksissa on täydentävät orkestrointityökalut, jotka automatisoivat konttipohjaisten sovellusten käyttöönoton, hallinnan, skaalauksen, verkostoitumisen ja saatavuuden. Se on pienten, helposti rakennettavien mikropalvelujen ja helposti asennettavien säiliöiden yhdistelmä, joka tekee devops-filosofia mahdolliseksi. Konttikonseptia on useita toteutuksia, mutta ylivoimaisesti suosituin on Docker, joka on yleensä pariksi Kubernetesin kanssa orkesterointialustana.
Vaikka kevät onkin suosittu, se on sidottu Java-alustaan. Konttipohjaiset järjestelmät ovat toisaalta polyglotteja: Kaikki käyttöjärjestelmän tukemat ohjelmointikielet voivat toimia kontissa, mikä antaa ohjelmoijille enemmän joustavuutta. Mikropalveluiden suuri etu on, että jokainen yksittäinen palvelu voidaan kirjoittaa millä tahansa kielellä, jolla on järkevintä tai jota kehittäjät viihtyvät parhaiten. Palvelu voitaisiin todellakin rakentaa kokonaan uudella kielellä vaikuttamatta koko järjestelmään, kunhan sen sovellusliittymät pysyvät vakaina. DZonella on artikkeli, joka käsittelee Spring Cloudin ja Kubernetesin etuja ja haittoja mikropalveluille.
Mikropalvelujen suunnittelumallit
Huolimatta siitä, mitä kieltä käytät mikropalvelujen kehittämiseen, kohtaat ongelmia, joita muut kehittäjät ovat aiemmin kohdanneet. Suunnittelumallit ovat virallisia, abstrakteja ratkaisuja toistuviin tietojenkäsittelytieteen ongelmiin, ja monet niistä on tarkoitettu nimenomaan mikropalveluihin. Devopedialla on loistava luettelo, joka sisältää:
- Palvelurekisteri: asiakkaiden yhdistämiseksi käytettävissä oleviin mikropalvelujen ilmentymiin
- Katkaisija: estää epäonnistuneita palveluja soittamasta toistuvasti
- Varaus: vaihtoehdon tarjoamisesta epäonnistuneelle palvelulle
- Sivuvaunu: apupalvelun tarjoamiseksi pääsäiliölle, kuten kirjaaminen, palvelujen synkronointi tai valvonta
- Sovitin: pääsäiliön ja ulkomaailman välisen rajapinnan standardointi tai normalisointi
- Suurlähettiläs: Yhdistä pääsäiliö ulkomaailmaan, esimerkiksi lähiverkkoyhteyksien välittämiseksi ulkoyhteyksiin
Mikropalvelut ja pilvi: AWS ja Azure
Kuten yllä todettiin, yksi konttien käytön eduista on, että ne voidaan helposti ottaa käyttöön pilvessä, jossa on käytettävissä joustavia laskentaresursseja, jotta voit maksimoida sovelluksesi tehokkuuden. Kuten voit kuvitella, suuret julkiset pilvimyyjät ovat kaikki innokkaita, että voit käyttää niiden alustoja mikropalvelupohjaisten sovellusten suorittamiseen. Lisätietoja saat Amazonin, Microsoftin ja Googlen resursseista.
