🥇Palveluverkkojen käyttötapaukset

Huomautus. käännös: Tämän artikkelin kirjoittaja (Luc Perkins) on kehittäjien puolestapuhuja CNCF-organisaatiossa, jossa on sellaisia avoimen lähdekoodin projekteja kuin Linkerd, SMI (Service Mesh Interface) ja Kuma (oletko muuten miettinyt, miksi Istio on ei ole tässä listassa? Hän yrittää jälleen kerran saada DevOps-yhteisön ymmärtämään paremmin trendikkäästä "palveluverkosta" kutsuttua hypeä. Hän listaa 16 ominaisuutta, joita tällaiset ratkaisut tarjoavat.

Tänään huoltoverkko ― yksi kuumimmista aiheista ohjelmistosuunnittelun alalla (ja oikeutetusti!). Mielestäni tämä tekniikka on uskomattoman lupaava ja haluaisin nähdä sen laajalti käyttöön (kun se on tietysti järkevää). Useimmille ihmisille sitä kuitenkin ympäröi mysteerin aura. Samaan aikaan jopa ne, jotka hyvin tunnettu sen kanssa on usein vaikea muotoilla sen etuja ja mitä se tarkalleen on (mukaan lukien sinun todella). Tässä artikkelissa yritän korjata tilanteen luettelemalla erilaisia Käytä koteloita "palveluverkot"*.

* Huomautus käännös: tässä ja edelleen artikkelissa juuri tätä käännöstä ("palveluverkko") käytetään vielä uudella termillä palveluverkko.

Mutta ensin haluan tehdä muutaman huomautuksen:

En ole koskaan työskennellyt palveluverkkojen kanssa tai käyttänyt niitä oman koulutukseni aloitettujen projektien ulkopuolella. Toisaalta minä olin se, joka kirjoitti joukon dokumentteja Twitterin sisäiseen palveluverkkoon vuonna 2015 (sitä ei silloin edes kutsuttu "palveluverkoksi") ja osallistuin verkkosivuston ja dokumentaation kehittämiseen. Linkerd, joten se tarkoittaa jotain.
Listani on likimääräinen ja epätäydellinen. Minulle tuntemattomat käyttötapaukset ovat täysin mahdollisia, ja uusia vaihtoehtoja tulee todennäköisesti esiin ajan myötä tekniikan kehittyessä ja sen suosion kasvaessa.
Samanaikaisesti kaikki olemassa olevat palveluverkkototeutukset eivät tue kaikkia lueteltuja käyttötapauksia. Siksi väittämäni, kuten "service mesh can..." tulisi lukea "yksittäisiksi, ja ehkä kaikki suositut palveluverkkototeutukset voivat...".
Esimerkkien järjestyksellä ei ole mitään eroa.

Lyhyt lista:

palvelun löytäminen;
salaus;
todennus ja valtuutus;
kuormituksen tasapainoittaminen;
virtapiirin katkaisu;
automaattinen skaalaus;
kanariansaarten käyttöönotot;
sinivihreä käyttöönottoa;
terveystarkastus;
kuorman pudottaminen;
liikenteen peilaus;
eristys;
pyyntönopeuden rajoittaminen, uudelleenyritykset ja aikakatkaisut;
telemetria;
tarkastaa;
visualisointi.

1. Palvelun etsintä

TL;DR: Yhdistä muihin verkon palveluihin yksinkertaisilla nimillä.

Palveluiden tulee pystyä automaattisesti "löytämään" toisensa sopivilla nimillä - esim. service.api.production, pets/staging tai cassandra. Pilviympäristöt ovat joustavia, ja yksi nimi voi piilottaa useita palvelun esiintymiä. On selvää, että tällaisessa tilanteessa on fyysisesti mahdotonta koodata kaikkia IP-osoitteita.

Lisäksi, kun yksi palvelu löytää toisen, sen pitäisi pystyä lähettämään pyyntöjä kyseiselle palvelulle ilman pelkoa, että ne päätyvät sen rikkinäisen esiintymän syötteeseen. Toisin sanoen palveluverkon on valvottava kaikkien palveluinstanssien kuntoa ja pidettävä isäntien luettelo mahdollisimman ajan tasalla.

Jokainen palveluverkko toteuttaa palvelunhakumekanismin eri tavalla. Tällä hetkellä yleisin tapa on delegoida ulkoisille prosesseille, kuten DNS Kubernetes. Aiemmin Twitterissä käytimme tähän tarkoitukseen nimeämisjärjestelmää Finagle. Lisäksi palveluverkkoteknologia mahdollistaa mukautettujen nimeämismekanismien syntymisen (vaikka en ole vielä nähnyt yhtään SM-toteutusta sellaisella toiminnallisuudella).

2. Salaus

TL;DR: Päästä eroon palvelujen välisestä salaamattomasta liikenteestä ja tee tästä prosessista automatisoitu ja skaalautuva.

On mukavaa tietää, etteivät hyökkääjät pääse sisäverkkoosi. Palomuurit tekevät tässä loistavaa työtä. Mutta mitä tapahtuu, jos hakkeri pääsee sisään? Pystyykö hän tekemään palvelun sisäisellä liikenteellä mitä haluaa? Toivotaan, että näin ei lopulta tapahdu. Tämän skenaarion estämiseksi sinun tulee ottaa käyttöön nollaluottamusverkko, jossa kaikki palveluiden välinen liikenne on salattu. Useimmat nykyaikaiset palveluverkot saavuttavat tämän keskinäisen kautta TLS (keskinäinen TLS, mTLS). Joissakin tapauksissa mTLS toimii kokonaisissa pilvissä ja klustereissa (luulen, että planeettojen välinen viestintä järjestetään joskus samalla tavalla).

Tietenkin mTLS-palveluverkolle valinnainen. Jokainen palvelu voi huolehtia omasta TLS:stään, mutta tämä tarkoittaa, että sinun on löydettävä tapa luoda varmenteita, jakaa ne palveluisäntien kesken ja sisällytettävä koodi sovellukseen, joka lataa nämä varmenteet tiedostoista. Ja älä unohda uusia näitä varmenteita säännöllisin väliajoin. Palveluverkot automatisoivat mTLS:n sellaisilla järjestelmillä kuin SPIFFE, jotka puolestaan automatisoivat varmenteiden myöntämis- ja kiertoprosessin.

3. Todennus ja valtuutus

TL;DR: Selvitä, kuka pyynnön esittäjä on ja mitä he saavat tehdä ennen kuin pyyntö edes saapuu palveluun.

Palvelut haluavat usein tietää joka suorittaa pyynnön (todennus) ja päättää näiden tietojen perusteella että tietyllä taholla on lupa tehdä (valtuutus). Tässä tapauksessa pronomini "kuka" voi piilottaa:

Muut palvelut. Tätä kutsutaan "todennus" tähyillä" Esimerkiksi palvelu web haluaa käyttää palvelua db. Palveluverkot ratkaisevat tällaiset ongelmat yleensä mTLS:n avulla: varmenteet toimivat tässä tapauksessa välttämättömänä tunnisteena.
Jotkut ihmiskäyttäjät. Tätä kutsutaan "todennus" tiedustelu" Esimerkiksi käyttäjä haxor69 haluaa ostaa uuden lampun. Palveluverkot tarjoavat erilaisia mekanismeja, mm. JSON-verkkotunnukset.
Monet meistä ovat tehneet tämän sovelluskoodissa. Pyyntö saapuu, katsomme pöydän läpi users, etsi käyttäjä ja vertaa salasanaa ja tarkista sitten sarake permissions jne. Palveluverkon tapauksessa tämä tapahtuu ennen kuin pyyntö edes saapuu palveluun.

Kun olemme selvittäneet, keneltä pyyntö tuli, meidän on määritettävä, mitä tämä taho saa tehdä. Joidenkin palveluverkkojen avulla voit asettaa peruskäytännöt (kuka voi tehdä mitä) YAML-tiedostoina tai komentorivillä, kun taas toiset tarjoavat integroinnin puitteisiin, kuten Open Policy Agent. Lopullisena tavoitteena on, että palvelusi hyväksyvät kaikki pyynnöt turvallisesti olettaen, että ne tulevat luotettavasta lähteestä и tämä toimenpide on sallittu.

4. Kuormituksen tasaus

TL;DR: Jaa kuorma palveluinstanssien kesken tietyn mallin mukaan.

Palveluosion "Palvelu" koostuu hyvin usein useista identtisistä tapauksista. Esimerkiksi tänään palvelu cache koostuu 5 kappaleesta, ja huomenna niiden määrä voi nousta 11:een. Pyynnöt lähetetään osoitteeseen cache, on jaettava tietyn tarkoituksen mukaisesti. Esimerkiksi viiveen minimoimiseksi tai toimivan ilmentymän saavuttamisen todennäköisyyden maksimoimiseksi. Yleisimmin käytetty algoritmi on Round-robin, mutta on monia muitakin - esimerkiksi painotettu menetelmä. (painotettu) kyselyt (voit valita ensisijaiset kohteet), soita (rengas) hajautus (käytetään johdonmukaista tiivistystä ylävirran isäntien välillä) tai vähiten pyyntö -menetelmä (etusija annetaan ilmentymälle, jolla on vähiten pyyntöjä).

Klassisissa tasapainottimissa on muita toimintoja, kuten HTTP-välimuisti ja DDoS-suojaus, mutta ne eivät ole kovin tärkeitä itä-länsi-liikenteelle (eli datakeskuksen sisällä kulkevalle liikenteelle - noin käännös) (tyypillinen palveluverkko). Palveluverkkoa ei tietenkään tarvitse käyttää kuormituksen tasapainottamiseen, mutta sen avulla voit määrittää ja hallita tasapainotuskäytäntöjä jokaiselle palvelulle keskitetystä ohjauskerroksesta, jolloin ei tarvitse suorittaa ja määrittää erillisiä kuormituksen tasaajia verkkopinossa. .

5. Virtapiirin katkaisu

TL;DR: Pysäytä liikenne ongelmalliseen palveluun ja hallitse vahinkoa pahimmassa tapauksessa.

Jos palvelu jostain syystä ei kestä liikennettä, palveluverkko tarjoaa useita vaihtoehtoja tämän ongelman ratkaisemiseksi (muita käsitellään asianmukaisissa kohdissa). Virran katkeaminen on vakavin vaihtoehto palvelun katkaisemiseksi liikenteestä. Se ei kuitenkaan sinänsä ole järkevää - tarvitaan varasuunnitelma. Vastapainetta voidaan tarjota (vastapaine) palveluihin, jotka tekevät pyyntöjä (älä vain unohda määrittää palveluverkkoasi tätä varten!), tai esimerkiksi värjätä tilasivu punaiseksi ja ohjaa käyttäjät sivun toiseen versioon "putoavalla valaalla" ("Twitter on" alas").

Palveluverkot eivät vain salli sinun määrittää missä sammutus seuraa ja että tämä seuraa. Tässä tapauksessa "kun" voi sisältää minkä tahansa määritettyjen parametrien yhdistelmän: pyyntöjen kokonaismäärä tietyltä ajanjaksolta, rinnakkaisten yhteyksien lukumäärä, odottavat pyynnöt, aktiiviset uudelleenyritykset jne.

Et luultavasti halua väärinkäyttää virrankatkaisua, mutta on mukava tietää, että sinulla on varasuunnitelma hätätilanteita varten.

6. Automaattinen skaalaus

TL;DR: Lisää tai vähennä palveluinstanssien määrää määritettyjen ehtojen mukaan.

Palveluverkot eivät ole ajoittajia, joten ne eivät sitä tee suorittaa skaalata itseäsi. He voivat kuitenkin antaa tietoa siitä, mitkä suunnittelijat tekevät päätöksensä. Koska palveluverkoilla on pääsy kaikkeen palveluiden väliseen liikenteeseen, niillä on laaja tieto siitä, mitä tapahtuu: missä palveluissa on ongelmia, mitkä palvelut ovat erittäin kevyesti kuormitettuja (niille varattu kapasiteetti hukkaan) jne.

Esimerkiksi Kubernetes skaalaa palvelut podsien suorittimen ja muistin käytön perusteella (katso raporttimme "Automaattinen skaalaus ja resurssien hallinta Kubernetesissa"- n. käännös.), mutta jos päätät skaalata minkä tahansa muun mittarin (tässä tapauksessa liikenteeseen liittyvän) perusteella, tarvitset erityisen mittarin. Hallinto kuten tämä näyttää kuinka tämä tehdään Lähettiläs, Sama и Prometheus, mutta itse prosessi on melko monimutkainen. Haluaisimme palveluverkon yksinkertaistavan tätä sallimalla meidän yksinkertaisesti asettaa ehtoja, kuten "lisää palveluesiintymien määrää auth, jos odottavien pyyntöjen määrä ylittää kynnyksen minuutin sisällä."

7. Kanarian sijoitukset

TL;DR: Testaa uusia ominaisuuksia tai palveluversioita osalla käyttäjiä.

Oletetaan, että kehität tiettyä SaaS-tuotetta ja aiot julkaista siitä hienon uuden version. Testasit sitä lavastuksessa ja se toimi hienosti. Mutta hänen käytöksensä todellisissa olosuhteissa herättää edelleen tiettyjä huolenaiheita. Toisin sanoen sinun on testattava uutta versiota todellisissa ongelmissa vaarantamatta käyttäjien luottamusta. Kanarian sijoitukset ovat hyviä tähän. Niiden avulla voit esitellä uutta ominaisuutta osalle käyttäjiä. Tämä alajoukko voi koostua uskollisimmista käyttäjistä tai niistä, jotka työskentelevät tuotteen ilmaisen version kanssa, tai käyttäjistä, jotka ovat ilmaisseet halunsa olla "marsuja".

Palveluverkot toteuttavat tämän sallimalla sinun määrittää kriteerit, jotka määrittävät, kuka näkee minkä tahansa sovelluksen version ja reitittää liikenteen sen mukaisesti. Mikään ei kuitenkaan muutu itse palveluille. Palvelun versio 1.0 uskoo, että kaikki pyynnöt tulevat käyttäjiltä, joiden pitäisi nähdä se, ja versio 1.1 uskoo saman käyttäjilleen. Sillä välin voit muuttaa liikenteen prosenttiosuutta vanhojen ja uusien versioiden välillä ohjaamalla yhä useampia käyttäjiä uuteen, jos se toimii vakaasti ja "koeposit" antavat valoa.

8. Sinivihreät sijoitukset

TL;DR: Ota käyttöön hieno uusi ominaisuus, mutta ole valmis ottamaan kaikki takaisin välittömästi.

Merkitys sinivihreät sijoitukset on ottaa käyttöön uusi "sininen" palvelu, joka lanseerataan rinnakkain vanhan "vihreän" kanssa. Jos kaikki sujuu hyvin ja uusi palvelu toimii hyvin, vanha voidaan asteittain poistaa käytöstä. (Voi, jonain päivänä tämä uusi "sininen" palvelu toistaa "vihreän" kohtalon ja katoaa...) Sinivihreät käyttöönotot eroavat kanarialaisista siinä, että uusi toiminto kattaa kaikki kerralla käyttäjät (ei osa); Tarkoitus tässä on olla "turvasatama" valmiina siltä varalta, että jokin menee pieleen.

Palveluverkot tarjoavat erittäin kätevän tavan testata "sinistä" palvelua ja vaihtaa välittömästi toimivaan "vihreään" ongelmatilanteissa. Puhumattakaan siitä, että matkan varrella he tarjoavat paljon tietoa (katso "Telemetria" alla) "sinisen" työstä, mikä auttaa ymmärtämään, onko se valmis täysimääräiseen käyttöön.

Huomautus. käännös: Voit lukea lisää erilaisista Kubernetesin käyttöönottostrategioista (mukaan lukien mainitut kanarialinssit, sininen/vihreä ja muut) tässä artikkelissa.

9. Terveystarkastus

TL;DR: Seuraa, mitkä palveluinstanssit ovat toimivia, ja vastaa niihin, jotka eivät enää toimi.

Terveystarkastus (terveystarkastus) auttaa päättämään, ovatko palveluinstanssit valmiita vastaanottamaan ja käsittelemään liikennettä. Esimerkiksi HTTP-palvelujen tapauksessa kuntotarkastus saattaa näyttää GET-pyynnöltä päätepisteelle /health. Vastaus 200 OK tarkoittaa, että ilmentymä on terve, mikä tahansa muu - että se ei ole valmis vastaanottamaan liikennettä. Huoltoverkkojen avulla voit määrittää sekä tavan, jolla toimivuus tarkistetaan, että tarkastustiheyden. Näitä tietoja voidaan sitten käyttää muihin tarkoituksiin - esimerkiksi kuormituksen tasapainottamiseen ja katkaisemiseen.

Terveystarkastus ei siis ole erillinen käyttötapaus, vaan sitä käytetään yleensä muiden tavoitteiden saavuttamiseen. Terveystarkastusten tuloksista riippuen voidaan myös vaatia muiden palveluverkkokohteiden ulkopuolisia toimia: esimerkiksi tilasivun päivittämistä, ongelman luomista GitHubissa tai JIRA-lipun täyttämistä. Ja palveluverkko tarjoaa kätevän mekanismin automatisoida kaikki tämä.

10. Kuormanpoisto

TL;DR: Ohjaa liikenne uudelleen tilapäisen käyttöpiikin vuoksi.

Jos jokin palvelu on ylikuormitettu liikenteellä, voit tilapäisesti ohjata osan liikenteestä toiseen paikkaan (eli "dumppaa", "siirrä" (vaja) hän siellä). Esimerkiksi varmuuskopiointipalveluun tai datakeskukseen tai pysyvään lehdistö aihe. Tämän seurauksena palvelu jatkaa joidenkin pyyntöjen käsittelyä sen sijaan, että kaatuisi ja lopettaisi kaiken käsittelyn. Kuorman irtoaminen on parempi kuin piirin katkaisu, mutta sitä ei silti kannata käyttää väärin. Se auttaa estämään peräkkäisiä vikoja, jotka aiheuttavat loppupään palvelujen kaatumisen.

11. Liikenteen rinnastaminen/peilaus

TL;DR: Lähetä yksi pyyntö useaan paikkaan kerralla.

Joskus on tarpeen lähettää pyyntö (tai tietty valikoima pyyntöjä) useille palveluille kerralla. Tyypillinen esimerkki on osan tuotantoliikenteestä lähettäminen välityspalveluun. Päätuotannon web-palvelin lähettää pyynnön loppupään palveluun products.production ja vain hänelle. Ja palveluverkko kopioi tämän pyynnön älykkäästi ja lähettää sen vastaanottajalle products.staging, josta verkkopalvelin ei ole edes tietoinen.

Toinen asiaan liittyvä palveluverkon käyttötapaus, joka voidaan toteuttaa liikenteen rinnakkaisuuden päälle, on regressiotestaus. Se sisältää samojen pyyntöjen lähettämisen palvelun eri versioille ja sen tarkistamisen, toimivatko kaikki versiot samalla tavalla. En ole vielä törmännyt palveluverkkototeutukseen, jossa on integroitu regressiotestausjärjestelmä, kuten Diffy, mutta idea itsessään vaikuttaa lupaavalta.

12. Eristys

TL;DR: Jaa palveluverkkosi miniverkkoihin.

Tunnetaan myös segmentointiEristäminen on taitoa jakaa palveluverkko loogisesti erillisiin segmentteihin, jotka eivät tiedä mitään toisistaan. Eristäminen on vähän kuin virtuaalisten yksityisten verkkojen luomista. Olennainen ero on, että voit silti nauttia kaikista palveluverkon eduista (kuten palvelun löytämisestä), mutta lisäturvalla. Jos hyökkääjä esimerkiksi onnistuu tunkeutumaan palveluun yhdessä aliverkossa, hän ei voi nähdä, mitä palveluita on käynnissä muissa aliverkoissa tai siepata niiden liikennettä.

Lisäksi edut voivat olla myös organisatorisia. Haluat ehkä aliverkkottaa palvelusi yrityksesi rakenteen perusteella ja vapauttaa kehittäjät kognitiivisesta kuormituksesta, joka aiheutuu koko palveluverkon pitämisestä mielessä.

13. Pyydä nopeuden rajoitusta, uudelleenyrityksiä ja aikakatkaisuja

TL;DR: Sinun ei enää tarvitse sisällyttää älykkäitä pyyntöjen hallintatehtäviä koodikantaasi.

Kaikki nämä asiat voitaisiin pitää erillisinä käyttötapauksina, mutta päätin yhdistää ne yhden yhteisen piirteen vuoksi: ne ottavat haltuunsa sovelluskirjastojen tyypillisesti hoitamat pyyntöjen elinkaaren hallintatehtävät. Jos olet kehittämässä verkkopalvelinta Ruby on Railsissa (ei integroitu palveluverkkoon), joka tekee pyyntöjä taustapalveluille gRPC, sovelluksen on päätettävä, mitä tehdä, jos N pyyntöä epäonnistuu. Sinun on myös selvitettävä, kuinka paljon liikennettä nämä palvelut pystyvät käsittelemään ja koodaamaan nämä parametrit käyttämällä erityistä kirjastoa. Lisäksi sovelluksen on päätettävä, milloin on aika luovuttaa ja antaa pyynnön umpeutua (aikakatkaisun perusteella). Ja jotta voidaan muuttaa jotakin yllä olevista parametreista, verkkopalvelin on pysäytettävä, määritettävä uudelleen ja käynnistettävä uudelleen.

Näiden tehtävien purkaminen palveluverkkoon tarkoittaa paitsi sitä, että palvelukehittäjien ei tarvitse ajatella niitä, vaan myös sitä, että niitä voidaan tarkastella globaalimmin. Jos käytetään monimutkaista palveluketjua, sanotaan A -> B -> C -> D -> E, pyynnön koko elinkaari on otettava huomioon. Jos tehtävänä on pidentää palvelun C aikakatkaisuja, on loogista tehdä tämä kerralla, ei osissa: päivittämällä palvelukoodi ja odottamalla, kunnes vetopyyntö hyväksytään ja CI-järjestelmä ottaa päivitetyn palvelun käyttöön.

14. Telemetria

TL;DR: Kerää kaikki tarvittavat (eikä aivan) tiedot palveluista.

Telemetria on yleinen termi, joka sisältää mittareita, hajautetun jäljityksen ja lokit. Palveluverkot tarjoavat mekanismeja kaikkien kolmentyyppisten tietojen keräämiseen ja käsittelyyn. Tässä asiat hämärtyvät, koska mahdollisten vaihtoehtojen määrä on liian suuri. Mittareiden kerääminen on olemassa Prometheus ja muita työkaluja, joita voidaan käyttää lokien keräämiseen sujuvasti, Loki, vektori jne. (esimerkiksi ClickHouse meidän kanssamme hirsimökki K8:lle - n. käännös.), hajautettua jäljitystä varten on olemassa Jääkäri ja niin edelleen. Jokainen huoltoverkko voi tukea joitain työkaluja mutta ei muita. On mielenkiintoista nähdä, onnistuuko projekti Avaa Telemetria tarjota jonkin verran lähentymistä.

Palveluverkkoteknologian etuna tässä tapauksessa on, että sivuvaunukontit voivat periaatteessa kerätä kaikki yllä mainitut tiedot palveluistaan. Toisin sanoen käytössäsi on yksi telemetrian keruujärjestelmä, ja palveluverkko pystyy käsittelemään kaiken tämän tiedon eri tavoin. Esimerkiksi:

tail lokit tietystä palvelusta CLI:ssä;
valvoa palveluverkkojen kojelaudan pyyntöjen määrää;
kerää hajautettuja jälkiä ja välitä ne Jaegerin kaltaiseen järjestelmään.

Huomio, subjektiivinen arviointi: Yleisesti ottaen telemetria on alue, jolla palveluverkon voimakkaat häiriöt eivät ole toivottavia. Perustietojen kerääminen ja joidenkin kultaisten mittareiden, kuten pyyntöjen onnistumisasteiden ja viiveiden, lennonaikainen seuranta on hienoa, mutta toivotaan, että emme näe Frankenstein-pinoja, jotka yrittävät korvata erikoisjärjestelmiä, joista osa on jo osoittautunut ja hyvin tutkittu. .

15. Tarkastus

TL;DR: Ne, jotka unohtavat historian oppitunnit, ovat tuomittuja toistamaan ne.

Auditointi on taidetta tarkkailla tärkeitä tapahtumia järjestelmässä. Palveluverkon tapauksessa tämä voi tarkoittaa seurantaa, kuka teki pyyntöjä tiettyihin päätepisteisiin tiettyjä palveluja varten tai kuinka monta kertaa jokin tietoturvaan liittyvä tapahtuma tapahtui viimeisen kuukauden aikana.

On selvää, että auditointi liittyy hyvin läheisesti telemetriaan. Erona on se, että telemetria yhdistetään yleensä sellaisiin asioihin kuin tuottavuus ja tekninen eheys, kun taas auditointi voi liittyä juridisiin ja muihin ongelmiin, jotka ylittävät puhtaasti teknisen alueen (esimerkiksi GDPR:n – EU:n yleisen tietosuoja-asetuksen) noudattaminen.

16. Visualisointi

TL;DR: Eläköön React.js – ehtymätön hienojen käyttöliittymien lähde.

Voi olla parempi termi, mutta en tiedä sitä. Tarkoitan yksinkertaisesti palveluverkon tai sen osien graafista esitystä. Nämä visualisoinnit voivat sisältää indikaattoreita, kuten keskimääräisiä viiveitä, sivuvaunun kokoonpanotietoja, terveystarkastustuloksia ja hälytyksiä.

Palvelukeskeisessä ympäristössä työskentelemiseen liittyy paljon korkeampi kognitiivinen kuormitus verrattuna Monoliittiin. Siksi kognitiivista painetta tulisi vähentää hinnalla millä hyvänsä. Yksinkertainen graafinen käyttöliittymä palveluverkolle, jossa on mahdollisuus napsauttaa nappia ja saada haluttu tulos, voisi olla ratkaiseva tämän tekniikan suosion kasvulle.

Ei sisältynyt luetteloon

Tarkoitukseni oli alun perin sisällyttää luetteloon vielä muutamia käyttötapauksia, mutta päätin sitten olla tekemättä. Tässä ne ja syyt päätökseeni:

Multi-tietokeskus. Mielestäni tämä ei ole niinkään käyttötapaus kuin kapea ja spesifinen palveluverkkojen tai joidenkin toimintojen, kuten palvelun löytämisen, sovellusalue.
Sisääntulo ja ulostulo. Tämä liittyy asiaan, mutta olen rajoittunut (ehkä keinotekoisesti) "itä-länsi-liikenteen" käyttötapaukseen. Sisääntulo ja ulostulo ansaitsevat erillisen artikkelin.

Johtopäätös

Tässä kaikki tältä erää! Jälleen tämä luettelo on hyvin mielivaltainen ja todennäköisesti epätäydellinen. Jos sinusta tuntuu, että minulta on jäänyt jotain paitsi tai mennyt pieleen, ota minuun yhteyttä Twitterissä (@luckerkins). Ole hyvä ja kunnioita säädyllisyyden sääntöjä.

PS kääntäjältä

Artikkelin otsikkokuvitus perustuu kuvaan artikkelista "Mikä on Service Mesh (ja milloin sitä käytetään)?"( kirjoittanut Gregory MacKinnon). Se näyttää, kuinka jotkin sovellusten toiminnot (vihreällä) ovat siirtyneet palveluverkkoon, joka tarjoaa yhteyksiä niiden välillä (sinisellä).

Lue myös blogistamme:

Lähde: will.com