Service Mesh is een bekende architecturale patroon voor de integratie van microservices en de overgang naar cloudinfrastructuur. Tegenwoordig is het moeilijk om zonder dit te functioneren in de wereld van cloudcontainers. Op de markt zijn er al verschillende open-source implementaties van Service Mesh beschikbaar, maar hun functionaliteit, betrouwbaarheid en veiligheid zijn vaak niet voldoende, vooral als het gaat om de eisen van grote financiƫle bedrijven van nationale schaal. Daarom hebben wij bij Sbertech besloten om Service Mesh te customizen en willen we vertellen over wat goed is aan Service Mesh, wat minder goed is en wat we hiermee van plan zijn.
De populariteit van het Service Mesh-patroon neemt toe met de groei van cloudtechnologieƫn. Het is een speciale infrastructu laag die de interactie tussen verschillende netwerkservices vereenvoudigt. Moderne cloudapplicaties bestaan uit honderden en zelfs duizenden van dergelijke services, waarvan elke service duizenden kopieƫn kan hebben.
De interactie tussen deze services en het beheer ervan is de kernopdracht van Service Mesh. In feite is het een netwerkmodel bestaande uit meerdere proxies, centraal beheerd en dat een reeks zeer nuttige functies uitvoert.
Op het niveau van de proxy (data plane):
- Toepassing en verspreiding van routing- en traffic-balanceringsbeleid
- Verspreiding van sleutels, certificaten, tokens
- Verzamelen van telemetrie, genereren van monitoring-metrics
- Integratie met beveiligings- en monitoringsinfrastructuur
Op het niveau van het controlepaneel (control plane):
- Toepassing van routing- en traffic-balanceringsbeleid
- Beheer van herhalingen en time-outs, identificatie van ādodeā knooppunten (circuit breaking), beheer van foutscenario's (injecting faults) en waarborgen van de veerkracht (resilience) van services via andere mechanismen
- Authenticatie/autorisatie van oproepen
- Afval van metrics (observability)
De groep gebruikers die geĆÆnteresseerd zijn in de ontwikkeling van deze technologie is zeer breed - van kleine startups tot grote internetcorpora, zoals PayPal.
Wat is de functie van Service Mesh in de bedrijfssector
Het gebruik van Service Mesh biedt tal van duidelijke voordelen. Allereerst is het eenvoudig voor ontwikkelaars: voor het schrijven van code ontstaat er een technologische platform, die de integratie in de cloudinfrastructuur aanzienlijk vereenvoudigt omdat de transportlaag volledig is geĆÆsoleerd van de applicatielogica.
Daarnaast Service Mesh vereenvoudigt de relaties tussen leveranciers en consumenten. Vandaag de dag is het voor API-leveranciers en -consumenten veel makkelijker om zelfstandig afspraken te maken over interfaces en contracten, zonder een speciale integratie-intermediair of arbiter - de corporate service bus - in te schakelen. 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 de kosten van de oplossing stijgen ook, omdat de integratie zelfstandig moet worden uitgevoerd. Het gebruik van Service Mesh door ontwikkelteams voor zakelijke functionaliteit stelt hen in staat om een balans te behouden. Uiteindelijk kunnen API-leveranciers zich uitsluitend richten op de applicatielogica van hun service en deze eenvoudig in Service Mesh publiceren - de API wordt onmiddellijk beschikbaar voor alle klanten en de kwaliteit van de integratie is productieklare en vereist geen enkele regel extra code.
Een ander voordeel is dat de ontwikkelaar, door gebruik te maken van Service Mesh, zich uitsluitend richt op de zakelijke functionaliteit ā de productgerichte en niet de technische kant van zijn service. Bijvoorbeeld, het is niet langer nodig om zich zorgen te maken over de mogelijkheid van een verbinding die verbroken wordt wanneer de service via het netwerk wordt aangeroepen. Bovendien helpt Service Mesh het verkeer te balanceren tussen kopieĆ«n van dezelfde service: als een van de kopieĆ«n 'is uitgevallen', schakelt het systeem al het verkeer over naar de resterende actieve kopieĆ«n.
Service Mesh ā dit is een goede basis voor het creĆ«ren van gedistribueerde applicaties, die de klant de details van de aanroepen van zijn services zowel van binnen als van buiten verbergt. Alle applicaties die Service Mesh gebruiken, zijn op transportniveau geĆÆsoleerd van zowel het netwerk als van elkaar: er is geen communicatie tussen hen. Dit geeft de ontwikkelaar volledige controle over zijn services.
Het moet worden benadrukt dat het vernieuwen van gedistribueerde applicaties in een omgeving waar Service Mesh wordt gebruikt, eenvoudiger wordt. Bijvoorbeeld, blue/green-implementatie waarbij er twee omgevingen voor de applicatie beschikbaar zijn, waarvan er Ć©Ć©n niet wordt bijgewerkt en in afwachting is. Terugdraaien naar een vorige versie in het geval van een mislukte release gebeurt via een speciale router, waarvan de rol uitstekend wordt vervuld door de Service Mesh.. Voor het testen van de nieuwe versie kan ook worden gebruikt canary release ā switch alleen 10% van het verkeer of aanvragen van een pilotgroep klanten naar de nieuwe versie. Het grootste deel van het verkeer gaat naar de oude versie, er gaat niets mis.
Ook Service Mesh biedt ons realtime controle over SLA's. Het systeem van gedistribueerde proxies laat de service niet falen wanneer een van de klanten zijn toegewezen quotum overschrijdt. Als de bandbreedte via de API beperkt is, kan niemand deze overbelasten met een groot aantal transacties: Service Mesh staat voor de service en laat geen overtollig verkeer door. Het zal eenvoudig worden afgehandeld in de integratielaag, terwijl de services blijven draaien zonder dat ze het merken.
Als een bedrijf de kosten voor de ontwikkeling van integratie-oplossingen wil verlagen, helpt Service Mesh ook: je kunt overstappen van commerciƫle producten naar de open-source versie. Onze Enterprise Service Mesh is gebaseerd op de open-source versie van Service Mesh.
Een ander voordeel is het beschikbaar zijn van een complete set integratiediensten. Aangezien alle integratie via deze tussenlaag plaatsvindt, kunnen we al het integratietraject en de verbindingen tussen applicaties die het bedrijfscentrum vormen, beheren. Dit is erg handig.
En tot slot Service Mesh stimuleert een bedrijf om over te stappen naar een dynamische infrastructuur. Momenteel kijkt velen richting containerisatie. Het splitsen van monolithen in microservices, dit allemaal mooi implementeren ā het onderwerp is in opkomst. Maar wanneer je probeert een systeem dat al vele jaren in productie is op nieuwe sporen te brengen, kom je onmiddellijk een aantal problemen tegen: alles in containers proppen en op een platform implementeren is niet eenvoudig. En de implementatie, synchronisatie en interactie van deze gedistribueerde componenten is een nog complexer onderwerp. Hoe zullen ze met elkaar communiceren? Zullen er cascade-failures optreden? Service Mesh helpt een deel van deze problemen op te lossen en vergemakkelijkt de migratie van de oude architectuur naar de nieuwe door de netwerklatentie te verwaarlozen.
Waarom is aanpassing van Service Mesh nodig?
In ons bedrijf coƫxisteren honderden systemen en modules, en de runtime is zwaar belast. Een eenvoudig patroon, waarbij het ene systeem het andere aanroept en een antwoord ontvangt, is niet voldoende omdat we in productie meer willen. Wat is er nog meer nodig van een enterprise Service Mesh?
Evenementverwerkingsservice
Stel je voor dat we real-time event processing nodig hebben - een systeem dat de acties van klanten in real time analyseert en hen direct relevante voorstellen kan doen. Om dergelijke functionaliteit te realiseren, wordt gebruik gemaakt van een architectonisch patroon dat event-driven architecture (EDA) wordt genoemd.Geen van de huidige Service Mesh's ondersteunt dergelijke patronen native, en dat is heel belangrijk, vooral voor banken!
Het is behoorlijk vreemd dat 'Remote Procedure Call' (RPC) door alle versies van Service Mesh wordt ondersteund, maar ze niet compatibel zijn met EDA. Omdat Service Mesh een soort moderne gedistribueerde integratie is, en EDA een zeer actueel architectonisch patroon is dat unieke mogelijkheden biedt in termen van klantervaring.
Onze Enterprise Service Mesh moet dit probleem oplossen. Bovendien willen we dat het gegarandeerde leveringen, streaming en complexe evenementverwerking implementeert met diverse filters en sjablonen.
Bestandsoverdrachtsservice
Naast EDA zou het ook fijn zijn om bestanden te kunnen overdragen: op Enterprise-niveau is vaak alleen bestandintegratie mogelijk. In het bijzonder wordt het architectonische patroon ETL (Extract, Transform, Load) gebruikt. In dit patroon wisselen alle partijen meestal uitsluitend bestanden uit: er worden grote gegevens gebruikt die niet praktisch afzonderlijk kunnen worden verzonden. De mogelijkheid van native ondersteuning voor bestandoverdracht in een Enterprise Service Mesh biedt de noodzakelijke flexibiliteit voor bedrijven.
Orkestratieservice
In grote organisaties zijn er bijna altijd verschillende teams die verschillende producten ontwikkelen. Bijvoorbeeld, in een bank werken sommige teams met deposito's, terwijl andere teams zich bezighouden met kredietproducten, en er zijn veel van deze gevallen. Dit zijn verschillende mensen, verschillende teams, die hun eigen producten maken, hun eigen API's ontwikkelen en deze aan anderen aanbieden. En vaak is er behoefte aan de compositie van deze diensten, evenals de implementatie van complexe logica voor de opeenvolgende aanroep van een set API's. Om dit probleem op te lossen is een oplossing in de integratielaag nodig, die het mogelijk maakt om al deze compositielogica te vereenvoudigen (het aanroepen van meerdere API's, het beschrijven van de route van verzoeken, enzovoort). Dit is de orchestration service in de Enterprise Service Mesh.
AI en ML
Wanneer microservices communiceren via een enkele integratielaag, weet de Service Mesh natuurlijk alles over de aanroepen van elke service. We verzamelen telemetrie: wie wie aanriep, wanneer, hoe lang, hoeveel keer, enzovoort. Wanneer er honderdduizenden van deze services zijn en miljarden aanroepen, stapelt dit zich op en vormt het Big Data. Deze gegevens kunnen worden geanalyseerd met behulp van AI, machine learning, enzovoort, en op basis van de analysemiddelen kunnen nuttige dingen worden gedaan. Het zou passend zijn om de kunstmatige intelligentie tenminste deels de controle over al dit netwerkverkeer en de aanroepen van toepassingen, geĆÆntegreerd in de Service Mesh, te geven.
API Gateway Service
Over het algemeen zijn er in de Service Mesh proxies en services die met elkaar communiceren binnen een vertrouwd perimeter. Maar er zijn ook externe tegenpartijen. De vereisten voor de API's die aan deze groep consumenten worden geleverd, zijn veel serieuzer. We delen deze taak in twee hoofdzaken.
- Beveiliging. Vragen gerelateerd aan DDoS, kwetsbaarheden van protocollen, toepassingen, besturingssystemen, enzovoort.
- Schaal. Wanneer het aantal API's dat aan klanten moet worden geleverd op duizenden of zelfs honderdduizenden loopt, ontstaat de noodzaak voor een middel om deze set API's te beheren. Er moet continu toezicht worden gehouden op de API's: functioneren ze of niet, in welke status, welk verkeer er is, welke statistieken, enzovoort. De API Gateway moet deze taak aan kunnen, waardoor het hele proces beheersbaar en veilig wordt. Dankzij dit onderdeel leert de Enterprise Service Mesh om zowel interne als externe API's zonder onnodige complicaties te publiceren.
Een dienst voor ondersteuning van specifieke protocollen en gegevensformaten (AS-gateway)
Momenteel kunnen de meeste Service Mesh-oplossingen native alleen met HTTP- en HTTP2-verkeer werken of in een beperkte modus op TCP/IP-niveau. De Enterprise Service Mesh heeft veel andere zeer specifieke gegevensoverdrachtsprotocollen. Sommige systemen kunnen berichtenbrokers gebruiken, terwijl andere zijn geĆÆntegreerd op database-niveau. Als er een SAP-systeem in het bedrijf is, kan dit ook zijn eigen integratiesysteem gebruiken. En dit alles werkt en is een belangrijk onderdeel van het bedrijf.
Je kunt niet gewoon zeggen: 'Laten we afstappen van legacy en nieuwe systemen maken die Service Mesh kunnen gebruiken'. Om alle oude systemen met de nieuwe (op microservices gebaseerde architectuur) te laten samenwerken, hebben systemen die Service Mesh kunnen gebruiken een soort adapter, tussenpersoon of gateway nodig. Het zou mooi zijn als dit geleverd zou worden met de dienst. De AS-gateway kan elke integratieoptie ondersteunen. Stel je voor, je installeert de Enterprise Service Mesh gewoon en deze is al klaar om samen te werken met alle protocollen die je nodig hebt. Deze aanpak is voor ons zeer belangrijk.
Zo stellen we ons de bedrijfsversie van Service Mesh (Enterprise Service Mesh) voor. De beschreven aanpassing lost de meeste problemen op die zich voordoen bij het proberen gebruik te maken van kant-en-klare open-source versies van het integratieplatform. De Service Mesh-architectuur, die pas een paar jaar geleden is verschenen, blijft zich ontwikkelen en we zijn blij dat we een bijdrage kunnen leveren aan deze ontwikkeling. We hopen dat onze ervaring nuttig voor je zal zijn.
Bron: habr.com
