Service mesh gebrûk senario's

Noat. transl.: De skriuwer fan dit artikel (Luc Perkins) is in advokaat foar ûntwikkelders by de CNCF-organisaasje, dy't thús is foar sokke Open Source-projekten lykas Linkerd, SMI (Service Mesh Interface) en Kuma (hasto trouwens ek ôffrege wêrom't Istio is net op dizze list? .). Nochris besykje de DevOps-mienskip in better begryp te bringen fan 'e trendy hype neamd "service mesh", hy listet 16 karakteristike mooglikheden dy't sokke oplossingen leverje.

hjoed tsjinst mesh ― ien fan de waarmste ûnderwerpen op it mêd fan software engineering (en mei rjocht!). Ik tink dat dizze technology ongelooflijk belofte is en soe it graach sjen wolle dat it breed oannommen is (as it fansels sin makket). It wurdt lykwols noch altyd omjûn troch in aura fan mystearje foar de measte minsken. Tagelyk, sels dyjingen dy't goed bekend mei it, it is faak lestich te articulate syn foardielen en wat it krekt is (ynklusyf dyn wier). Yn dit artikel sil ik besykje de situaasje te korrigearjen troch ferskate te listjen gebrûk gefallen "tsjinstmeshes"*.

* Opmerking oers.: hjir en fierder yn it artikel sil krekt dizze oersetting ("tsjinstmesh") brûkt wurde foar de noch nije term tsjinstmesh.

Mar earst wol ik in pear opmerkingen meitsje:

• Ik haw noait wurke mei tsjinstmeshes of brûkt se bûten projekten dy't begon binne foar myn eigen oplieding. Oan 'e oare kant wie ik dejinge dy't yn 2015 in protte dokumintaasje skreau foar it ynterne tsjinstmesh fan Twitter (it waard doe noch net iens in "servicemesh" neamd) en meidie oan 'e ûntwikkeling fan 'e webside en dokumintaasje foar Linkerd, dus dat betsjut wat.
• Myn list is sawat en net kompleet. D'r kinne my goed gebrûksgefallen wêze dy't my ûnbekend binne, en nije opsjes sille nei alle gedachten ûntsteane yn 'e rin fan' e tiid as de technology ûntwikkelet en syn populariteit groeit.
• Tagelyk stipet net elke besteande tsjinstmesh-ymplemintaasje alle neamde gebrûksgefallen. Dêrom moatte myn útspraken lykas "tsjinstmesh kin ..." wurde lêzen as "yndividueel, en miskien kinne alle populêre tsjinstmesh-ymplementaasjes ...".
• De folchoarder fan de foarbylden makket gjin ferskil.

Koarte list:

• ûntdekking fan tsjinsten;
• fersifering;
• autentikaasje en autorisaasje;
• load balancing;
• circuit breaking;
• autoscaling;
• kanaryske ynset;
• blau-grien ynset;
• sûnens Tsjek;
• load shedding;
• ferkearsspegeljen;
• isolaasje;
• fersyk taryf beheining, opnij besykjen en timeouts;
• telemetry;
• audit;
• fisualisaasje.

1. Service ûntdekking

TL;DR: Ferbine mei oare tsjinsten op it netwurk mei ienfâldige nammen.

Tsjinsten moatte elkoar automatysk kinne "fine" mei adekwate nammen - bygelyks, service.api.production, pets/staging of cassandra. Wolkenomjouwings binne elastysk, en ien namme kin in protte eksimplaren fan in tsjinst ferbergje. It is dúdlik dat it yn sa'n situaasje fysyk ûnmooglik is om alle IP-adressen hardcode te meitsjen.

Plus, as de iene tsjinst in oare fynt, soe it oanfragen nei dy tsjinst moatte kinne stjoere sûnder eangst dat se sille einigje by de ynfier fan har brutsen eksimplaar. Mei oare wurden, it tsjinstmesh moat de sûnens fan alle tsjinstynstânsjes kontrolearje en de list mei hosts sa aktueel mooglik hâlde.

