🥇Benotzungsfäll vu Service Mesh

Note. iwwersat.: Den Auteur vun dësem Artikel (Luc Perkins) ass en Entwéckler Affekot bei der CNCF Organisatioun, déi Heem ass fir sou Open Source Projete wéi Linkerd, SMI (Service Mesh Interface) a Kuma (iwwregens, hutt Dir Iech och gefrot firwat Istio ass net op dëser Lëscht.). Nach eng Kéier probéiert d'DevOps Gemeinschaft e bessert Verständnis vum trendy Hype genannt "Service Mesh" ze bréngen, hie lëscht 16 charakteristesch Fäegkeeten déi sou Léisungen ubidden.

haut Service Mesh gemaach ― ee vun de wäermsten Themen am Beräich vun der Software Engineering (a mat Recht!). Ech mengen dës Technologie ass onheemlech villverspriechend a géif gären se wäit ugeholl gesinn (wann et natierlech Sënn mécht). Wéi och ëmmer, et ass ëmmer nach vun enger Aura vu Geheimnis fir déi meescht Leit ëmginn. Gläichzäiteg och déi, déi gutt bekannt domat ass et dacks schwéier seng Virdeeler ze formuléieren a wat et genee ass (och Är wierklech). An dësem Artikel probéieren ech d'Situatioun ze korrigéieren andeems Dir verschidde oplëscht benotzen Fäll "Service Meshes"*.

* Notiz Iwwersetzung: hei a weider am Artikel gëtt genee dës Iwwersetzung ("Service Mesh") fir den nach neie Begrëff Service Mesh benotzt.

Awer als éischt wëll ech e puer Kommentarer maachen:

Ech hunn ni mat Service Meshes geschafft oder se ausserhalb vu Projete benotzt fir meng eegen Ausbildung ugefaang. Op der anerer Säit war ech deen, deen am Joer 2015 eng ganz Rëtsch Dokumentatioun fir den internen Service Mesh vun Twitter geschriwwen huet (et war deemools nach net e "Service Mesh" genannt) an un der Entwécklung vun der Websäit an der Dokumentatioun fir Linker, also dat heescht eppes.
Meng Lëscht ass ongeféier an onkomplett. Et ka gutt Benotzungsfäll fir mech onbekannt sinn, an nei Optiounen wäerte méiglecherweis mat der Zäit entstoen wéi d'Technologie sech entwéckelt a seng Popularitéit wiisst.
Zur selwechter Zäit ënnerstëtzt net all existent Service Mesh Implementatioun all déi opgelëscht Benotzungsfäll. Dofir sollten meng Aussoe wéi "Service Mesh Can ..." als "individuell gelies ginn, a vläicht all populär Service Mesh Implementatiounen kënnen ...".
D'Uerdnung vun de Beispiller mécht keen Ënnerscheed.

Kuerz Lëscht:

Service Entdeckung;
Verschlësselung;
Authentifikatioun an Autorisatioun;
Belaaschtung;
Circuit briechen;
autoscaling;
Kanaresch Deployementer;
blo-gréng Détachementer;
Gesondheet kontrolléieren;
Belaaschtung;
Verkéier Spigelen;
Isolatioun;
Ufro Taux limitéieren, Retry an Timeouts;
Telemetrie;
Audit;
visualization.

1. Service Entdeckung

TL;DR: Connectéiert mat anere Servicer am Netz mat einfachen Nimm.

D'Servicer solle sech automatesch géigesäiteg "fannen" mat adequat Nimm - z.B. service.api.production, pets/staging oder cassandra. Cloud Ëmfeld sinn elastesch, an een eenzegen Numm kann vill Instanzen vun engem Service verstoppen. Et ass kloer datt an esou enger Situatioun et kierperlech onméiglech ass all IP Adressen ze hardcode.

Plus, wann ee Service en aneren fënnt, sollt et fäeg sinn Ufroen un dee Service ze schécken ouni Angscht datt se um Input vu senger gebrochener Instanz ophalen. An anere Wierder, de Service Mesh muss d'Gesondheet vun all Serviceinstanzen iwwerwaachen an d'Lëscht vun den Hosten esou aktuell wéi méiglech halen.

