Hallo weer!.. Aan de vooravond van de start van de cursus We hebben nog een nuttige vertaling voorbereid.
Een service mesh is een configureerbare infrastructuurlaag met lage latentie die nodig is om grote volumes netwerkgebaseerde inter-procescommunicatie tussen application programming interfaces (API's) te verwerken. Service Mesh maakt snelle, betrouwbare en veilige communicatie mogelijk tussen gecontaineriseerde en vaak kortstondige applicatie-infrastructuurdiensten. Service Mesh biedt mogelijkheden zoals servicedetectie, taakverdeling, encryptie, transparantie, traceerbaarheid, authenticatie en autorisatie, en ondersteuning voor automatische uitschakelpatronen (stroomonderbreker).
Een servicemesh wordt doorgaans geïmplementeerd door elke service-instantie te voorzien van een proxy-instantie, genaamd Zijspan. Zijspan de communicatie tussen services afhandelen, beveiligingsproblemen monitoren en oplossen, dat wil zeggen alles wat uit individuele services kan worden geabstraheerd. Op deze manier kunnen ontwikkelaars applicatiecode in services schrijven, onderhouden en aanbieden, en kunnen systeembeheerders met de Service Mesh werken en de applicatie uitvoeren.
Istio van Google, IBM en Lyft is momenteel de bekendste service mesh-architectuur. En Kubernetes, oorspronkelijk ontwikkeld bij Google, is nu het enige containerorkestratieframework dat door Istio wordt ondersteund. Leveranciers proberen commercieel ondersteunde versies van Istio te maken. Het zal interessant zijn om te zien welke nieuwe dingen ze kunnen toevoegen aan het open source-project.
Istio is echter niet de enige optie, aangezien er andere Service Mesh-implementaties worden ontwikkeld. Patroon sidecar proxy is de meest populaire implementatie, zoals kan worden beoordeeld aan de hand van de projecten Buoyant, HashiCorp, Solo.io en anderen. Er zijn ook alternatieve architecturen: de Netflix-technologietoolkit is een van de benaderingen waarbij de Service Mesh-functionaliteit wordt geïmplementeerd via de Ribbon-, Hysterix-, Eureka-, Archaius-bibliotheken en platforms zoals Azure Service Fabric.
Service Mesh heeft ook zijn eigen terminologie voor servicecomponenten en -functies:
- Containerorkestratieframework. Naarmate er steeds meer containers aan de applicatie-infrastructuur worden toegevoegd, is er behoefte aan een afzonderlijk hulpmiddel voor het monitoren en beheren van containers: een containerorkestratieframework. Kubernetes heeft deze niche stevig bezet, zozeer zelfs dat zelfs zijn belangrijkste concurrenten Docker Swarm en Mesosphere DC/OS integratie met Kubernetes als alternatief aanbieden.
- Services en instanties (Kubernetes-pods). Een instance is één actieve kopie van een microservice. Soms is één instance één container. In Kubernetes bestaat een instantie uit een kleine groep onafhankelijke containers, een zogenaamde pod. Clients hebben zelden rechtstreeks toegang tot een instance of pod; vaker hebben zij toegang tot een service, die bestaat uit een reeks identieke, schaalbare en fouttolerante instances of pods (replica's).
- Zijspan-proxy. Sidecar Proxy werkt met één exemplaar of pod. Het doel van Sidecar Proxy is om verkeer dat afkomstig is van de container waarmee het werkt, te routeren of te proxyen en verkeer terug te sturen. Sidecar werkt samen met andere Sidecar-proxy's en wordt beheerd door een orkestratieframework. Veel Service Mesh-implementaties gebruiken Sidecar Proxy om al het verkeer in en uit een instance of pod te onderscheppen en te beheren.
- Servicedetectie. Wanneer een exemplaar met een andere service moet communiceren, moet het een gezond en beschikbaar exemplaar van de andere service vinden (ontdekken). Normaal gesproken voert het exemplaar DNS-zoekopdrachten uit. Het containerorkestratieframework houdt een lijst bij van instanties die klaar zijn om verzoeken te ontvangen en biedt een interface voor DNS-query's.
- Loadbalancing. De meeste containerorkestratieframeworks bieden taakverdeling op laag 4 (transport). Service Mesh implementeert complexere taakverdeling op laag 7 (applicatieniveau), rijk aan algoritmen en effectiever in het beheren van verkeer. Instellingen voor taakverdeling kunnen worden gewijzigd met behulp van de API, zodat u blauw-groene of canarische implementaties kunt orkestreren.
- Versleuteling. Service Mesh kan verzoeken en antwoorden versleutelen en ontsleutelen, waardoor deze last van diensten wordt weggenomen. Service Mesh kan ook de prestaties verbeteren door bestaande persistente verbindingen prioriteit te geven of te hergebruiken, waardoor de noodzaak voor dure berekeningen om nieuwe verbindingen te creëren wordt verminderd. De meest voorkomende implementatie van verkeersencryptie is wederzijdse TLS (mTLS), waar een publieke sleutelinfrastructuur (PKI) certificaten en sleutels genereert en distribueert voor gebruik door Sidecar Proxy.
- Authenticatie en authorisatie. De Service Mesh kan verzoeken van buiten of binnen de applicatie autoriseren en authenticeren, waarbij alleen gevalideerde verzoeken naar instances worden verzonden.
- Ondersteuning voor automatische uitschakelingspatronen. Service Mesh-ondersteuning , dat ongezonde exemplaren isoleert en ze vervolgens indien nodig geleidelijk terugstuurt naar de pool met gezonde exemplaren.
Het deel van een Service Mesh-applicatie dat het netwerkverkeer tussen instances beheert, wordt aangeroepen Gegevensvlak. Creëer en implementeer een configuratie die het gedrag regelt Gegevensvlak, wordt uitgevoerd met behulp van een afzonderlijke Controle vliegtuig. Controle vliegtuig omvat doorgaans of is ontworpen om verbinding te maken met een API, CLI of GUI om de applicatie te besturen.
Het Control Plane in de Service Mesh verdeelt de configuratie tussen de Sidecar Proxy en het Data Plane.
Service Mesh-architectuur wordt vaak gebruikt om complexe operationele problemen op te lossen met behulp van containers en microservices. Pioniers in het veld zijn bedrijven zoals Lyft, Netflix en Twitter, die stabiele diensten leveren aan miljoenen gebruikers over de hele wereld. (). Voor minder veeleisende toepassingen zullen eenvoudigere architecturen waarschijnlijk volstaan.
Het is onwaarschijnlijk dat de Service Mesh-architectuur ooit het antwoord zal zijn op alle problemen met de werking en levering van applicaties. Architecten en ontwikkelaars hebben een enorm arsenaal aan gereedschappen, en slechts één daarvan is een hamer, die, naast vele taken, slechts één moet oplossen: het hameren van spijkers. , bevat bijvoorbeeld verschillende modellen die een continuüm van benaderingen bieden voor het oplossen van problemen met behulp van microservices.
De elementen die samenkomen in een Service Mesh-architectuur, zoals NGINX, containers, Kubernetes en microservices als architecturale benadering, kunnen even productief zijn in niet-Service Mesh-implementaties. Istio is bijvoorbeeld ontworpen als een complete service mesh-architectuur, maar de modulariteit betekent dat ontwikkelaars alleen de technologiecomponenten kunnen selecteren en implementeren die ze nodig hebben. Met dit in gedachten is het belangrijk om een duidelijk begrip van het Service Mesh-concept te ontwikkelen, zelfs als u niet zeker weet of u het ooit volledig in uw applicatie zult kunnen implementeren.
Bron: www.habr.com