Ohjelmointi

4 käyttöönottostrategiaa joustaville mikropalveluille

Sovellusten rakentaminen mikropalveluilla tarjoaa kehittäjille nopeamman ja ketterämmän kuin perinteiset arkkitehtuurit. Jokaiseen koodimuutokseen liittyy kuitenkin edelleen riskejä, mikä asettaa mahdollisten vikojen vaiheet, jos koodin laatuongelmia ei löydy ja käsitellä. Näiden riskien lieventämiseksi sovellustiimien tulisi toteuttaa moderneja, pilvipohjaisia ​​reititysstrategioita, jotka helpottavat vaarojen testaamista ja varmistavat, että sovellukset ovat todella valmiita käyttöönottoon tuotantoympäristöissä.

Seuraavat neljä käyttöönottostrategiaa käyttävät reititystekniikoita uusien palveluiden ja ominaisuuksien turvalliseen käyttöönottoon, toimintojen testaamiseen ja iteratiivisten parannusten tekemiseen, haavoittuvuuksien tunnistamiseen ja poistamiseen jne. Yhdessä nämä lähestymistavat ovat virtuaalinen työkalupakki, johon sovellusryhmät voivat pyrkiä vähentämään riskejä mikropalveluilla toimivien sovellusten kehittämisen ja käyttöönoton aikana. Heidän erojensa ja samankaltaisuuksiensa ymmärtäminen on avain tietäessä kuinka hyödyntää niitä parhaalla mahdollisella tavalla omassa ympäristössäsi.

Kanariansaarten käyttöönotto

Nimetty historiallisen käytännön mukaan lähettää todellisia lintuja hiilikaivoksiin sen selvittämiseksi, onko ilmanlaatu ihmisille turvallista, kanariansaarten käyttöönotto on tapa testata todellisia tuotantokäytäntöjä vähäisillä vaikutuksilla tai riskeillä. Niin kutsuttu kanarialintu on ehdokasversio palvelusta, joka saa osan alaryhmästä saapuvia pyyntöjä (esimerkiksi 1%) uusien ominaisuuksien tai koontiversioiden kokeilemiseksi. Joukkueet voivat sitten tutkia tuloksia, ja jos asiat sujuvat sujuvasti, lisätä asteittain palvelinten tai solmujen käyttöönottoa 100 prosenttiin. Ja jos ei? Liikenne voidaan ohjata nopeasti kanarian käyttöönotosta, kun rikkoneen koodin tarkistus ja virheenkorjaus tapahtuu.

Kanariansaarten käyttöönotto voidaan toteuttaa integroimalla reitin reitityskomponentteihin, jotka vastaavat saapuvan käyttäjäliikenteen käsittelystä. Esimerkiksi Kubernetes-ympäristössä kanarian käyttöönotto voi napauttaa sisääntulon ohjaimen kokoonpanoa määrittääksesi tietyt prosenttiosuudet liikennepyynnöistä vakaan ja kanarian käyttöönottoon. Liikenteen reitittäminen tällä tavoin varmistaa, että uusilla palveluilla on mahdollisuus todistaa itsensä ennen täyden käyttöönoton saamista. Jos he eivät tee niin, heidät lähetetään takaisin korjaamaan ongelmat ja suorittamaan sitten uusi kierros kanarian käyttöönoton testausta, kun se on valmis.

A / B-testaus

A / B-testaus on samanlainen kuin kanariansaarteissa, ja siinä on yksi tärkeä ero. Kanariansaarteissa keskitytään yleensä virheiden ja suorituskyvyn pullonkaulojen tunnistamiseen, kun taas A / B-testaus keskittyy mittaamiseen käyttäjän hyväksyntä uusia sovelluksen ominaisuuksia. Kehittäjät saattavat esimerkiksi haluta tietää, ovatko uudet ominaisuudet suosittuja käyttäjien keskuudessa, onko ne helppo löytää vai toimiiko käyttöliittymä oikein.

Tässä mallissa ohjelmistoreititys aktivoidaan ja testataan erityisiä ominaisuuksia eri liikennesegmenteillä, jolloin uudet ominaisuudet altistetaan tietylle prosenttiosuudelle liikenteestä tai rajoitetuille ryhmille. A- ja B-reitityssegmentit saattavat lähettää liikennettä ohjelmiston eri koontiversioihin, tai palvelun esiintymät saattavat jopa käyttää samaa ohjelmistokokoonpanoa, mutta eri kokoonpanoattribuuteilla (kuten orkesterissa tai muualla on määritelty).

Sinivihreä käyttöönotto

Sinivihreän käyttöönoton malliin kuuluu kahden tuotantoympäristön käyttö rinnakkain: yksi nykyistä vakaa julkaisua varten (sininen) ja toinen vaiheittaa ja suorittaa testaus seuraavalla julkaisulla (vihreä). Tämän strategian avulla päivitetyt ohjelmistoversiot voidaan julkaista helposti toistettavalla tavalla. Devops-tiimit voivat käyttää tätä tekniikkaa uuden version käyttöönoton automatisointiin CI / CD-putkilinjan avulla.

