Opmerking. vert.: Service mesh is een fenomeen dat nog geen stabiele vertaling in het Russisch heeft (meer dan 2 jaar geleden hebben we de optie “mesh for services” voorgesteld, en even later begonnen enkele collega’s de combinatie “service zeef” actief te promoten). Het voortdurende gepraat over deze technologie heeft geleid tot een situatie waarin de marketing- en technische componenten te nauw met elkaar verweven zijn. Dit prachtige materiaal van een van de auteurs van de oorspronkelijke term is bedoeld om duidelijkheid te bieden aan ingenieurs en anderen.
Komisch van
Introductie
Als je een software-ingenieur bent die ergens in de backend-systeemruimte werkt, is de term 'service mesh' de afgelopen jaren waarschijnlijk al stevig in je hoofd verankerd. Dankzij een vreemd toeval neemt deze term de industrie steeds meer over, en de hype en promotionele aanbiedingen die ermee gepaard gaan groeien als een sneeuwbal die bergafwaarts vliegt en geen tekenen van vertraging vertoont.
Service mesh werd geboren in de duistere, bevooroordeelde wateren van het cloud-native ecosysteem. Helaas betekent dit dat een groot deel van de controverse eromheen varieert van “caloriearme praatjes” tot – om een technische term te gebruiken – regelrechte onzin. Maar als je al het lawaai doorbreekt, zul je merken dat het servicegaas een zeer reële, gedefinieerde en belangrijke functie heeft.
In dit bericht zal ik precies dat proberen te doen: een eerlijke, diepgaande, op ingenieurs gerichte gids bieden voor service mesh. Ik ga niet alleen de vraag beantwoorden: "Wat het is?", - maar ook "Waarvoor?"En "Waarom nu?". Ten slotte zal ik proberen uit te leggen waarom (naar mijn mening) deze specifieke technologie zo'n gekke opschudding heeft veroorzaakt, wat op zichzelf een interessant verhaal is.
Wie ben ik?
Dag Allemaal! Mijn naam is . Ik ben een van de makers – het allereerste service mesh-project en het project dat verantwoordelijk is voor het verschijnen van de term servicegaas als zodanig (sorry jongens!). (Opmerking vert.: Trouwens, aan het begin van de verschijning van deze term, meer dan 2,5 jaar geleden, vertaalden we al het vroege materiaal van dezelfde auteur getiteld “".) Ik leid ook is een startup die coole service mesh-dingen maakt zoals Linkerd en .
Je kunt waarschijnlijk wel raden dat ik een zeer bevooroordeelde en subjectieve mening heb over deze kwestie. Ik zal echter proberen de vooringenomenheid tot een minimum te beperken (met uitzondering van één sectie: “Waarom wordt er zoveel gesproken over service mesh?”, - waarin ik mijn vooropgezette ideeën alsnog zal delen). Ik zal ook mijn best doen om deze gids zo objectief mogelijk te maken. Voor specifieke voorbeelden zal ik in de eerste plaats vertrouwen op de ervaring van Linkerd, terwijl ik zal wijzen op de verschillen (indien aanwezig) die ik ken bij de implementatie van andere service mesh-typen.
Oké, tijd om verder te gaan met de lekkernijen.
Wat is een servicemesh?
Ondanks alle hype is de structuur van het servicenetwerk vrij eenvoudig. Dit zijn slechts een aantal gebruikersruimteproxy's die zich "naast" de services bevinden (we zullen later wat praten over wat "het volgende" is), plus een reeks controleprocessen. De proxy's worden gezamenlijk gebeld gegevens vlak, en de controleprocessen worden aangeroepen Controle vliegtuig. Het datavlak onderschept oproepen tussen services en doet er “allerlei verschillende dingen” mee; Het besturingsvlak coördineert dienovereenkomstig het gedrag van de proxy en biedt u toegang, d.w.z. operator, naar de API, waardoor het netwerk als geheel kan worden gemanipuleerd en gemeten.
Wat voor soort proxy is dit? Dit is een Layer 7-bewuste TCP-proxy (d.w.z. “rekening houdend met” laag 7 van het OSI-model) zoals HAProxy en NGINX. U kunt een proxy naar wens kiezen; Linkerd gebruikt een Rust-proxy, eenvoudigweg genaamd . We hebben het speciaal samengesteld voor service mesh. Andere meshes geven de voorkeur aan andere proxy's (Envoy is een gebruikelijke keuze). Het kiezen van een proxy is echter slechts een kwestie van implementatie.
Wat doen deze proxyservers? Uiteraard proxy's ze oproepen van en naar diensten (strikt genomen fungeren ze als proxy's en reverse proxy's, waarbij ze zowel inkomende als uitgaande oproepen afhandelen). En ze implementeren een functieset die zich richt op oproepen между Diensten. Deze focus op verkeer tussen services is wat een service mesh-proxy onderscheidt van bijvoorbeeld API-gateways of ingress-proxy's (de laatste richten zich op oproepen die vanuit de buitenwereld het cluster binnenkomen). (Opmerking. vert.: Voor een vergelijking van bestaande Ingress-controllers voor Kubernetes, waarvan er vele de reeds genoemde Envoy gebruiken, zie .)
We hebben het datavlak dus op orde. Het besturingsvlak is eenvoudiger: het is een reeks componenten die alle mechanismen bieden die het datavlak nodig heeft om op een gecoördineerde manier te werken, inclusief het ontdekken van diensten, het uitgeven van TLS-certificaten, metrische aggregatie, enz. Het datavlak informeert het besturingsvlak over zijn gedrag; op zijn beurt biedt het besturingsvlak een API waarmee u het gedrag van het datavlak als geheel kunt wijzigen en monitoren.
Hieronder ziet u een diagram van het besturingsvlak en het gegevensvlak in Linkerd. Zoals u kunt zien, bevat het besturingsvlak verschillende componenten, waaronder een Prometheus-instantie die statistieken verzamelt van proxyservers, evenals andere componenten zoals destination (service-ontdekking), identity (certificeringsinstantie, CA) en public-api (eindpunten voor web en CLI). Het gegevensvlak is daarentegen een eenvoudige linkerd-proxy naast het toepassingsexemplaar. Dit is slechts een logisch diagram; In een implementatie in de echte wereld hebt u mogelijk drie replica's van elk onderdeel van het besturingsvlak en honderden of duizenden proxy's in het gegevensvlak.
(De blauwe rechthoeken in dit diagram symboliseren de grenzen van Kubernetes-pods. Je kunt zien dat de containers met linkerd-proxy zich in dezelfde pod bevinden als de applicatiecontainers. Dit schema staat bekend als zijspan container.)
Service mesh-architectuur heeft verschillende belangrijke implicaties. Ten eerste heeft een service mesh, aangezien het de taak van een proxy is om oproepen tussen services te onderscheppen, alleen zin als uw applicatie voor een bepaalde reeks services is gemaakt. Gaas men kan gebruik met monolieten, maar dit is duidelijk overbodig omwille van één enkele proxy, en het is onwaarschijnlijk dat er veel vraag zal zijn naar de functionaliteit ervan.
Een ander belangrijk gevolg is dat de service mesh dit vereist enorm aantal proxy's. In feite koppelt Linkerd een linkerd-proxy aan elk exemplaar van elke service (andere implementaties voegen een proxy toe aan elk knooppunt/host/virtuele machine. Dat is sowieso veel). Een dergelijk actief gebruik van proxy's brengt op zichzelf een aantal extra complicaties met zich mee:
- Proxy's in het datavlak moeten dat zijn snel, aangezien er voor elke oproep een aantal oproepen naar de proxy zijn: één aan de clientzijde, één aan de serverzijde.
- Proxy's zouden dat ook moeten zijn klein и lichtgewicht. Beide verbruiken geheugen- en CPU-bronnen, en dit verbruik zal lineair toenemen met de toepassing.
- U hebt een mechanisme nodig om een groot aantal proxy's te implementeren en bij te werken. Handmatig doen is geen optie.
Over het algemeen ziet een service mesh er als volgt uit (althans vanuit vogelperspectief): je zet een aantal userspace-proxy's in die "iets doen" met intern, interserviceverkeer, en gebruikt een controlevlak om deze te monitoren en te beheren.
Nu is het tijd om de vraag te stellen: “Waarom?”
Waar is een servicemesh voor?
Degenen die voor het eerst met het idee van een servicegaas in aanraking kwamen, kunnen vergeven worden dat ze zich een beetje huiverig voelden. Het service mesh-ontwerp betekent dat het niet alleen de latentie in de applicatie verhoogt, maar ook consumeren middelen en zal toevoegen een heleboel nieuwe mechanismen in de infrastructuur. Eerst zet u een servicegaas op, en dan merkt u plotseling dat u honderden (zo niet duizenden) proxy's moet bedienen. De vraag is: wie gaat dit vrijwillig doen?
Het antwoord op deze vraag bestaat uit twee delen. Ten eerste kunnen de transactiekosten die gepaard gaan met het inzetten van deze proxy’s aanzienlijk worden verlaagd dankzij enkele veranderingen die plaatsvinden in het ecosysteem (hierover later meer).
Ten tweede is een apparaat als dit eigenlijk een geweldige manier om extra logica in het systeem te introduceren. Niet alleen omdat een service mesh veel nieuwe functionaliteit kan toevoegen, maar ook omdat dit kan zonder het ecosysteem te verstoren. In feite is het hele service mesh-model gebaseerd op dit uitgangspunt: in een multiservicesysteem, wat er ook gebeurt maken individuele diensten, verkeer tussen hen is het ideale punt om functionaliteit toe te voegen.
In Linkerd is de functionaliteit bijvoorbeeld (zoals in de meeste meshes) vooral gericht op HTTP-aanroepen, waaronder HTTP/2 en gRPC*. De functionaliteit is behoorlijk rijk - deze kan in drie klassen worden verdeeld:
- Functies gerelateerd aan betrouwbaarheid. Herhaalde verzoeken, time-outs, kanarie-aanpak (verkeerssplitsing/omleiding), enz.
- Functies gerelateerd aan toezicht houden. Aggregatie van succespercentages, vertragingen en aanvraagvolumes voor elke dienst of individuele richting; constructie van topologische kaarten van diensten, enz.
- Functies gerelateerd aan veiligheid. Wederzijdse TLS, toegangscontrole, etc.
* Vanuit het standpunt van Linkerd verschilt gRPC praktisch niet van HTTP/2: het gebruikt alleen protobuf in de payload. Vanuit het perspectief van een ontwikkelaar zijn de twee dingen natuurlijk verschillend.
Veel van deze mechanismen werken op verzoekniveau (vandaar de "L7-proxy"). Als de Foo-service bijvoorbeeld een HTTP-aanroep naar de Bar-service doet, kan de linkerd-proxy aan de Foo-kant intelligente taakverdeling uitvoeren en oproepen van Foo naar Bar-instanties routeren op basis van de waargenomen latentie; het kan het verzoek indien nodig herhalen (en als het idempotent is); het kan de responscode en time-out registreren, enz. Op dezelfde manier kan linkerd-proxy aan de Bar-kant een verzoek afwijzen als dit niet is toegestaan of als de verzoeklimiet wordt overschreden; kan een vertraging van zijn kant registreren, enz.
Proxy’s kunnen ook ‘iets doen’ op verbindingsniveau. linkerd-proxy aan de Foo-kant kan bijvoorbeeld een TLS-verbinding initiëren, en linkerd-proxy aan de Bar-kant kan deze beëindigen, en beide partijen kunnen elkaars TLS-certificaten* verifiëren. Dit biedt niet alleen versleuteling tussen diensten, maar ook een cryptografisch veilige manier om diensten te identificeren: Foo en Bar kunnen ‘bewijzen’ dat ze zijn wie ze zeggen dat ze zijn.
* "Wederzijds van een vriend" betekent dat het clientcertificaat ook wordt geverifieerd (wederzijdse TLS). Bij ‘klassieke’ TLS, bijvoorbeeld tussen een browser en een server, wordt doorgaans het certificaat van slechts één kant (de server) geverifieerd.
Ongeacht of ze op verzoek- of verbindingsniveau werken, het is belangrijk om te benadrukken dat alle service mesh-functies dat ook zijn operationeel karakter. Linkerd kan de semantiek van de payload niet transformeren, bijvoorbeeld door velden aan een JSON-fragment toe te voegen of wijzigingen aan te brengen in protobuf. We zullen later over deze belangrijke functie praten als we het hebben over ESB en middleware.
Dit is de reeks functies die een servicemesh biedt. De vraag rijst: waarom zouden we ze niet rechtstreeks in de applicatie implementeren? En waarom zou je überhaupt moeite doen met een proxy?
Waarom service mesh een goed idee is
Hoewel de mogelijkheden van een servicemesh opwindend zijn, ligt de kernwaarde ervan niet in de functies ervan. Uiteindelijk wij Kan implementeer ze rechtstreeks in de applicatie (we zullen later zien dat dit de oorsprong was van de service mesh). Om het in één zin samen te vatten: de waarde van een servicemesh is: het biedt functies die essentieel zijn voor het op consistente wijze uitvoeren van moderne serversoftware over de gehele stack en onafhankelijk van de applicatiecode.
Laten we dit voorstel analyseren.
«Functies die cruciaal zijn voor het draaien van moderne serversoftware" Als u een transactionele serverapplicatie maakt die is verbonden met het openbare internet, waarbij u verzoeken van de buitenwereld accepteert en daar binnen korte tijd op reageert - bijvoorbeeld een webapplicatie, een API-server en de overgrote meerderheid van andere moderne applicaties - en als u het implementeert als een reeks services die synchroon met elkaar communiceren, en als u deze software voortdurend aan het upgraden bent, nieuwe functies toevoegt, en als u gedwongen wordt om dit systeem tijdens het wijzigingsproces in werkende staat te houden - in dit In dat geval, gefeliciteerd, u maakt moderne serversoftware. En al deze geweldige functies die hierboven zijn vermeld, blijken feitelijk van cruciaal belang voor u te zijn. De applicatie moet betrouwbaar en veilig zijn en je moet kunnen observeren wat hij doet. Dit zijn precies de vragen die service mesh helpt oplossen.
(Oké, de vorige paragraaf bevat nog steeds mijn overtuiging dat deze aanpak de moderne manier is om serversoftware te maken. Anderen geven er de voorkeur aan om monolieten, “reactieve microservices” en andere dingen te ontwikkelen die niet onder de hierboven gegeven definitie vallen. Deze mensen hebben waarschijnlijk hun eigen mening is anders dan de mijne. Op mijn beurt denk ik dat ze "fout" zijn - hoewel de service mesh in ieder geval niet erg nuttig voor hen is).
«Uniform voor de hele stapel" De functionaliteit van een servicemesh is niet alleen bedrijfskritisch. Ze zijn van toepassing op alle services in de applicatie, ongeacht in welke taal ze zijn geschreven, welk raamwerk ze gebruiken, wie ze heeft geschreven, hoe ze zijn ingezet en eventuele andere subtiliteiten van hun ontwikkeling en gebruik.
«Onafhankelijk van applicatiecode" Ten slotte biedt een servicemesh niet alleen consistente functionaliteit over de hele stapel, maar ook op een manier waarbij de applicatie niet hoeft te worden bewerkt. De fundamentele basis van de service mesh-functionaliteit, inclusief taken voor configuratie, updates, bediening, onderhoud, enz., bevindt zich volledig op platformniveau en is onafhankelijk van de applicatie. De applicatie kan veranderen zonder dat dit invloed heeft op de service mesh. Op zijn beurt kan het servicegaas veranderen zonder enige deelname van de applicatie.
Kortom: een service mesh biedt niet alleen vitale functionaliteit, maar doet dit ook op een globale, uniforme en applicatie-onafhankelijke manier. En hoewel service mesh-functionaliteit kan worden geïmplementeerd in servicecode (bijvoorbeeld als een bibliotheek die bij elke service is inbegrepen), zal deze aanpak dus niet de uniformiteit en onafhankelijkheid bieden die zo waardevol is in het geval van een service mesh.
En het enige dat u hoeft te doen, is een aantal proxy's toevoegen! Ik beloof dat we binnenkort zullen kijken naar de operationele kosten die gepaard gaan met het toevoegen van deze proxy's. Maar laten we eerst even stoppen en dit idee van onafhankelijkheid vanuit verschillende perspectieven bekijken. mensen.
Wie helpt service mesh?
Hoe ongemakkelijk het ook mag zijn, wil een technologie een belangrijk onderdeel van het ecosysteem worden, dan moet deze door mensen worden geaccepteerd. Dus wie is er geïnteresseerd in service mesh? Wie profiteert van het gebruik ervan?
Als u moderne serversoftware ontwikkelt, kunt u uw team grofweg als een groep beschouwen eigenaren van dienstendie samen bedrijfslogica ontwikkelen en implementeren, en platformeigenaren, het ontwikkelen van het interne platform waarop deze diensten opereren. In kleine organisaties kunnen dit dezelfde mensen zijn, maar naarmate het bedrijf groeit, worden deze rollen steeds duidelijker en zelfs onderverdeeld in subrollen... (Er valt hier veel te zeggen over de veranderende aard van devops, de organisatorische impact van microservices, etc.) n. Maar laten we voorlopig deze beschrijvingen nemen zoals gegeven).
Vanuit dit oogpunt zijn de platformeigenaren de duidelijke begunstigden van het servicegaas. Het uiteindelijke doel van het platformteam is immers om een intern platform te creëren waarop service-eigenaren bedrijfslogica kunnen implementeren en dit op een manier doen die ervoor zorgt dat ze zo onafhankelijk mogelijk zijn van de duistere details van de werking ervan. Een service mesh biedt niet alleen mogelijkheden die cruciaal zijn om dit doel te bereiken, maar doet dit ook op een manier die op zijn beurt geen afhankelijkheden oplegt aan service-eigenaren.
Eigenaren van diensten profiteren er ook van, zij het op een meer indirecte manier. Het doel van de service-eigenaar is om zo productief mogelijk te zijn bij het implementeren van de logica van het bedrijfsproces, en hoe minder hij zich zorgen hoeft te maken over operationele problemen, hoe beter. In plaats van zich bezig te houden met het implementeren van bijvoorbeeld beleid voor opnieuw proberen of TLS, kunnen ze zich uitsluitend richten op zakelijke doelstellingen en hopen dat het platform voor de rest zorgt. Dit is een groot voordeel voor hen.
De organisatorische waarde van een dergelijke scheiding tussen de eigenaren van platforms en diensten kan niet worden overschat. Ik denk dat zij een bijdrage levert hoofd bijdrage aan de waarde van de service mesh.
Deze les hebben we geleerd toen een vroege Linkerd-fan ons vertelde waarom ze voor service mesh kozen: omdat ze hierdoor “het praten tot een minimum konden beperken.” Hier zijn enkele details: de jongens van één groot bedrijf hebben hun platform naar Kubernetes gemigreerd. Omdat de applicatie gevoelige informatie verwerkte, wilden ze alle communicatie tussen de clusters versleutelen. De situatie werd echter gecompliceerd door de aanwezigheid van honderden diensten en honderden ontwikkelingsteams. Het vooruitzicht om met iedereen contact op te nemen en hen ervan te overtuigen TLS-ondersteuning in hun plannen op te nemen, stemde hen helemaal niet vrolijk. Na het installeren van Linkerd zijn ze overgestapt verantwoordelijkheid van ontwikkelaars (vanuit het oogpunt waarvan dit onnodige problemen waren) tot platformgames, voor wie dit een prioriteit op het hoogste niveau was. Met andere woorden, Linkerd loste voor hen niet zozeer een technisch als wel een organisatorisch probleem op.
Kortom, een service mesh is meer een oplossing, geen technische oplossing, maar socio-technisch Problemen. (Bedankt voor de introductie van deze term.)
Zal een service mesh al mijn problemen oplossen?
Ja. Ik bedoel Nee!
Als je kijkt naar de drie hierboven geschetste klassen van functies – betrouwbaarheid, veiligheid en waarneembaarheid – wordt het duidelijk dat een servicemesh geen volledige oplossing is voor al deze problemen. Hoewel Linkerd verzoeken opnieuw kan indienen (als het weet dat ze idempotent zijn), kan het geen beslissingen nemen over wat het aan de gebruiker moet teruggeven als de service permanent is mislukt. Deze beslissingen moeten door de applicatie worden genomen. Linkerd kan statistieken bijhouden van succesvolle verzoeken, maar kan niet naar de service kijken en de interne statistieken verstrekken - de applicatie moet over dergelijke tools beschikken. En hoewel Linkerd in staat is om mTLS te organiseren, vereisen volwaardige beveiligingsoplossingen veel meer.
Een subset van de functies in deze gebieden die door het servicegaas worden aangeboden, hebben betrekking op platformfuncties. Hiermee bedoel ik functies die:
- Onafhankelijk van bedrijfslogica. De manier waarop oproephistogrammen tussen Foo en Bar worden opgebouwd, is volledig onafhankelijk van waarom Foo belt Bar.
- Moeilijk correct uit te voeren. In Linkerd worden nieuwe pogingen geparametriseerd met allerlei leuke dingen, zoals budgetten voor nieuwe pogingen (budgetten opnieuw proberen), aangezien een ongekunstelde, frontale benadering van het implementeren van dergelijke zaken zeker zal leiden tot het ontstaan van een zogenaamde “lawine van verzoeken” (nieuwe poging storm) en andere problemen die kenmerkend zijn voor gedistribueerde systemen.
- Het meest effectief als het gelijkmatig wordt aangebracht. Het TLS-mechanisme heeft alleen zin als het overal wordt toegepast.
Omdat deze functies op proxyniveau (en niet op applicatieniveau) worden geïmplementeerd, biedt de servicemesh ze op het platform, geen toepassingen. Het maakt dus niet uit in welke taal de diensten zijn geschreven, welk raamwerk ze gebruiken, wie ze heeft geschreven en waarom. Proxy's opereren buiten al deze details, en de fundamentele basis van deze functionaliteit, inclusief taken voor configuratie, updates, bediening, onderhoud, enz., ligt uitsluitend op platformniveau.
Voorbeelden van service mesh-mogelijkheden
Samenvattend kan worden gezegd dat een service mesh geen complete oplossing is voor betrouwbaarheid, zichtbaarheid of veiligheid. De reikwijdte van deze gebieden vereist de deelname van service-eigenaren, Ops/SRE-teams en andere bedrijfsentiteiten. Het servicegaas biedt voor elk van deze gebieden slechts een ‘segment’ op platformniveau.
Waarom is service mesh nu populair geworden?
Je vraagt je nu waarschijnlijk af: oké, als de service mesh zo goed is, waarom zijn we dan niet tien jaar geleden begonnen met het inzetten van miljoenen proxy's in de stack?
Er is een banaal antwoord op deze vraag: tien jaar geleden bouwde iedereen monolieten en niemand had een servicegaas nodig. Dat is waar, maar naar mijn mening mist dit antwoord het punt. Zelfs tien jaar geleden werd het concept van microservices als veelbelovende manier om grootschalige systemen te bouwen breed besproken en toegepast bij bedrijven als Twitter, Facebook, Google en Netflix. De algemene opvatting – althans in de delen van de industrie waarmee ik in contact kwam – was dat microservices de ‘juiste manier’ was om grote systemen te bouwen, ook al was dat verdomd moeilijk.
Hoewel er tien jaar geleden bedrijven waren die microservices exploiteerden, plaatsten ze natuurlijk niet overal waar ze konden proxy's om een servicenetwerk te vormen. Als je echter goed kijkt, deden ze iets soortgelijks: veel van deze bedrijven vereisten het gebruik van een speciale interne bibliotheek voor netwerkcommunicatie (ook wel een dikke clientbibliotheek genoemd, dikke klantenbibliotheek).
Netflix had Hysterix, Google had Stubby, Twitter had de Finagle-bibliotheek. Finagle was bijvoorbeeld verplicht voor elke nieuwe dienst op Twitter. Het behandelde zowel de client- als de serverzijde van verbindingen, maakte herhaalde verzoeken mogelijk, ondersteunde verzoekroutering, taakverdeling en metingen. Het zorgde voor een consistente laag van betrouwbaarheid en zichtbaarheid over de hele Twitter-stack, ongeacht wat de service deed. Het werkte uiteraard alleen voor JVM-talen en was gebaseerd op een programmeermodel dat voor de hele applicatie gebruikt moest worden. De functionaliteit ervan was echter vrijwel hetzelfde als die van de service mesh. (In feite was de eerste versie van Linkerd gewoon Finagle, verpakt in proxy-vorm.)
Tien jaar geleden waren er dus niet alleen microservices, maar ook speciale proto-service-mesh-bibliotheken die dezelfde problemen oplosten die service mesh vandaag de dag oplost. De service mesh zelf bestond toen echter nog niet. Er moest nog één dienst plaatsvinden voordat ze verscheen.
En dit is waar het diepere antwoord ligt, verborgen in een andere verandering die de afgelopen tien jaar heeft plaatsgevonden: de kosten voor het inzetten van microservices zijn dramatisch gedaald. De hierboven genoemde bedrijven die tien jaar geleden microservices gebruikten – Twitter, Netflix, Facebook, Google – waren bedrijven van enorme omvang en met enorme middelen. Ze hadden niet alleen de behoefte, maar ook de mogelijkheid om grote, op microservices gebaseerde applicaties te bouwen, uit te rollen en te exploiteren. De energie en moeite die Twitter-ingenieurs steken in de overstap van een monolithische naar een microservices-aanpak is verbazingwekkend. (Om eerlijk te zijn: dat geldt ook voor het feit dat het is gelukt.) Dit soort infrastructurele manoeuvres waren toen voor kleinere bedrijven onmogelijk.
Snel vooruit naar het heden. Er zijn tegenwoordig startups waar de verhouding tussen microservices en ontwikkelaars 5:1 (of zelfs ), en bovendien gaan ze er met succes mee om! Als een startup van vijf personen gemakkelijk 5 microservices kan exploiteren, dan heeft iets de kosten van de implementatie ervan duidelijk verlaagd.
1500 microservices in Monzo; elke lijn is een voorgeschreven netwerkregel die verkeer toestaat
De dramatische verlaging van de kosten voor het exploiteren van microservices is het resultaat van één proces: groeiende populariteit van containers и orkestrators. Dit is precies het diepgaande antwoord op de vraag wat heeft bijgedragen aan de opkomst van de service mesh. Dezelfde technologie maakte zowel service meshes als microservices aantrekkelijk: Kubernetes en Docker.
Waarom? Welnu, Docker lost één groot probleem op: het verpakkingsprobleem. Door een applicatie en de (niet-netwerk) runtime-afhankelijkheden ervan in een container te verpakken, verandert Docker de applicatie in een uitwisselbare eenheid die overal kan worden gehost en uitgevoerd. Tegelijkertijd vereenvoudigt het de bediening aanzienlijk meertalig Stack: Omdat een container een atomaire uitvoeringseenheid is, maakt het voor implementatie- en operationele doeleinden niet uit wat erin zit, of het nu een JVM-, Node-, Go-, Python- of Ruby-applicatie is. Je start het gewoon en dat is alles.
Kubernetes tilt alles naar een hoger niveau. Nu er heel veel ‘dingen zijn om te draaien’ en heel veel machines om ze op te laten draaien, is er behoefte aan een tool die ze met elkaar kan correleren. In brede zin geef je Kubernetes veel containers en veel machines, en het brengt ze tegen elkaar in kaart (dit is natuurlijk een dynamisch en steeds veranderend proces: nieuwe containers bewegen zich door het systeem, machines starten en stoppen , enz. Kubernetes houdt hier echter allemaal rekening mee).
Zodra Kubernetes is geconfigureerd, verschillen de tijdskosten voor het implementeren en exploiteren van één service weinig van de kosten voor het implementeren en exploiteren van tien services (in feite zijn deze vrijwel hetzelfde voor 100 services). Voeg hieraan containers toe als een verpakkingsmechanisme dat meertalige implementatie aanmoedigt, en je hebt een groot aantal nieuwe applicaties geïmplementeerd in de vorm van microservices geschreven in verschillende talen - precies het soort omgeving waar een service mesh zo goed geschikt voor is.
We komen dus bij het antwoord op de vraag waarom het idee van een service mesh nu populair is geworden: de homogeniteit die Kubernetes biedt voor diensten is rechtstreeks van toepassing op de operationele uitdagingen waarmee een service mesh wordt geconfronteerd. Je verpakt de proxy’s in containers, geeft Kubernetes de taak om ze waar mogelijk te plakken, en voila! Het resultaat is dat u een servicegaas krijgt, terwijl alle mechanismen van de implementatie ervan worden beheerd door Kubernetes. (Althans vanuit vogelperspectief. Natuurlijk zijn er veel nuances in dit proces.)
Om het samen te vatten: de reden dat service meshes nu populair zijn geworden, en niet tien jaar geleden, is dat Kubernetes en Docker niet alleen aanzienlijk zijn toegenomen behoefte erin, waardoor de implementatie van applicaties als sets van meertalige microservices is vereenvoudigd, maar ook aanzienlijk is verminderd kosten voor de werking ervan, door mechanismen te bieden voor de inzet en ondersteuning van zijspan-proxyvloten.
Waarom wordt er zoveel gesproken over service mesh?
Waarschuwing: In deze rubriek maak ik gebruik van allerlei aannames, vermoedens, verzinsels en voorkennis.
Zoek naar 'service mesh' en je zult een hoop gerecyclede, caloriearme inhoud tegenkomen, rare projecten en een caleidoscoop van vervorming die een echokamer waardig is. Elke mooie nieuwe technologie doet dit, maar in het geval van een service mesh is het probleem bijzonder acuut. Waarom?
Nou ja, een deel ervan is mijn schuld. Ik heb hard gewerkt om Linkerd en de service mesh te promoten, elke kans die ik krijg via talloze blogposts en artikelen zoals deze. Maar ik ben niet zo krachtig. Om deze vraag echt te kunnen beantwoorden, moeten we iets over de algemene situatie praten. En het is onmogelijk om erover te praten zonder één project te noemen: is een open source service mesh ontwikkeld gezamenlijk door Google, IBM en Lyft.
(De drie bedrijven hebben zeer verschillende rollen: de betrokkenheid van Lyft lijkt alleen in naam te bestaan; zij zijn de auteurs van Envoy, maar gebruiken of nemen niet deel aan de ontwikkeling van Istio. IBM is betrokken bij en gebruikt de ontwikkeling van Istio. Google is actief betrokken bij de ontwikkeling van Istio. development , maar gebruikt het voor zover ik weet niet echt.)
Het Istio-project valt op door twee dingen. Ten eerste is er de enorme marketinginspanning die met name Google steekt in het promoten ervan. Ik schat dat de meeste mensen die vandaag de dag op de hoogte zijn van het service mesh-concept er voor het eerst over hoorden via Istio. Het tweede is hoe slecht Istio werd ontvangen. In deze kwestie ben ik uiteraard een belanghebbende partij, maar als ik probeer zo objectief mogelijk te blijven, kan ik nog steeds niet helpen , niet erg onderscheidend (hoewel niet uniek: systemd komt in me op, ...) voor een Open Source-project.
(In de praktijk lijkt Istio niet alleen problemen te hebben met complexiteit en UX, maar ook met prestaties. Bijvoorbeeld tijdens In een onderzoek van derden vonden onderzoekers situaties waarin de staartlatentie van Istio 100 keer hoger was dan die van Linkerd, evenals situaties waarin Linkerd met succes bleef functioneren terwijl Istio volledig stopte met werken.)
Afgezien van mijn theorieën over waarom dit gebeurde, geloof ik dat de overweldigende opwinding rond de service mesh wordt verklaard door de deelname van Google. Namelijk een combinatie van de volgende drie factoren:
- Google's opdringerige reclame voor Istio;
- een overeenkomstige afkeurende, kritische houding ten opzichte van het project;
- de recente snelle stijging van de populariteit van Kubernetes, waarvan de herinneringen nog vers zijn.
Samen zorgen deze factoren ervoor dat er een bedwelmende, zuurstofvrije omgeving ontstaat waarin het vermogen tot rationeel oordeel verzwakt is en alleen de vreemde variatie overblijft. .
Vanuit het perspectief van Linkerd is dit... wat ik zou omschrijven als een gemengde zegen. Ik bedoel, het is geweldig dat service mesh de mainstream is binnengedrongen op een manier die niet bestond in 2016, toen Linkerd voor het eerst begon, en het was heel moeilijk om mensen aandacht aan het project te laten besteden. Nu is er geen dergelijk probleem! Maar het slechte nieuws is dat het service mesh-landschap tegenwoordig zo verwarrend is dat het bijna onmogelijk is om te begrijpen welke projecten eigenlijk in de service mesh-categorie thuishoren (laat staan om te begrijpen welke het meest geschikt is voor een bepaalde gebruikssituatie). Dit is absoluut een dealbreaker voor iedereen (en er zijn zeker enkele gevallen waarin Istio of een ander project beter geschikt is dan Linkerd, aangezien dit laatste nog steeds geen universele oplossing is).
Aan de kant van Linkerd is onze strategie geweest om de ruis te negeren, ons te blijven concentreren op het oplossen van echte gemeenschapsproblemen en in wezen te wachten tot de hype is verdwenen. Uiteindelijk zal de hype afnemen en kunnen we rustig verder werken.
In de tussentijd zullen we allemaal nog een beetje geduld moeten hebben.
Zal een service mesh nuttig zijn voor mij, een bescheiden software-ingenieur?
De volgende vragenlijst helpt u deze vraag te beantwoorden:
Houdt u zich uitsluitend bezig met het implementeren van bedrijfslogica? In dit geval zal het servicegaas niet nuttig voor u zijn. Dat wil zeggen dat u er misschien in geïnteresseerd bent, maar idealiter zou de servicemesh niets rechtstreeks van invloed moeten zijn op iets in uw omgeving. Blijf werken aan datgene waarvoor u betaald wordt.
Ondersteun je het platform bij een bedrijf dat gebruik maakt van Kubernetes? Ja, in dit geval heb je een service mesh nodig (tenzij je K8s natuurlijk alleen gebruikt om een monoliet of batchverwerking uit te voeren - maar dan zou ik willen vragen waarom je K8s nodig hebt). Je zult waarschijnlijk eindigen met veel microservices die door verschillende mensen zijn geschreven. Ze communiceren allemaal met elkaar en zijn verwikkeld in een wirwar van runtime-afhankelijkheden, en je moet een manier vinden om met dit alles om te gaan. Door Kubernetes te gebruiken, kunt u ‘voor uzelf’ een servicemesh kiezen. Om dit te doen, moet u vertrouwd raken met hun mogelijkheden en kenmerken en de vraag beantwoorden of een van de beschikbare projecten geschikt voor u is (ik raad aan om uw onderzoek bij Linkerd te starten).
Ben jij een platformbedrijf bij een bedrijf dat GEEN Kubernetes gebruikt maar microservices? In dit geval zal een servicemesh nuttig voor u zijn, maar het gebruik ervan zal niet triviaal zijn. Natuurlijk kan je dat imiteren werk service mesh door een aantal proxy's te plaatsen, maar een belangrijk voordeel van Kubernetes is het implementatiemodel: het handmatig onderhouden van deze proxy's zal veel meer tijd, moeite en kosten vergen.
Ben jij verantwoordelijk voor het platform in een bedrijf dat met monolieten werkt? In dit geval hebt u waarschijnlijk geen servicemesh nodig. Als je werkt met monolieten (of zelfs verzamelingen monolieten) die goed gedefinieerde en zelden veranderende interactiepatronen hebben, dan heeft een service mesh je weinig te bieden. Je kunt het dus gewoon negeren en hopen dat het als een nare droom zal verdwijnen...
Conclusie
Waarschijnlijk mag service mesh nog steeds niet “de meest gehypte technologie ter wereld” worden genoemd; deze twijfelachtige eer behoort waarschijnlijk toe aan Bitcoin of AI. Waarschijnlijk staat ze in de top vijf. Maar als je de lagen van ruis doorbreekt, wordt het duidelijk dat de service mesh echte voordelen oplevert voor degenen die applicaties op Kubernetes bouwen.
Ik zou graag willen dat je Linkerd uitprobeert: installeer het op een Kubernetes-cluster (of zelfs Minikube op een laptop) , en je kunt zelf zien waar ik het over heb.
FAQ
— Zal het verdwijnen als ik het servicegaas negeer?
— Ik moet je teleurstellen: service mesh bestaat al heel lang bij ons.
- Maar ik wil service mesh NIET gebruiken!
- Nou, dat is niet nodig! Lees gewoon mijn vragenlijst hierboven om te begrijpen of u op zijn minst vertrouwd moet raken met de basisprincipes ervan.
— Is dit niet de goede oude ESB/middleware met een nieuw sausje?
— Service mesh houdt zich bezig met operationele logica, niet met semantische logica. zakelijke servicebus (). Door deze scheiding in stand te houden, kan het servicegaas hetzelfde lot vermijden.
— Hoe verschilt een servicemesh van API-gateways?
— Er zijn een miljoen artikelen over dit onderwerp. Google het gewoon.
— Envoy is een servicemesh?
- Nee, Envoy is geen servicemesh, het is een proxyserver. Het kan worden gebruikt om een servicemesh te organiseren (en nog veel meer - het is een proxy voor algemene doeleinden). Maar op zichzelf is het geen servicenetwerk.
— Network Service Mesh is een servicemesh?
- Nee. Ondanks de naam is dit geen servicenetwerk (wat vind je van marketingwonderen?).
— Zal een servicemesh helpen met mijn op berichtenwachtrijen gebaseerde reactieve asynchrone systeem?
- Nee, service mesh zal u niet helpen.
— Welk servicegaas moet ik gebruiken?
- , geen hersens.
- Het artikel is waardeloos! / De auteur is welkom!
— Deel de link ernaar met al je vrienden, zodat zij het kunnen zien!
Dankbetuigingen
Zoals je misschien al uit de titel hebt geraden, is dit artikel geïnspireerd op de fantastische verhandeling van Jay Kreps "" Ik ontmoette Jay tien jaar geleden toen ik hem interviewde op Linked In en sindsdien is hij een inspiratie voor mij.
Hoewel ik mezelf graag een "Linkerd-ontwikkelaar" noem, is de realiteit dat ik meer een onderhouder ben van het README.md-bestand van een project. Er wordt vandaag aan Linkerd gewerkt , , mensen, en dit project zou niet tot stand zijn gekomen zonder de deelname van een geweldige gemeenschap van bijdragers en gebruikers.
En tot slot een speciale dank aan de maker van Linkerd, (primus inter pares), die zich vele jaren geleden samen met mij halsoverkop in al dat gedoe rond service mesh heeft gestort.
PS van vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «";
- «.
Bron: www.habr.com