Service Mesh is een bekend architectonisch patroon voor het integreren van microservices en het migreren naar cloudinfrastructuur. Tegenwoordig is het in de cloudcontainerwereld vrij moeilijk om zonder te doen. Er zijn al verschillende open-source service mesh-implementaties op de markt beschikbaar, maar hun functionaliteit, betrouwbaarheid en veiligheid zijn niet altijd voldoende, vooral als het gaat om de eisen van grote financiële bedrijven in het hele land. Daarom hebben we bij Sbertech besloten om Service Mesh aan te passen en willen we praten over wat er cool is aan Service Mesh, wat niet zo cool is, en wat we eraan gaan doen.
De populariteit van het Service Mesh-patroon groeit met de populariteit van cloudtechnologieën. Het is een speciale infrastructuurlaag die de interactie tussen verschillende netwerkdiensten vereenvoudigt. Moderne cloudapplicaties bestaan uit honderden of zelfs duizenden van dergelijke diensten, waarvan elk duizenden exemplaren kan hebben.
De interactie tussen en het beheer van deze diensten is een kerntaak van de Service Mesh. In feite is dit een netwerkmodel van vele proxy's, centraal beheerd en een reeks zeer nuttige functies uitvoeren.
Op proxyniveau (datavlak):
- Toewijzen en distribueren van routerings- en verkeersbalanceringsbeleid
- Distributie van sleutels, certificaten, tokens
- Verzameling van telemetrie, genereren van monitoringstatistieken
- Integratie met beveiligings- en monitoringinfrastructuur
Op het niveau van het besturingsvlak:
- Het toepassen van routing- en verkeersbalanceringsbeleid
- Het beheren van nieuwe pogingen en time-outs, het detecteren van ‘dode’ knooppunten (circuitonderbreking), het beheren van injectiefouten en het garanderen van de veerkracht van de service via andere mechanismen
- Oproepverificatie/autorisatie
- Metrieken laten vallen (waarneembaarheid)
Het bereik van gebruikers die geïnteresseerd zijn in de ontwikkeling van deze technologie is zeer breed: van kleine startups tot grote internetbedrijven, bijvoorbeeld PayPal.
Waarom is Service Mesh nodig in het bedrijfsleven?
Er zijn veel duidelijke voordelen verbonden aan het gebruik van een Service Mesh. Allereerst is het gewoon handig voor ontwikkelaars: voor het schrijven van code er verschijnt een technologieplatform, wat de integratie in de cloudinfrastructuur aanzienlijk vereenvoudigt vanwege het feit dat de transportlaag volledig geïsoleerd is van applicatielogica.
Bovendien Service Mesh vereenvoudigt de relatie tussen leveranciers en consumenten. Tegenwoordig is het voor API-aanbieders en consumenten veel gemakkelijker om zelf overeenstemming te bereiken over interfaces en contracten, zonder tussenkomst van een speciale integratie-intermediair en arbiter: de enterprise service bus. Deze aanpak heeft een aanzienlijke invloed op twee indicatoren. De snelheid waarmee nieuwe functionaliteit op de markt wordt gebracht (time-to-market) neemt toe, maar tegelijkertijd nemen de kosten van de oplossing toe, omdat de integratie onafhankelijk moet gebeuren. Het gebruik van Service Mesh door ontwikkelteams voor zakelijke functionaliteit helpt hier een evenwicht te bewaren. Als gevolg hiervan kunnen API-providers zich uitsluitend concentreren op de applicatiecomponent van hun service en deze eenvoudigweg publiceren in de Service Mesh - de API zal onmiddellijk beschikbaar zijn voor alle klanten, en de kwaliteit van de integratie zal klaar zijn voor productie en vereist geen enkele regel extra code.
Het volgende voordeel is dat de ontwikkelaar, die Service Mesh gebruikt, richt zich uitsluitend op zakelijke functionaliteit — op het product en niet op de technologische component van de dienst. Zo hoeft u er bijvoorbeeld niet meer aan te denken dat in een situatie waarbij een dienst over het netwerk wordt aangeroepen, er ergens een verbindingsfout kan optreden. Bovendien helpt Service Mesh het verkeer tussen kopieën van dezelfde service te verdelen: als een van de kopieën ‘sterft’, schakelt het systeem al het verkeer over naar de resterende live kopieën.
Servicenetwerk - dit is een goede basis voor het maken van gedistribueerde applicaties, dat voor de klant de details verbergt van het aanbieden van oproepen naar zijn diensten, zowel intern als extern. Alle applicaties die Service Mesh gebruiken, zijn op transportniveau geïsoleerd van het netwerk en van elkaar: er is geen communicatie tussen de applicaties. In dit geval krijgt de ontwikkelaar volledige controle over zijn diensten.
het zou genoteerd moeten worden dat Het updaten van gedistribueerde applicaties in een service mesh-omgeving wordt eenvoudiger. Bijvoorbeeld een blauw/groene implementatie, waarbij twee applicatieomgevingen beschikbaar zijn voor installatie, waarvan er één niet is bijgewerkt en in de standby-modus staat. Terugkeren naar de vorige versie in het geval van een mislukte release wordt uitgevoerd door een speciale router, waarvan Service Mesh goed opgewassen is. Om de nieuwe versie te testen, kunt u gebruiken kanarie vrijlating — schakel slechts 10% van het verkeer of de verzoeken van een pilotgroep klanten over naar de nieuwe versie. Het belangrijkste verkeer gaat naar de oude versie, er gaat niets kapot.
Ook Service Mesh geeft ons realtime SLA-controle. Het gedistribueerde proxysysteem zal niet toestaan dat de service mislukt wanneer een van de clients het toegewezen quotum overschrijdt. Als de API-doorvoer beperkt is, kan niemand deze overweldigen met een groot aantal transacties: de Service Mesh staat voor de dienst en laat geen onnodig verkeer toe. Het zal eenvoudigweg terugvechten in de integratielaag, en de diensten zelf zullen blijven werken zonder het te merken.
Als een bedrijf de kosten voor de ontwikkeling van integratieoplossingen wil verlagen, helpt Service Mesh ook: U kunt vanuit commerciële producten overschakelen naar de open-sourceversie. Onze Enterprise Service Mesh is gebaseerd op de open-source versie van Service Mesh.
Een ander voordeel - beschikbaarheid van één volwaardig pakket integratiediensten. Omdat alle integratie via deze middleware wordt opgebouwd, kunnen we al het integratieverkeer en de verbindingen tussen applicaties die de zakelijke kern van het bedrijf vormen, beheren. Het is zeer comfortabel.
En tot slot Service Mesh stimuleert een bedrijf om over te stappen naar een dynamische infrastructuur. Nu kijken velen naar containerisatie. Een monoliet opdelen in microservices en dit allemaal prachtig implementeren: het onderwerp is in opkomst. Maar als je een systeem dat al jaren in productie is, probeert over te zetten naar een nieuw platform, stuit je meteen op een aantal problemen: het allemaal in containers stoppen en op het platform inzetten is niet eenvoudig. En de implementatie, synchronisatie en interactie van deze gedistribueerde componenten is een ander zeer complex onderwerp. Hoe zullen ze met elkaar communiceren? Zullen er trapsgewijze mislukkingen optreden? Met Service Mesh kunt u een aantal van deze problemen oplossen en de migratie van de oude architectuur naar de nieuwe vergemakkelijken, omdat u de logica voor netwerkuitwisseling kunt vergeten.
Waarom heb je Service Mesh-aanpassing nodig?
In ons bedrijf bestaan honderden systemen en modules naast elkaar, en de runtime is erg belastend. Een eenvoudig patroon waarbij het ene systeem het andere belt en een antwoord ontvangt, is dus niet voldoende, omdat we in de productie meer willen. Wat heb je nog meer nodig van een enterprise service mesh?
Dienst voor gebeurtenisverwerking
Laten we ons voorstellen dat we realtime gebeurtenisverwerking moeten maken: een systeem dat de acties van de klant in realtime analyseert en hem onmiddellijk een relevant aanbod kan doen. Gebruik om vergelijkbare functionaliteit te implementeren architectonisch patroon genaamd event-driven architectuur (EDA). Geen van de huidige Service Meshes ondersteunt dergelijke patronen van nature, maar dit is erg belangrijk, vooral voor een bank!
Het is nogal vreemd dat Remote Procedure Call (RPC) door alle versies van Service Mesh wordt ondersteund, maar dat ze niet vriendelijk zijn tegen EDA. Omdat Service Mesh een soort moderne gedistribueerde integratie is, en EDA een zeer relevant architectonisch patroon is waarmee je unieke dingen kunt doen op het gebied van klantervaring.
Onze Enterprise Service Mesh zou dit probleem moeten oplossen. Daarnaast willen we daarin de implementatie zien van gegarandeerde levering, streaming en complexe gebeurtenisverwerking met behulp van een verscheidenheid aan filters en sjablonen.
Dienst voor bestandsoverdracht
Naast EDA zou het fijn zijn om bestanden te kunnen overbrengen: op Enterprise-schaal is vaak alleen bestandsintegratie mogelijk. In het bijzonder wordt gebruik gemaakt van het ETL-architectuurpatroon (Extract, Transform, Load). Daarin wisselt iedereen in de regel uitsluitend bestanden uit: er wordt gebruik gemaakt van big data, wat onpraktisch is om afzonderlijke verzoeken in te dienen. De mogelijkheid om bestandsoverdrachten native te ondersteunen in de Enterprise Service Mesh geeft u de flexibiliteit die uw bedrijf nodig heeft.
Orkestratie dienst
Grote organisaties hebben bijna altijd verschillende teams die verschillende producten maken. Bij een bank werken sommige teams bijvoorbeeld met deposito's, terwijl andere met leningproducten werken, en er zijn nogal wat van dergelijke gevallen. Dit zijn verschillende mensen, verschillende teams die hun producten maken, hun API’s ontwikkelen en deze aan anderen verstrekken. En heel vaak is het nodig om deze services samen te stellen, en om complexe logica te implementeren voor het sequentieel aanroepen van een reeks API's. Om dit probleem op te lossen heb je een oplossing in de integratielaag nodig die al deze samengestelde logica vereenvoudigt (het aanroepen van verschillende API's, het beschrijven van de aanvraagroute, enz.). Dit is de orkestratieservice in de Enterprise Service Mesh.
AI en ML
Wanneer microservices via één enkele integratielaag communiceren, weet de Service Mesh uiteraard alles over de oproepen van elke service. We verzamelen telemetrie: wie heeft wie gebeld, wanneer, hoe lang, hoe vaak, enzovoort. Als er honderdduizenden van deze diensten zijn en miljarden oproepen, dan stapelt dit zich allemaal op en vormt het Big Data. Deze gegevens kunnen worden geanalyseerd met behulp van AI, machinaal leren, enz., en vervolgens kunnen enkele nuttige dingen worden gedaan op basis van de analyseresultaten. Het zou passend zijn om de controle over al dit netwerkverkeer en de in de Service Mesh geïntegreerde applicatieoproepen op zijn minst gedeeltelijk over te dragen aan kunstmatige intelligentie.
API-gatewayservice
Normaal gesproken heeft een Service Mesh proxy's en services die met elkaar communiceren binnen een vertrouwde omgeving. Maar er zijn ook externe tegenpartijen. De eisen voor API’s die aan deze groep consumenten worden blootgesteld, zijn veel strenger. We verdelen deze taak in twee hoofdonderdelen.
- veiligheid. Problemen met betrekking tot ddos, kwetsbaarheid van protocollen, applicaties, besturingssystemen, enzovoort.
- Schubben. Wanneer het aantal API's dat aan klanten moet worden aangeboden in de duizenden of zelfs honderdduizenden loopt, is er behoefte aan een soort beheertool voor deze set API's. Je moet de API voortdurend monitoren: of ze werken of niet, wat hun status is, welk verkeer er stroomt, welke statistieken, enz. Een API-gateway moet deze taak afhandelen en tegelijkertijd het hele proces beheersbaar en veilig maken. Dankzij dit onderdeel leert Enterprise Service Mesh zowel interne als externe API’s eenvoudig te publiceren.
Ondersteuningsservice voor specifieke protocollen en dataformaten (AS-gateway)
Momenteel kunnen de meeste Service Mesh-oplossingen alleen native werken met HTTP- en HTTP2-verkeer of in een beperkte modus op TCP/IP-niveau. De Enterprise Service Mesh is in opkomst met vele andere zeer specifieke protocollen voor gegevensoverdracht. Sommige systemen kunnen berichtenmakelaars gebruiken, andere zijn geïntegreerd op databaseniveau. Als het bedrijf over SAP beschikt, kan het ook een eigen integratiesysteem gebruiken. Bovendien werkt dit allemaal en is het een belangrijk onderdeel van de bedrijfsvoering.
Je kunt niet zomaar zeggen: “Laten we de erfenis achter ons laten en nieuwe systemen maken die Service Mesh kunnen gebruiken.” Om alle oude systemen met de nieuwe te verbinden (op een microservice-architectuur), zullen systemen die Service Mesh kunnen gebruiken een soort adapter, tussenpersoon, gateway nodig hebben. Mee eens, het zou leuk zijn als het samen met de service in een doos zou komen. De AC-gateway ondersteunt elke integratieoptie. Stel je voor: je installeert gewoon Enterprise Service Mesh en het is klaar voor interactie met alle protocollen die je nodig hebt. Deze aanpak is voor ons heel belangrijk.
Dit is ongeveer hoe wij ons de bedrijfsversie van Service Mesh (Enterprise Service Mesh) voorstellen. Het beschreven maatwerk lost de meeste problemen op die zich voordoen bij het gebruik van kant-en-klare open-sourceversies van het integratieplatform. De Service Mesh-architectuur, die pas een paar jaar geleden werd geïntroduceerd, blijft zich ontwikkelen en we zijn blij dat we kunnen bijdragen aan de ontwikkeling ervan. Wij hopen dat onze ervaring nuttig voor u zal zijn.
Bron: www.habr.com