Elk tsjinstmesh ymplementearret it tsjinstûntdekkingmeganisme oars. Op it stuit is de meast foarkommende manier om te delegearjen nei eksterne prosessen lykas DNS Kubernetes. Yn it ferline brûkten wy op Twitter in nammesysteem foar dit doel Finagle. Dêrneist service mesh technology makket it mooglik foar oanpaste nammejouwing meganismen in emerge (hoewol't ik haw noch net sjoen gjin SM ymplemintaasje mei sokke funksjonaliteit).

2. Fersifering

TL;DR: Ferwiderje fan ûnfersifere ferkear tusken tsjinsten en meitsje dit proses automatisearre en skalberber.

It is moai om te witten dat oanfallers jo ynterne netwurk net kinne penetrearje. Firewalls dogge dit geweldich wurk. Mar wat bart der as in hacker binnenkomt? Sil hy kinne dwaan wat er wol mei intra-tsjinst ferkear? Litte wy hoopje dat dit ommers net bart. Om dit senario te foarkommen, moatte jo in nul-trustnetwurk ymplementearje wêryn alle ferkear tusken tsjinsten fersifere is. De measte moderne tsjinstmeshes berikke dit troch wjerskanten TLS (ûnderlinge TLS, mTLS). Yn guon gefallen wurket mTLS yn hiele wolken en klusters (ik tink dat ynterplanetêre kommunikaasje ienris op deselde manier sil wurde regele).

Fansels, foar mTLS tsjinst mesh fakultatyf. Elke tsjinst kin har eigen TLS fersoargje, mar dit betsjut dat jo in manier moatte fine om sertifikaten te generearjen, se te fersprieden oer tsjinsthosters, en koade opnimme yn 'e applikaasje dy't dizze sertifikaten sil laden fan bestannen. Ja, ferjit net om dizze sertifikaten mei reguliere yntervallen te fernijen. Tsjinstmeshes automatisearje mTLS mei systemen lykas SPIFFE, dy't op syn beurt it proses fan it útjaan en rotearjen fan sertifikaten automatisearje.

3. Ferifikaasje en autorisaasje

TL;DR: Fêststelle wa't de oanfreger is en definiearje wat se meie dwaan foardat it fersyk sels de tsjinst berikt.

Tsjinsten wolle faaks witte wa fiert it fersyk (autentikaasje), en mei help fan dizze ynformaasje, beslút dat in opjûne entiteit is tastien te dwaan (autorisaasje). Yn dit gefal kin it foarnamwurd "wa" ferbergje:

1. Oare tsjinsten. Dit wurdt "ferifikaasje" neamd peer" Bygelyks, tsjinst web wol tagong krije ta de tsjinst db. Service meshes meastal oplosse sokke problemen mei help fan mTLS: sertifikaten yn dit gefal fungearje as de nedige identifier.
2. Guon minsklike brûkers. Dit wurdt "ferifikaasje" neamd fersyk" Bygelyks, brûker haxor69 wol in nije lamp keapje. Service meshes jouwe ferskate meganismen, f.eks. JSON Webtoken.

   In protte fan ús hawwe dit dien yn applikaasjekoade. Der komt in fersyk binnen, wy sjogge troch de tafel users, fyn de brûker en fergelykje it wachtwurd, kontrolearje dan de kolom permissions ensfh. Yn it gefal fan in tsjinstmesh bart dit foardat it fersyk sels de tsjinst berikt.

Sadree't wy hawwe fêststeld wa't it fersyk kaam út, wy moatte bepale wat dizze entiteit is tastien te dwaan. Guon tsjinstmeshes kinne jo basisbelied ynstelle (oer wa kin wat dwaan) as YAML-bestannen of op 'e kommandorigel, wylst oaren yntegraasje biede mei kaders lykas Iepenje Policy Agent. It úteinlike doel is dat jo tsjinsten elk fersyk akseptearje, feilich oannommen dat it komt fan in fertroude boarne и dizze aksje is tastien.

4. Load balancing

TL;DR: Fersprieden de lading oer tsjinstynstânsjes neffens in spesifyk patroan.

In "tsjinst" binnen in tsjinst seksje bestiet faak út in protte identike eksimplaren. Bygelyks, hjoed de tsjinst cache bestiet út 5 eksimplaren, en moarn harren oantal kin tanimme nei 11. Fersiken stjoerd nei cache, moat wurde ferdield yn oerienstimming mei in spesifyk doel. Minimalisearje bygelyks latency of maksimalisearje de kâns om nei in wurkjend eksimplaar te kommen. It meast brûkte algoritme is Round-Robin, mar d'r binne in protte oaren - bygelyks de gewichtmetoade (gewogen) queries (jo kinne foarkar doelen selektearje), ring (ring) hashing (gebrûk fan konsekwint hashing oer streamop-hosts) of metoade foar minste fersyk (foarkar wurdt jûn oan it eksimplaar mei de minste oanfragen).

Klassike balancers hawwe oare funksjes, lykas HTTP-caching en DDoS-beskerming, mar se binne net heul relevant foar east-west-ferkear (dat is, foar ferkear dat binnen in datasintrum streamt - sawat transl.) (typysk berik fan tsjinstmesh). Fansels is it net nedich om in tsjinstmesh te brûken foar loadbalancing, mar it makket it mooglik om balânsbelied foar elke tsjinst yn te stellen en te kontrolearjen fanút in sintralisearre kontrôlelaach, wêrtroch't de needsaak is om aparte loadbalancers út te fieren en te konfigurearjen yn 'e netwurkstapel .

5. Circuit breaking

TL;DR: Stopje ferkear nei de problematyske tsjinst en kontrolearje de skea yn minste gefal senario's.

As de tsjinst om ien of oare reden it ferkear net kin omgean, biedt de tsjinstmesh ferskate opsjes foar it oplossen fan dit probleem (oaren sille wurde besprutsen yn 'e passende seksjes). Circuit breaking is de meast earnstige opsje foar it loskoppelen fan in tsjinst fan ferkear. Op himsels makket it lykwols gjin sin - in reservekopyplan is nedich. Weromdruk kin foarsjoen wurde (tsjindruk) oan tsjinsten dy't oanfragen meitsje (ferjit gewoan net jo tsjinstmesh hjirfoar te konfigurearjen!), of bygelyks de statusside read kleurje en brûkers trochferwize nei in oare ferzje fan 'e side mei in "fallende walfisk" ("Twitter is omleech").

Tsjinstmeshes kinne jo net allinich definiearje wannear shutdown sil folgje en dat dit sil folgje. Yn dit gefal kin "wannear" elke kombinaasje fan oantsjutte parameters omfetsje: it totale oantal oanfragen foar in bepaalde perioade, it oantal parallelle ferbiningen, oanfragen yn ôfwachting, aktive werhellings, ensfh.

Jo wolle wierskynlik gjin circuit breaking misbrûke, mar it is moai om te witten dat jo in reserveplan hawwe yn gefal fan need.

6. Autoscaling

TL;DR: Ferheegje of ferminderje it oantal tsjinstynstânsjes ôfhinklik fan de opjûne kritearia.

Tsjinstmeshes binne gjin planners, dus dat dogge se net útdrage skaalfergrutting dysels. Se kinne lykwols ynformaasje jaan oer hokker planners har besluten basearje. Om't tsjinstmeshes tagong hawwe ta alle ferkear tusken tsjinsten, hawwe se wiidweidige ynformaasje oer wat der bart: hokker tsjinsten hawwe problemen, hokker tsjinsten binne tige licht laden (de oan har tawiisde kapasiteit is fergriemd), ensfh.

Bygelyks, Kubernetes skaleart tsjinsten op basis fan 'e CPU en ûnthâldgebrûk fan pods (sjoch ús ferslach "Autoscaling en boarnebehear yn Kubernetes"- ca. oerset.). Behear lykas dit lit sjen hoe te dwaan dit mei envoy, Istio и Prometheus, mar it proses sels is frij yngewikkeld. Wy wolle graach dat it tsjinstmesh dit ferienfâldigje troch ús gewoan betingsten yn te stellen lykas "it oantal tsjinstynstânsjes ferheegje auth, as it oantal oanfreegjende fersiken binnen in minút de drompel oerstjit."

7. Kanaryske ynset

TL;DR: Test nije funksjes as tsjinstferzjes op in subset fan brûkers.

Litte wy sizze dat jo in SaaS-produkt ûntwikkelje en fan doel binne in koele nije ferzje derfan út te rollen. Jo testen it yn staging en it wurke geweldich. Mar d'r binne noch bepaalde soargen oer har gedrach yn echte omstannichheden. Mei oare wurden, jo moatte de nije ferzje testen op echte problemen sûnder it fertrouwen fan brûkers te riskearjen. Kanaryske ynset binne geweldich foar dit. Se kinne jo in nije funksje demonstrearje oan in subset fan brûkers. Dizze subset kin bestean út de meast trouwe brûkers as dyjingen dy't wurkje mei de fergese ferzje fan it produkt, of brûkers dy't in winsk hawwe útsprutsen om "cavia's" te wêzen.

Tsjinstmeshes ymplementearje dit troch jo kritearia op te jaan dy't bepale wa't sil sjen hokker ferzje fan 'e applikaasje, en it ferkear dêrop rjochtsje. Der feroaret lykwols neat foar de tsjinsten sels. Ferzje 1.0 fan 'e tsjinst is fan betinken dat alle oanfragen komme fan brûkers dy't it moatte sjen, en ferzje 1.1 leaut itselde foar har brûkers. Underwilens kinne jo it persintaazje ferkear feroarje tusken de âlde en nije ferzjes, troch in groeiend oantal brûkers nei de nije te ferwizen as it stabyl wurket en jo "cavia's" jouwe de start.

8. Blau-griene ynset

TL;DR: Rôlje in koele nije funksje út, mar wês ree om alles daliks werom te nimmen.

Betsjutting blau-griene ynset is om in nije "blauwe" tsjinst út te rollen, dy't parallel mei de âlde "griene" lanseart. As alles soepel giet en de nije tsjinst goed docht, dan kin de âlde stadichoan útskeakele wurde. (Och, ienris sil dizze nije "blauwe" tsjinst it lot fan 'e "griene" werhelje en ferdwine ...) Blau-griene ynset ferskille fan kanaryske yn dat de nije funksje omfettet elkenien tagelyk brûkers (net diel); It punt hjir is om in "feilige haven" klear te hawwen foar it gefal dat der wat mis giet.

Tsjinstmeshes biede in heul handige manier om in "blauwe" tsjinst te testen en yn gefal fan problemen daliks oer te skeakeljen nei in wurkjende "griene". Net te hawwen oer it feit dat se ûnderweis in protte ynformaasje leverje (sjoch "Telemetry" hjirûnder) oer it wurk fan 'e "blau", dy't helpt om te begripen oft it klear is foar folsleine operaasje.

Noat. transl.: Jo kinne mear lêze oer ferskate ynsetstrategyen yn Kubernetes (ynklusyf de neamde kanaryske, blau/grien en oaren) yn dit artikel.

9. Health check

TL;DR: Hâld by hokker tsjinstynstânsjes funksjoneel binne en reagearje op dyjingen dy't net mear funksjoneel binne.

Sûnens Tsjek (sûnens Tsjek) helpt beslute oft tsjinst eksimplaren binne ree om te akseptearjen en ferwurkjen ferkear. Bygelyks, yn it gefal fan HTTP-tsjinsten, kin in sûnenskontrôle lykje op in GET-fersyk nei it einpunt /health... Antwurd 200 OK sil betsjutte dat it eksimplaar sûn is, elke oare - dat it net ree is om ferkear te ûntfangen. Tsjinstmeshes kinne jo opjaan sawol de manier wêrop funksjonaliteit wurdt kontrolearre as de frekwinsje wêrmei dizze kontrôle sil wurde útfierd. Dizze ynformaasje kin dan brûkt wurde foar oare doelen - bygelyks foar load balancing en circuit breaking.

Sa binne sûnenskontrôles gjin stand-alone gebrûksgefal, mar wurde typysk brûkt om oare doelen te berikken. Ek, ôfhinklik fan 'e resultaten fan sûnenskontrôles, kinne eksterne aksjes (yn relaasje mei oare tsjinstmesh-doelen) ferplicht wurde: bygelyks it bywurkjen fan de statusside, it meitsjen fan in probleem op GitHub, of it ynfoljen fan in JIRA-ticket. En servicemesh biedt in handich meganisme om dit alles te automatisearjen.

10. Laadferliening

TL;DR: Ferkear omliede yn reaksje op in tydlike pyk yn gebrûk.

As in bepaalde tsjinst wurdt oerladen mei ferkear, kinne jo in part fan dit ferkear tydlik omliede nei in oare lokaasje (dat is, "dump", "oerdracht" (skuorre) hy dêr). Bygelyks, nei in reservekopy tsjinst of data sintrum, of nei in permaninte pulsar ûnderwerp. As gefolch, de tsjinst sil trochgean mei it ferwurkjen fan guon oanfragen ynstee fan crashing en stopje it ferwurkjen fan alles hielendal. Load shedding is de foarkar foar it brekken fan it circuit, mar it is noch altyd net oan te rieden om it te misbrûken. It helpt foar te kommen cascadearjende flaters dy't feroarsaakje downstream tsjinsten te crashen.

11. Ferkear parallelization / spegeljen

TL;DR: Stjoer ien fersyk nei ferskate plakken tagelyk.

Soms is it nedich om in fersyk (of in bepaalde seleksje fan oanfragen) te stjoeren nei ferskate tsjinsten tagelyk. In typysk foarbyld is it ferstjoeren fan in diel fan produksjeferkear nei in stagingtsjinst. De haadproduksjewebserver stjoert in fersyk nei de streamôfwertstsjinst products.production en allinnich foar him. En de tsjinstmesh kopiearret dit fersyk yntelligint en stjoert it nei products.staging, dêr't de webtsjinner net iens fan bewust is.

In oare besibbe gebrûksgefal fan tsjinstmesh dat kin wurde ymplementearre boppe op ferkearsparallellisaasje is regression testen. It giet om it ferstjoeren fan deselde oanfragen nei ferskate ferzjes fan 'e tsjinst en kontrolearjen oft alle ferzjes itselde gedrage. Ik haw noch net tsjinkaam in tsjinst mesh ymplemintaasje mei in yntegrearre regression testing systeem lykas Diffy, mar it idee sels liket kânsryk.

12. Isolaasje

TL;DR: Brek jo tsjinstmesh yn mini-netwurken.

Ek bekind as segmintaasjeIsolaasje is de keunst om in tsjinstmesh te ferdielen yn logysk ûnderskate segminten dy't neat oer elkoar witte. Isolaasje is in bytsje as it meitsjen fan firtuele privee netwurken. It fûnemintele ferskil is dat jo noch kinne genietsje fan alle foardielen fan in tsjinst mesh (lykas tsjinst ûntdekking), mar mei tafoege feiligens. Bygelyks, as in oanfaller in tsjinst op ien subnet kin penetrearje, sil hy net kinne sjen hokker tsjinsten op oare subnets rinne of har ferkear ûnderskeppe.

Derneist kinne de foardielen ek organisatoarysk wêze. Jo kinne jo tsjinsten wolle subnetearje op basis fan jo bedriuwstruktuer en ûntwikkelders fan 'e kognitive lading ûntlêste om it heule tsjinstmesh yn gedachten te hâlden.

13. Fersykje taryfbeheining, opnij besykjen en timeouts

TL;DR: Jo hoege net mear drukke fersykbeheartaken op te nimmen yn 'e koadebase.

Al dizze dingen koenen wurde beskôge as aparte gebrûk gefallen, mar ik besletten om te kombinearjen se fanwege ien mienskiplike funksje: se nimme oer de fersyk lifecycle behear taken typysk ôfhannele troch applikaasje biblioteken. As jo ​​​​in webserver ûntwikkelje yn Ruby on Rails (net yntegreare mei in tsjinstmesh) dy't fersiken makket foar backend-tsjinsten fia gRPC, sil de applikaasje beslute moatte wat te dwaan as N fersiken mislearje. Jo sille ek moatte útfine hoefolle ferkear dizze tsjinsten dizze parameters kinne ferwurkje en hardkodearje mei in spesjale bibleteek. Plus, de applikaasje sil moatte beslute wannear't it tiid is om op te jaan en it fersyk út te litten (basearre op time-out). En om ien fan 'e boppesteande parameters te feroarjen, sil de webtsjinner moatte wurde stoppe, opnij konfigureare en opnij begon.

It laden fan dizze taken nei in tsjinstmesh betsjut net allinich dat tsjinstûntwikkelders der net oer hoege te tinken, mar ek dat se op in mear globale manier kinne wurde besjoen. As in komplekse keten fan tsjinsten brûkt wurdt, sis A -> B -> C -> D -> E, moat de hiele libbenssyklus fan it fersyk yn rekken brocht wurde. As de taak is om timeouts yn tsjinst C te ferlingjen, is it logysk om dit alles tagelyk te dwaan, en net yn dielen: troch de tsjinstkoade te aktualisearjen en te wachtsjen oant it pull-fersyk wurdt akseptearre en it CI-systeem de bywurke tsjinst ynset.

14. Telemetry

TL;DR: Sammelje alle nedige (en net hielendal) ynformaasje fan tsjinsten.

Telemetry is in algemiene term dy't metriken, ferspraat tracing en logs omfettet. Tsjinstmeshes biede meganismen foar it sammeljen en ferwurkjen fan alle trije soarten gegevens. Dit is wêr't dingen in bytsje wazig wurde, om't it oantal mooglike opsjes te grut is. Om metriken te sammeljen is der Prometheus en oare ark dy't brûkt wurde kinne om logs te sammeljen floeiend, Loki, Vector en oaren. (bygelyks ClickHouse mei ús loghouse foar K8s - ca. oerset.), foar ferspraat tracing der is Jager ensafuorthinne. Elk tsjinstmesh kin guon ark stypje en net oaren. It sil nijsgjirrich wêze om te sjen oft it projekt kin Iepenje Telemetry jouwe wat konverginsje.

Yn dit gefal is it foardiel fan tsjinstmeshtechnology dat sidecarcontainers yn prinsipe alle boppesteande gegevens kinne sammelje fan har tsjinsten. Mei oare wurden, jo hawwe in inkele telemetry-sammelsysteem ta jo beskikking, en it tsjinstmesh kin al dizze ynformaasje op ferskate manieren ferwurkje. Bygelyks:

• sturt logs fan in bepaalde tsjinst yn 'e CLI;
• kontrolearje it folume fan oanfragen fan it dashboard fan it tsjinstmesh;
• sammelje ferspraat spoaren en stjoer se nei in systeem lykas Jaeger.

Oandacht, subjektyf oardiel: Yn 't algemien is telemetry in gebiet wêryn sterke ynterferinsje fan' e tsjinstmesh net winsklik is. It sammeljen fan basisynformaasje en it folgjen fan guon gouden metriken lykas fersykssuksesrate en latency is prima, mar litte wy hoopje dat wy gjin Frankenstein-stacks opkomme dy't besykje spesjalisearre systemen te ferfangen, wêrfan guon harsels al bewiisd hawwe en goed studearre .

15. Audit

TL;DR: Dejingen dy't de lessen fan 'e skiednis ferjitte binne feroardiele om se te herheljen.

Auditing is de keunst fan it observearjen fan wichtige eveneminten yn in systeem. Yn it gefal fan in tsjinstmesh kin dit betsjutte dat it folgjen fan wa't oanfragen dien hat oan spesifike einpunten foar spesifike tsjinsten, of hoefolle kearen in feiligens-relatearre evenemint barde yn 'e lêste moanne.

It is dúdlik dat auditing tige nau besibbe is oan telemetry. It ferskil is dat telemetry meastentiids assosjearre is mei saken lykas produktiviteit en technyske yntegriteit, wylst kontrôle kin relatearje oan juridyske en oare problemen dy't bûten it strikt technyske sfear gean (bygelyks neilibjen fan GDPR - de EU Algemiene Regeling oer gegevensbeskerming).

16. Foarbyld

TL;DR: Lang libje React.js - in ûnútputlike boarne fan fancy ynterfaces.

Der kin in bettere term wêze, mar ik wit it net. Ik bedoel gewoan in grafyske foarstelling fan in tsjinstmesh of guon fan syn komponinten. Dizze fisualisaasjes kinne yndikatoaren omfetsje lykas gemiddelde latencies, sidecar-konfiguraasje-ynformaasje, resultaten foar sûnenskontrôles en warskôgings.

Wurkjen yn in tsjinst-rjochte omjouwing omfettet in folle hegere kognitive load yn ferliking mei Syn Majesteit de Monolith. Dêrom moat kognitive druk by alle kosten wurde fermindere. In ienfâldige grafyske ynterface foar in tsjinstmesh mei de mooglikheid om op in knop te klikken en it winske resultaat te krijen kin beslissend wêze foar de groei fan populariteit fan dizze technology.

Wiene net opnommen yn 'e list

Ik wie oarspronklik fan doel in pear mear gebrûksgefallen yn 'e list op te nimmen, mar besleat doe dat net te dwaan. Hjir binne se, tegearre mei de redenen foar myn beslút:

• Multi-data sintrum. Yn myn miening is dit net sasear in gebrûk as in smel en spesifyk gebiet fan tapassing fan tsjinstmeshes as in set fan funksjes lykas tsjinstûntdekking.
• Yn- en útgong. Dit is in besibbe gebiet, mar ik haw mysels (miskien keunstmjittich) beheind ta it gebrûk fan "east-west ferkear". Ingress en egress fertsjinje in apart artikel.

konklúzje

Dat is alles foar no! Nochris, dizze list is heul willekeurich en nei alle gedachten net kompleet. As jo ​​​​tinke dat ik wat miste of wat mis haw, nim dan kontakt mei my op Twitter (@luckerkins). Respektearje asjebleaft de regels fan fatsoen.

PS fan oersetter

De titelyllustraasje foar it artikel is basearre op in ôfbylding út it artikel "Wat is in Service Mesh (en wannear ien te brûken)?"(troch Gregory MacKinnon). It lit sjen hoe't guon funksjonaliteit fan applikaasjes (yn grien) is ferpleatst nei in tsjinstmesh dat ynterferbiningen tusken har leveret (yn blau).

Lês ek op ús blog:

• «Service Mesh: wat elke software-yngenieur moat witte oer de heulste technology";
• «Wat is in tsjinstmesh en wêrom haw ik it nedich [foar in wolkapplikaasje mei mikrotsjinsten]?";
• «Werom nei mikrotsjinsten mei Istio. Diel 1".

Boarne: www.habr.com