All Service Mesh implementéiert de Service Entdeckungsmechanismus anescht. Am Moment ass déi allgemeng Manéier fir extern Prozesser wéi Kubernetes DNS ze delegéieren. An der Vergaangenheet op Twitter hu mir en Nummsystem fir dësen Zweck benotzt Finagle. Zousätzlech, Service Mesh Technologie mécht et méiglech fir Benotzerdefinéiert Benennungsmechanismen ze entstoen (obwuel ech nach keng SM-Implementatioun mat esou Funktionalitéit gesinn hunn).

2. Verschlësselung

TL;DR: Gitt vun onverschlësselte Verkéier tëscht Servicer lass a maacht dëse Prozess automatiséiert a skalierbar.

Et ass schéin ze wëssen datt Ugräifer net an Ärem internen Netzwierk penetréiere kënnen. Firewalls maachen eng super Aarbecht vun dëser. Awer wat geschitt wann en Hacker dobanne kënnt? Wäert hien fäeg maache wat e wëll mam intra-Service Traffic? Loosse mer hoffen, datt dat schliisslech net geschitt. Fir dëst Szenario ze vermeiden, sollt Dir en Nullvertrauensnetz implementéieren, an deem all Traffic tëscht Servicer verschlësselt ass. Déi meescht modern Service Meshes erreechen dëst duerch géigesäiteg TLS (géigesäitege TLS, mTLS). An e puer Fäll funktionnéiert mTLS a ganz Wolleken a Stärekéip (ech mengen interplanetaresch Kommunikatioun wäert iergendwann ähnlech arrangéiert ginn).

Natierlech, fir mTLS Service Mesh gemaach fakultativ. All Service ka sech ëm säin eegene TLS këmmeren, awer dëst bedeit datt Dir e Wee muss fannen fir Certificaten ze generéieren, se iwwer Servicehoster ze verdeelen, a Code an der Applikatioun enthalen déi dës Certificaten aus Dateien lued. Jo, vergiesst net dës Certificaten a reegelméissegen Ofstänn ze erneieren. Service Meshes automatiséieren mTLS mat Systemer wéi SPIFFE, déi am Tour de Prozess vun der Ausstellung an der Rotatioun vun Zertifikater automatiséieren.

3. Authentifikatioun an Autorisatioun

TL;DR: Etabléiert wien den Ufroer ass an definéiert wat se dierfen maachen ier d'Ufro iwwerhaapt de Service erreecht.

Servicer wëllen oft wëssen wien ass mécht d'Ufro (Authentifikatioun), a benotzt dës Informatioun, entscheet dass eng bestëmmten Entitéit ass erlaabt ze maachen (Autorisatioun). An dësem Fall kann de Pronomen "wien" verstoppen:

Aner Servicer. Dëst gëtt "Authentifikatioun" genannt peer" Zum Beispill, Service web wëll Zougang zum Service kréien db. Service Meshes léisen normalerweis esou Probleemer mat mTLS: Certificaten an dësem Fall handelen als néideg Identifizéierer.
E puer mënschlech Benotzer. Dëst gëtt "Authentifikatioun" genannt ufroen" Zum Beispill, Benotzer haxor69 wëll eng nei Luucht kafen. Service Meshes bidden verschidde Mechanismen, z.B. JSON Web Tokens.
Vill vun eis hunn dëst am Applikatiounscode gemaach. Eng Demande kënnt an, mir kucken duerch den Dësch users, Fannt de Benotzer a vergläicht d'Passwuert, kontrolléiert dann d'Kolonn permissions etc. Am Fall vun engem Service Mesh geschitt dat ier d'Ufro iwwerhaapt de Service erreecht.

Wann mir festgestallt hunn, vu wiem d'Ufro koum, musse mir bestëmmen wat dës Entitéit erlaabt ass ze maachen. E puer Service Meshes erlaaben Iech Basispolitiken ze setzen (iwwer wien wat maache kann) als YAML Dateien oder op der Kommandozeil, anerer bidden Integratioun mat Kaderen wéi Open Politik Agent. D'ultimativ Zil ass fir Är Servicer all Ufro ze akzeptéieren, sécher unzehuelen datt et aus enger vertrauter Quell kënnt и dës Aktioun ass erlaabt.

