Yksi tietotekniikassa tapahtuvista muutoksista digitaalisen muutoksen lipun alla on suurten, monoliittisten sovellusten hajottaminen mikropalveluiksi—pienet, erilliset toiminnallisuudet - jotka toimivat kontteissa—ohjelmistopaketit, jotka sisältävät kaikki palvelun koodit ja riippuvuudet, jotka voidaan eristää ja helposti siirtää palvelimelta toiselle.
Tällaisia konttipohjaisia arkkitehtuureja on helppo laajentaa ja käyttää pilvessä, ja yksittäiset mikropalvelut voidaan nopeasti ottaa käyttöön ja toistaa. Näiden mikropalvelujen välinen viestintä muuttuu kuitenkin yhä monimutkaisemmaksi, kun sovellukset kasvavat ja useita saman palvelun esiintymiä suoritetaan samanaikaisesti. Palveluverkko on nouseva arkkitehtoninen muoto, jonka tarkoituksena on yhdistää nämä mikropalvelut dynaamisesti tavalla, joka vähentää hallinnollisia ja ohjelmointikuluja.
Mikä on palveluverkko?
Laajimmassa merkityksessä palveluverkko on, kuten Red Hat kuvaa, "tapa hallita kuinka sovelluksen eri osat jakavat tietoja keskenään". Tämä kuvaus voisi kuitenkin sisältää paljon erilaisia asioita. Itse asiassa se kuulostaa todella paljon kuin väliohjelmisto, jonka useimmat kehittäjät tuntevat asiakas-palvelinsovelluksista.
Palveluverkosta tekee ainutlaatuisen se, että se on rakennettu vastaamaan hajautettujen mikropalveluympäristöjen ainutlaatuisuutta. Mikropalveluista rakennettuun laajamittaiseen sovellukseen voi olla useita yksittäisiä palveluita, jotka kulkevat useiden paikallisten tai pilvipalvelimien yli. Kaikki nämä liikkuvat osat vaikeuttavat yksittäisten mikropalvelujen ilmeisesti muiden palveluiden löytämistä, joiden kanssa he tarvitsevat yhteydenpitoa. Palveluverkko huolehtii automaattisesti palveluiden löytämisestä ja yhdistämisestä hetkellisesti, jotta sekä ihmisen kehittäjien että yksittäisten mikropalvelujen ei tarvitse.
Ajattele palveluverkkoa vastaavana kuin ohjelmiston määrittämä verkko (SDN) OSI-verkkomallin tasolla 7. Aivan kuten SDN luo abstraktikerroksen, jotta verkonvalvojien ei tarvitse käsitellä fyysisiä verkkoyhteyksiä, palveluverkko irrottaa sovelluksen taustalla olevan infrastruktuurin abstraktista arkkitehtuurista, jonka kanssa olet vuorovaikutuksessa.
Ajatus palveluverkosta syntyi orgaanisesti, kun kehittäjät ryhtyivät kamppailemaan todella valtavien hajautettujen arkkitehtuurien ongelmien kanssa. Linkerd, ensimmäinen tämän alueen projekti, syntyi Twitterin sisäisen projektin osana. Istio, toinen suosittu palveluverkko, jolla on suuri yritystuki, on peräisin Lyftiltä. (Tarkastelemme molempia hankkeita tarkemmin hetken kuluttua.)
Huoltoverkkokuormituksen tasapainotus
Yksi palveluverkon tarjoamista tärkeimmistä ominaisuuksista on kuormituksen tasapainottaminen. Ajattelemme yleensä kuormituksen tasapainottamista verkkotoimintona - haluat estää palvelimia tai verkkolinkkejä ylikuormittamasta liikennettä, joten reitität paketit vastaavasti. Palveluverkot tekevät jotain vastaavaa sovellustasolla, kuten Twain Taylor kuvaa, ja ymmärtäminen, joka antaa sinulle hyvän käsityksen siitä, mitä tarkoitamme, kun sanomme, että palveluverkko on kuin ohjelmistokohtainen verkko sovelluskerrokselle.
Pohjimmiltaan yksi palveluverkon tehtävistä on seurata, mitkä eri mikropalvelujen esiintymät infrastruktuurille ovat "terveellisimpiä". Se saattaa kysellä heitä nähdäkseen, miten heillä on, tai seurata, mitkä esiintymät vastaavat hitaasti palvelupyyntöihin ja lähettää myöhemmät pyynnöt muille ilmentymille. Palveluverkko voi tehdä samanlaista työtä verkkoreiteillä, huomatessaan, kun viestien saapuminen kestää liian kauan määränpäähänsä, ja korvaamaan muita reittejä. Nämä hidastumiset voivat johtua taustalla olevan laitteiston ongelmista tai yksinkertaisesti palvelujen ylikuormituksesta pyynnöillä tai työskentelystä niiden käsittelykapasiteetilla. Tärkeää on, että palveluverkko voi löytää toisen saman palvelun esiintymän ja reitin sen sijaan, mikä hyödyntää tehokkaimmin koko sovelluksen kapasiteettia.
Palveluverkko vs. Kubernetes
Jos olet jonkin verran perehtynyt konttipohjaisiin arkkitehtuureihin, saatat miettiä, missä Kubernetes, suosittu avoimen lähdekoodin konttiorkesterijärjestelmä, sopii tähän kuvaan. Eikö loppujen lopuksi ole Kubernetesin koko asia, että se hallitsee, kuinka kontit kommunikoivat keskenään? Kuten Kublrin tiimi huomauttaa yritysblogissaan, voit ajatella Kubernetesin "palvelu" -resurssia hyvin perustyyppisenä palveluverkkona, koska se tarjoaa palvelujen löytämisen ja pyyntöjen tasapainottamisen. Mutta täysin varustetut palveluverkot tarjoavat paljon enemmän toiminnallisuutta, kuten tietoturvakäytäntöjen ja salauksen hallinta, "piirin rikkominen" keskeyttääkseen pyyntöjä hitaasti vastaaville instansseille, kuormituksen tasapainottaminen, kuten edellä kuvataan, ja paljon muuta.
Muista, että useimmat palveluverkot vaativat Kubernetesin kaltaisen orkestrointijärjestelmän olevan paikallaan. Huoltoverkot tarjoavat laajennetun toiminnallisuuden, eivät korvaavia.
Palveluverkko vs. API-yhdyskäytävät
Jokainen mikropalvelu tarjoaa sovelluksen ohjelmointirajapinnan (API), joka toimii keinona, jolla muut palvelut kommunikoivat sen kanssa. Tämä herättää kysymyksen eroista palveluverkon ja muiden perinteisempien API-hallintamuotojen, kuten API-yhdyskäytävien, välillä. Kuten IBM selittää, API-yhdyskäytävä seisoo mikropalveluryhmän ja "ulkomaailman" välillä reitittämällä palvelupyyntöjä tarpeen mukaan, jotta pyynnön esittäjän ei tarvitse tietää, että se käsittelee mikropalvelupohjaista sovellusta. Palveluverkko puolestaan välittää mikropalvelusovelluksen sisällä olevia pyyntöjä eri komponenttien ollessa täysin tietoisia ympäristöstään.
Toinen tapa ajatella sitä, kuten Justin Warren kirjoittaa Forbes, on, että palveluverkko on itä-länsi -liikenteelle klusterissa ja API-yhdyskäytävä on pohjoisesta etelään -liikenteelle, joka menee klusteriin ja sieltä pois. Mutta koko ajatus palveluverkosta on vielä varhaista ja vaihtelevaa. Monet palveluverkot - mukaan lukien Linkerd ja Istio - tarjoavat nyt myös pohjoisesta etelään -toiminnon.
Palveluverkkoarkkitehtuuri
Ajatus palveluverkosta on tullut esiin vasta parin viime vuoden aikana, ja "palveluverkko" -ongelman ratkaisemiseen, ts. Mikropalvelujen viestinnän hallintaan, on olemassa useita erilaisia lähestymistapoja. Andrew Jenkins Aspen Meshistä tunnistaa kolme mahdollista vaihtoehtoa siitä, missä palveluverkon luoma viestintäkerros saattaa asua:
- Jonkin sisällä kirjasto että kukin mikropalvelusi tuo
- Jonkin sisällä solmuagentti joka tarjoaa palveluja kaikille tietyn solmun säiliöille
- Jonkin sisällä sivuvaunu kontti, joka kulkee sovellussäiliön rinnalla
Sivuvaunupohjainen malli on yksi suosituimmista palveluverkkomalleista - niin paljon, että siitä on joillakin tavoin tullut synonyymi palveluverkkoille yleensä. Vaikka se ei ole tarkalleen ottaen totta, sivuvaunun lähestymistapa on saanut niin paljon pitoa, että tämä on arkkitehtuuri, jota tarkastelemme tarkemmin.
Sivuvaunut huoltoverkossa
Mitä tarkoittaa sanoa, että sivuvaunusäiliö "kulkee" sovellussäiliön rinnalla? Red Hatilla on melko hyvä selitys. Jokaisella tämän tyyppisen palveluverkon mikropalvelusäiliöllä on toinen vastaava välityspalvelinsäiliö. Kaikki palveluiden välisen viestinnän edellyttämä logiikka erotetaan mikropalvelusta ja laitetaan sivuvaunuun.
Tämä saattaa tuntua monimutkaiselta - loppujen lopuksi kaksinkertaistat sovelluksesi säiliöiden määrän! Mutta käytät myös suunnittelumallia, joka on avain hajautettujen sovellusten yksinkertaistamiseen. Laittamalla kaikki verkko- ja tietoliikennekoodit erilliseen säilöön olet tehnyt siitä osan infrastruktuuria ja vapauttanut kehittäjät sen toteuttamisesta osana sovellusta.
Pohjimmiltaan jäljellä on mikropalvelu, joka voidaan keskittää laserilla sen liiketoimintalogiikkaan. Mikropalvelun ei tarvitse osata kommunikoida kaikkien muiden palveluiden kanssa villissä ja hullussa ympäristössä, jossa ne toimivat. Sen on vain osattava kommunikoida sivuvaunun kanssa, joka huolehtii muusta.
Palveluverkot: Linkerd, Envio, Istio, konsuli
Joten mitkä palveluverkot ovat käytettävissä? No, ei ole aivan kaupan saatavia kaupallisia tuotteita. Useimmat palveluverkot ovat avoimen lähdekoodin projekteja, joiden toteuttaminen vie hienoa. Suuret nimet ovat:
- Linkerd (lausutaan "linker-dee") - Julkaistu vuonna 2016, ja siten vanhin näistä tarjouksista, Linkerd erotettiin Twitterissä kehitetystä kirjastosta. Toinen raskas lyöjä tässä tilassa, Conduit, vietiin Linkerd-projektiin ja muodostaa perustan Linkerd 2.0: lle.
- Lähettiläs - Lyftissä luotu lähettiläs on palveluverkon ”tietotaso” -osa. Täyden palvelun verkon tarjoamiseksi se on yhdistettävä "ohjaustasoon", kuten ...
- Istio - Lyftin, IBM: n ja Googlen yhteistyössä kehittämä Istio on valvontasuunnitelma välityspalvelinten, kuten Envoy, palvelemiseksi. Istio ja lähettiläs ovat oletusparit, mutta molemmat voidaan yhdistää muihin alustoihin.
- HashiCorp Consul - Yhdistetty Consul 1.2: n kanssa, ominaisuus nimeltä Connect lisäsi palvelun salauksen ja henkilöllisyyteen perustuvan valtuutuksen HashiCorpin hajautettuun järjestelmään palvelujen löytämiseksi ja määrittämiseksi muuttamalla siitä täyden palvelun verkon.
Mikä palveluverkko sopii sinulle? Vertailu ei kuulu tämän artikkelin piiriin, mutta on syytä huomata, että kaikki yllä olevat tuotteet on todistettu suurissa ja vaativissa ympäristöissä. Linkerdillä ja Istiossa on laajimmat ominaisuusjoukot, mutta kaikki kehittyvät nopeasti. Haluat ehkä tarkistaa George Mirandan erittelyn Linkerdin, lähettilään ja Istion ominaisuuksista, vaikka pidä mielessä, että hänen artikkelinsa kirjoitettiin ennen kuin Conduit ja Linkerd yhdistivät voimansa.
Muista myös, että tämä tila on uusi ja uusia kilpailijoita voi tulla esiin milloin tahansa. Esimerkiksi marraskuussa 2018 Amazon aloitti julkisen esikatselun AWS-palveluverkosta. Ottaen huomioon, kuinka monta kauppaa käyttää Amazonin julkista pilvipalvelua, AWS App Meshillä pitäisi olla suuri vaikutus.