Sinivihreän strategian avulla kehittäjät ottavat käyttöön uuden palveluversion olemassa olevan ilmentymän rinnalla, joka käsittelee tällä hetkellä tuotantoliikennettä. CI / CD-putki tulisi asettaa suorittamaan automaattisia savutestejä varmistaakseen, että uusi versio onnistuu avaintoiminnoissaan. Kun uusi palvelu on läpäissyt viimeiset testit, liikenne voidaan sitten ohjata turvallisesti ja automaattisesti siihen käyttämällä ohjelmistoreititystä hallitsemaan saumattomasti liikenteen siirtymistä sinisestä vihreään. Yhtä tärkeää on, että kriittisten viime hetken ongelmien kohdalla on helppo palauttaa käyttöönotto siniseen versioon, jos kriittisiä ongelmia ilmenee.

Liikenteen varjostus

Liikenteen varjo on samanlainen kuin sinivihreä käyttöönotto, mutta sen sijaan, että käytettäisiin synteettisiä testejä "vihreän" ympäristön validoimiseksi, reititystekniikka kopioi kaiken saapuvan tuotantoliikenteen ja heijastaa sitä erilliseksi testijärjestelmäksi, joka ei ole vielä julkista. Siten liikenteen varjostus luo tarkan kuvan siitä, mitä tapahtuisi, jos uusi versio otettaisiin käyttöön, aidon liikenteen perusteella. Samalla liikenteen varjostus varmistaa, että testeillä ei ole vaikutusta todelliseen tuotantoon. Käytännössä kehittäjät voivat halutessaan kopioida tietyn prosenttiosuuden pyynnöistä testipalvelulle, jossa he voivat sitten suorittaa integrointitestauksen ja suorituskyvyn vertailun (joko manuaalisesti tai automatisoidun CI / CD-putkiston puitteissa).

Yrityskehittäjät hyödyntävät jo useita testaustekniikoita, jotka on suunniteltu varmistamaan, että uusi sovelluskoodi täyttää tietyt vaatimukset. Esimerkiksi yksikkö- ja toimintatestit ovat edelleen olennaisia ​​toimenpiteitä, jotka koodin on tyhjennettävä. Mikropalvelupohjaisten arkkitehtuurien luonteen vuoksi end-to-end-integraatiotestaus on tärkeämpää kuin koskaan. Ottaen huomioon mikropalveluarkkitehtuureille ominaisen keskinäisten riippuvuuksien määrän ja pitkäaikaisen rajapinnan siirtymisen riskin, synteettisillä testeillä on edelleen arvoa, mutta ne eivät viime kädessä näytä tarkasti kaikkia palvelujen välisiä vuorovaikutuksia tuotantoympäristöissä.

Neljä strategiaa, yksi tavoite

Nämä reititystekniikat tarjoavat kaikki erilliset, mutta toisiinsa liittyvät menetelmät apuna vikojen löytämisessä, lieventämisessä ja testauksessa mikropalveluihin perustuvissa sovelluksissa. Ne ovat tehokkaita työkaluja virheiden, suorituskykyongelmien ja tietoturva-aukkojen korjaamiseen, varsinkin kun ne otetaan käyttöön osana jatkuvaa integrointi- ja jakelujärjestelmää (CI / CD).

Mikä näistä menetelmistä sopii parhaiten omaan tapaukseesi, riippuu suurelta osin siitä, mitkä huolenaiheet ovat tärkeimmät. Esimerkiksi merkittävä käyttöliittymän uudistaminen voi hyötyä suuresti A / B-testauksesta, kun taas sinivihreä käyttöönotto voi olla korvaamaton nähdäksesi, kuinka uusi ominaisuus voi vaikuttaa olemassa olevan tietovaraston suorituskykyyn.

Usein näiden tekniikoiden yhdistelmä voi tarjota parhaan kattavuuden. On kuitenkin tärkeää miettiä, kuinka hyvin kukin integroituu olemassa olevaan kehitysmalliin. Yksittäisten ominaisuuksien käyttöönotto Kanariansaarilla saattaa soveltua paremmin ketteriin kehitysmenetelmiin kuin esimerkiksi sinivihreä täysversioiden käyttöönotto. Ja vaikka liikenteen varjostus voi antaa erinomaisen näkyvyyden sovelluksen suorituskyvyn esiasennukseen, se voi olla vaikeaa ja aikaa vievää ja kallista resurssien laskennassa.

Kuitenkin käytät niitä, tällaiset reititystekniikat voivat olla korvaamaton osa ohjelmistokehitysprosessia, varsinkin kun teollisuus siirtyy perinteisistä, monoliittisista sovelluksista kohti pilvikohtaisia ​​järjestelmiä, jotka perustuvat mikropalveluihin. Soveltamalla yhtä, joitain tai kaikkia näitä tekniikoita pitäen samalla mielessä erityiset edut, sovellusryhmät voivat paremmin varmistaa projektien eheyden ja menestyksen ja siirtyä luottavaisemmin tuotantoon.

Manuel Zapf on Containous-tuotteen OSS-johtaja, joka on avoimen lähdekoodin Traefikin ja Maeshin projektien taustalla toimiva pilvikohtainen verkko-yritys.

New Tech Forum tarjoaa mahdollisuuden tutkia ja keskustella kehittyvistä yritysteknologioista ennennäkemättömällä syvyydellä ja laajuudella. Valinta on subjektiivinen, perustuu valitsemiemme tekniikoihin, joiden uskomme olevan tärkeitä ja kiinnostavia lukijoille. ei hyväksy markkinointivakuuksia julkaisua varten ja pidättää oikeuden muokata kaikkea lähetettyä sisältöä. Lähetä kaikki tiedustelut osoitteeseen [email protected].

$config[zx-auto] not found$config[zx-overlay] not found