4. Laascht Equiliber

TL;DR: Verdeelt d'Laascht iwwer Serviceinstanzen no engem spezifesche Muster.

E "Service" an enger Service Sektioun besteet ganz dacks aus villen identesche Fäll. Zum Beispill, haut de Service cache besteet aus 5 Exemplare, a muer kann hir Zuel op 11 klammen. Demandë geschéckt un cache, muss no engem spezifeschen Zweck verdeelt ginn. Zum Beispill, minimiséieren d'Latenz oder maximéiert d'Wahrscheinlechkeet fir an eng Aarbechtsinstans ze kommen. Dee meescht benotzten Algorithmus ass Round-Robin, awer et gi vill anerer - zum Beispill déi gewiicht Method (gewiicht) Ufroen (Dir kënnt gewënschte Ziler auswielen), Ring (ring) hashing (benotzt konsequent Hashing iwwer Upstream Hosten) oder mannst Ufro Method (Preferenz gëtt der Instanz mat de mannste Ufroe ginn).

Klassesch Balancer hunn aner Funktiounen, wéi HTTP-Caching an DDoS-Schutz, awer si sinn net ganz relevant fir den Ost-West-Traffic (dat ass, fir de Verkéier, deen an engem Datenzenter fléisst - ca. Iwwersetzung) (typesch Ëmfang vum Service Mesh). Natierlech ass et net néideg e Service Mesh fir Laaschtbalancéierung ze benotzen, awer et erlaabt Iech Balancéierungspolitike fir all Service aus enger zentraliséierter Kontrollschicht ze setzen an ze kontrolléieren, an doduerch d'Noutwennegkeet eliminéiert fir separat Lastbalancer am Netzstack ze lafen an ze konfiguréieren. .

5. Circuit gebrach

TL;DR: Stop de Verkéier op de problematesche Service a kontrolléiert de Schued am schlëmmste Fall Szenarie.

Wann aus irgendege Grënn de Service net mam Traffic eens kann, bitt de Service Mesh verschidde Méiglechkeeten fir dëse Problem ze léisen (aner gëtt an de passenden Rubriken diskutéiert). Circuit Breaking ass déi schwéierst Optioun fir e Service vum Traffic ze trennen. Wéi och ëmmer, eleng mécht et kee Sënn - e Backupplang ass néideg. Réckdrock kann zur Verfügung gestallt ginn (Réckdrock) op Servicer déi Ufroe maachen (vergiesst just net Äre Service Mesh fir dëst ze konfiguréieren!), Oder zum Beispill d'Statussäit rout ze faarwen an d'Benotzer op eng aner Versioun vun der Säit mat engem "falende Wal" ëmzeweisen ("Twitter ass erof").

Service Meshes erlaben Iech net nëmmen ze definéieren wéini shutdown wäert verfollegen an dass dëst wäert duerno. An dësem Fall, "wann" kann all Kombinatioun vun spezifizéierte Parameteren enthalen: d'Gesamtzuel vun Ufroe fir eng gewëssen Zäit, d'Zuel vun de parallele Verbindungen, pendend Ufroen, aktiv Neiversichten, etc.

Dir wëllt wahrscheinlech keng Circuitbriechung mëssbrauchen, awer et ass flott ze wëssen datt Dir e Backupplang am Noutfall hutt.

6. Autoscaling

TL;DR: Erhéije oder reduzéieren d'Zuel vun de Serviceinstanzen ofhängeg vun de spezifizéierte Critèren.

Service Meshes sinn net Scheduler, sou datt se net ausdroen selwer skaléieren. Wéi och ëmmer, si kënnen Informatioun ubidden iwwer wéi eng Planer hir Entscheedungen baséieren. Zënter Service Meshes hunn Zougang zu all Traffic tëscht Servicer, si hunn extensiv Informatioun iwwer wat geschitt: wéi eng Servicer erliewen Problemer, wéi eng Servicer si ganz liicht gelueden (d'Kapazitéit, déi hinnen zougedeelt ass, gëtt verschwend), etc.

Zum Beispill, Skala Kubernetes Servicer baséiert op Pods 'CPU an Erënnerung Notzung (kuckt eise Bericht "Autoscaling a Ressourcemanagement zu Kubernetes"- ca. Iwwersetzung), awer wann Dir décidéiert fir op all aner Metrik ze skaléieren (an eisem Fall, Verkéiersbezunn), braucht Dir eng speziell Metrik. Gestioun esou weist wéi dëst ze maachen mat spécial, Istio и Prometheus, awer de Prozess selwer ass zimlech komplizéiert. Mir wëllen datt de Service Mesh dëst vereinfacht andeems mir eis einfach Konditioune setzen wéi "d'Zuel vun de Serviceinstanzen erhéijen auth, wann d'Zuel vun de pendende Ufroe bannent enger Minutt d'Schwell iwwerschreift."

7. Kanaresch deployment

TL;DR: Test nei Fonctiounen oder Service Versiounen op engem Ënnerdeel vun Benotzer.

Loosst eis soen datt Dir e SaaS Produkt entwéckelt a wëlles eng cool nei Versioun dovun auszerollen. Dir hutt et an der Inszenéierung getest an et huet super geschafft. Mä et sinn nach bestëmmte Bedenken iwwer hir Verhalen an real Konditiounen. An anere Wierder, Dir musst déi nei Versioun op echte Probleemer testen ouni d'Vertrauen vum Benotzer ze riskéieren. Kanaresch Deployementer si super fir dëst. Si erlaben Iech eng nei Feature zu engem Ënnerdeel vun de Benotzer ze demonstréieren. Dëse Subset kann aus de treiste Benotzer besteet oder déi, déi mat der gratis Versioun vum Produkt schaffen, oder Benotzer déi e Wonsch ausgedréckt hunn "Meerschwäin" ze sinn.

Service Meshes implementéieren dëst andeems Dir Critèren spezifizéiere kënnt, déi bestëmmen wien déi Versioun vun der Applikatioun gesäit, an de Traffic deementspriechend routéieren. Fir d'Servicer selwer ännert sech awer näischt. D'Versioun 1.0 vum Service mengt datt all Ufroe vu Benotzer kommen, déi et solle gesinn, an d'Versioun 1.1 gleeft d'selwecht fir seng Benotzer. Mëttlerweil kënnt Dir de Prozentsaz vum Traffic tëscht der aler an der neier Versioun änneren, eng wuessend Zuel vu Benotzer op déi nei redirectéieren, wann et stabil funktionnéiert an Är "Meerschwäin" ginn de Go-Ahead.

8. Blo-gréng Détachementer

TL;DR: Roll eng cool nei Feature aus, awer bereet Iech direkt alles zréck ze huelen.

Sinn blo-gréng Détachementer ass en neien "bloen" Service auszerollen, parallel mam alen "grénge" lancéieren. Wann alles glat geet an den neie Service funktionnéiert gutt, da kann deen alen lues a lues deaktivéiert ginn. (Ach, iergendwann wäert dësen neie "bloen" Service d'Schicksal vum "gréngen" widderhuelen a verschwannen ...) Blo-gréngen Deployementer ënnerscheede sech vun de Kanaresch an datt déi nei Funktioun deckt jiddereen op eemol Benotzer (net Deel); De Punkt hei ass e "sécheren Hafen" prett ze hunn am Fall wou eppes falsch leeft.

Service Meshes bidden e ganz praktesche Wee fir e "bloen" Service ze testen an direkt op eng funktionéierend "gréng" ze wiesselen am Fall vu Probleemer. Net der Tatsaach ze ernimmen, datt laanscht de Wee vill Informatiounen (kuckt "Telemetrie" ënnendrënner) iwwer d'Aarbecht vun der "blo", déi hëlleft ze verstoen, ob et fir voll Operatioun prett ass.

Note. iwwersat.: Dir kënnt méi iwwer verschidden Deploymentstrategien an Kubernetes liesen (inklusiv déi ernimmt Kanaresch, blo / gréng an anerer) an dësen Artikel.

9. Gesondheet kontrolléieren

TL;DR: Verfollegt wéi eng Serviceinstanzen funktionell sinn a reagéiert op déi déi net méi funktionell sinn.

Gesondheetscheck (Gesondheetscheck) hëlleft ze entscheeden ob Service Instanzen prett sinn Traffic ze akzeptéieren an Prozess. Zum Beispill, am Fall vun HTTP-Servicer, kann e Gesondheetscheck ausgesinn wéi eng GET-Ufro un den Endpunkt /health. Äntwert 200 OK wäert heeschen, datt d'Instanz gesond ass, all aner - datt et net prett ass Traffic ze kréien. Service Meshes erlaben Iech souwuel de Wee ze spezifizéieren wéi d'Funktionalitéit gepréift gëtt an d'Frequenz mat där dës Kontroll duerchgefouert gëtt. Dës Informatioun kann dann fir aner Zwecker benotzt ginn - zum Beispill fir Belaaschtung a Circuitbriechung.

Also ass d'Gesondheetskontroll net e Stand-alone Benotzungsfall, awer gëtt normalerweis benotzt fir aner Ziler z'erreechen. Och, ofhängeg vun de Resultater vun de Gesondheetsprüfungen, kënnen Handlungen extern zu anere Service Mesh Ziler erfuerderlech sinn: zum Beispill d'Statussäit aktualiséieren, en Thema op GitHub erstellen oder e JIRA Ticket ausfëllen. A Service Mesh bitt e praktesche Mechanismus fir dat alles ze automatiséieren.

10. Belaaschtung

TL;DR: Redirect Traffic als Äntwert op eng temporär Spike am Gebrauch.

Wann e bestëmmte Service mat Traffic iwwerlaascht ass, kënnt Dir e puer vun dësem Traffic temporär op eng aner Plaz redirectéieren (dat ass "dump", "transfer" (Schapp) hien do). Zum Beispill, zu engem Backupsatellit Service oder Daten Zentrum, oder zu engem permanent Pulsar Thema. Als Resultat wäert de Service weider e puer Ufroe veraarbecht anstatt alles ofzeschléissen an ze stoppen. D'Belaaschtung ass léiwer wéi de Circuit ze briechen, awer et ass nach ëmmer net unzeroden et ze mëssbrauchen. Et hëlleft Kaskadfehler ze vermeiden, déi Downstream Servicer verursaachen.

11. Verkéier parallelization / Spigelen

TL;DR: Schéckt eng Ufro op e puer Plazen gläichzäiteg.

Heiansdo gëtt et e Besoin fir eng Ufro (oder eng gewësse Selektioun vun Ufroen) un e puer Servicer gläichzäiteg ze schécken. En typescht Beispill ass en Deel vum Produktiounsverkéier un e Staging Service ze schécken. Den Haaptproduktiounswebserver schéckt eng Ufro un den Downstream Service products.production an nëmmen him. An de Service Mesh kopéiert dës Ufro intelligent a schéckt se un products.staging, wat de Webserver net emol bewosst ass.

En anere verbonne Service Mesh Benotzungsfall deen uewen op Traffic Paralleliséierung ëmgesat ka ginn ass Regressiounstest. Et handelt sech ëm déiselwecht Ufroe fir verschidde Versioune vum Service ze schécken an ze kontrolléieren ob all Versiounen d'selwecht behuelen. Ech sinn nach net mat engem Service Mesh Implementatioun mat engem integréierte Regressiounstestsystem wéi Diffy, mee d'Iddi selwer schéngt villverspriechend.

12. Isolatioun

TL;DR: Break Äre Service Mesh a Mini-Netzwierker.

Och bekannt als SegmentatiounIsolatioun ass d'Konscht fir e Servicemesh a logesch ënnerschiddlech Segmenter opzedeelen déi näischt iwwerenee wëssen. Isolatioun ass e bësse wéi virtuell privat Netzwierker ze kreéieren. De fundamentalen Ënnerscheed ass datt Dir ëmmer nach all d'Virdeeler vun engem Service Mesh genéisst (wéi Service Entdeckung), awer mat zousätzlech Sécherheet. Zum Beispill, wann en Ugräifer et fäerdeg bréngt e Service an engem vun den Ënnernetzer z'erreechen, wäert hien net fäeg sinn ze gesinn wéi eng Servicer op anere Subnetzer lafen oder hiren Traffic ofbriechen.

Zousätzlech kënnen d'Virdeeler och organisatoresch sinn. Dir wëllt Är Servicer op Basis vun Ärer Firmastruktur subnetéieren an d'Entwéckler vun der kognitiver Laascht entlaaschten fir de ganze Servicemesh am Kapp ze halen.

13. Ufro Taux limitéieren, retries an timeouts

TL;DR: Dir braucht net méi déi nitty-gritty Ufro Gestioun Aufgaben an Ärer Codebase abegraff.

All dës Saache kéinten als separat Benotzungsfäll ugesi ginn, awer ech hunn decidéiert se ze kombinéieren wéinst enger gemeinsamer Feature: si iwwerhuelen d'Ufro Lifecycle Management Aufgaben, déi typesch vun Applikatiounsbibliothéiken gehandhabt ginn. Wann Dir e Webserver am Ruby on Rails entwéckelt (net mat engem Service Mesh integréiert) deen Ufroe fir Backend Servicer iwwer gRPC, d'Applikatioun muss entscheeden wat ze maachen wann N Ufroe feelen. Dir musst och erausfannen wéi vill Traffic dës Servicer fäeg sinn dës Parameteren mat enger spezieller Bibliothéik ze veraarbechten an ze hardcodéieren. Plus, d'Applikatioun muss entscheeden wéini et Zäit ass opzeginn an d'Ufro ausléisen (baséiert op Timeout). A fir eng vun den uewe genannte Parameteren z'änneren, muss de Webserver gestoppt ginn, nei konfiguréiert an erëm gestart ginn.

Dës Aufgaben op e Service Mesh eroflueden heescht net nëmmen datt Service Entwéckler net iwwer si mussen nodenken, awer och datt se op eng méi global Manéier kënne gekuckt ginn. Wann eng komplex Kette vu Servicer benotzt gëtt, soen A -> B -> C -> D -> E, muss de ganze Liewenszyklus vun der Ufro berücksichtegt ginn. Wann d'Aufgab ass d'Timeouts am Service C ze verlängeren, ass et logesch dëst alles gläichzäiteg ze maachen, an net an Deeler: andeems Dir de Servicecode aktualiséiert a waart bis d'Pull-Ufro akzeptéiert gëtt an de CI System den aktualiséierten Service ofsetzt.

14. Telemetrie

TL;DR: Sammelt all néideg (an net ganz) Informatioune vu Servicer.

Telemetrie ass en allgemenge Begrëff deen Metriken, verdeelt Tracing a Logbicher enthält. Service Meshes bidden Mechanismen fir all dräi Zorte vun Daten ze sammelen an ze veraarbecht. Dëst ass wou d'Saachen e bësse blurry ginn, well d'Zuel vu méiglechen Optiounen ze grouss ass. Fir Metriken ze sammelen gëtt et Prometheus an aner Tools déi benotzt kënne fir Logbicher ze sammelen fléissend, Loki, Vecteure an anerer. (zum Beispill ClickHouse mat eisem Loghaus fir K8s - ca. Iwwersetzung), fir verdeelt Tracing gëtt et Jaeger a sou weider. All Service Mesh kann e puer Tools ënnerstëtzen an net anerer. Et wäert interessant sinn ze gesinn, ob de Projet kann Open Telemetrie eng Konvergenz ubidden.

An dësem Fall ass de Virdeel vun der Service Mesh Technologie datt Sidecar Container am Prinzip all déi uewe genannte Donnéeën aus hire Servicer sammelen. An anere Wierder, Dir hutt en eenzegen Telemetrie Sammelsystem zur Verfügung, an de Service Mesh kann all dës Informatioun op verschidde Manéiere veraarbechten. Zum Beispill:

Schwäif Logbicher vun engem bestëmmte Service am CLI;
Monitor de Volume vun Ufroe vum Service Mesh Dashboard;
sammelen verdeelt Spuren a weiderginn hinnen zu engem System wéi Jaeger.

Opgepasst, subjektiv Uerteel: Allgemeng ass Telemetrie e Gebitt an deem staark Interferenz vum Service Mesh onerwënscht ass. Basisinformatioun sammelen an on-the-fly e puer gëllene Metriken wéi Ufro Erfollegsquote a Latenz verfollegen ass gutt, awer loosst eis hoffen datt mir Frankenstein Stacks net gesinn entstinn déi probéieren spezialiséiert Systemer ze ersetzen, e puer vun deenen sech scho bewisen a gutt studéiert hunn .

15. Audit

TL;DR: Déi, déi d'Lektioune vun der Geschicht vergiessen, sinn veruerteelt se ze widderhuelen.

Audit ass d'Konscht fir wichteg Eventer an engem System ze observéieren. Am Fall vun engem Service Mesh, kann dat bedeiten Tracking wien Ufroe fir spezifesch Endpunkte fir spezifesch Servicer gemaach hunn, oder wéi oft e Sécherheetsbezunnen Event am leschte Mount geschitt ass.

Et ass kloer datt Audit ganz enk mat Telemetrie verbonnen ass. Den Ënnerscheed ass datt Telemetrie normalerweis mat Saachen wéi Produktivitéit an technescher Integritéit assoziéiert ass, während Audit kann op juristesch an aner Themen bezéien déi iwwer déi strikt technesch Sphär goen (zum Beispill d'Konformitéit mam GDPR - d'EU General Regulation on Dateschutz).

16. Virschau

TL;DR: Vive React.js - eng onendlech Quell vu flotten Interfaces.

Et gëtt vläicht e bessere Begrëff, awer ech weess et net. Ech mengen einfach eng grafesch Representatioun vun engem Service Mesh oder e puer vu senge Komponenten. Dës Visualiséierunge kënnen Indikatoren enthalen wéi duerchschnëttlech Latenzen, Sidecar Konfiguratiounsinformatioun, Gesondheetscheckresultater an Alarmer.

An engem serviceorientéierten Ëmfeld schaffen involvéiert eng vill méi héich kognitiv Belaaschtung am Verglach zu Seng Majestéit de Monolith. Dofir sollt de kognitiven Drock op all Käschten reduzéiert ginn. Eng einfach grafesch Interface fir e Service Mesh mat der Fäegkeet fir op e Knäppchen ze klicken an dat gewënschte Resultat ze kréien kéint entscheedend sinn fir de Wuesstum vun der Popularitéit vun dëser Technologie.

War net an der Lëscht abegraff

Ech wollt ursprénglech e puer méi Benotzungsfäll an der Lëscht enthalen, awer hunn dunn decidéiert net. Hei sinn se, zesumme mat de Grënn fir meng Entscheedung:

Multi-Datenzentrum. Menger Meenung no ass dëst net sou vill e Benotzungsfall wéi e schmuel a spezifescht Gebitt vun der Applikatioun vu Service Meshes oder e puer Set vu Funktiounen wéi Service Entdeckung.
Ingress an Ausgang. Dëst ass e verwandte Beräich, awer ech hunn mech limitéiert (vläicht kënschtlech) zum "Ost-West Traffic" Benotzungsfall. Ingress an Egress verdéngen en separaten Artikel.

Konklusioun

Dat ass alles fir elo! Elo ass dës Lëscht ganz arbiträr a wahrscheinlech onkomplett. Wann Dir mengt datt ech eppes verpasst hunn oder eppes falsch hunn, da kontaktéiert mech w.e.g. op Twitter (@luckerkins). Respektéiert w.e.g. d'Regele vun der Anstännegkeet.

PS vum Iwwersetzer

D'Titelillustratioun fir den Artikel baséiert op engem Bild aus dem Artikel "Wat ass e Service Mesh (a wéini een ze benotzen)?"(vum Gregory MacKinnon). Et weist wéi e puer Funktionalitéit vun Uwendungen (am gréngen) an e Service Mesh geplënnert ass, deen Interconnections tëscht hinnen ubitt (am blo).

Liest och op eisem Blog:

Source: will.com