En weer hallo!.. In de aanloop naar de start van de cursus hebben we nog een nuttige vertaling voorbereid.
Service Mesh is een configureerbaar infrastructuurniveau met lage latentie dat nodig is voor het verwerken van een grote hoeveelheid netwerk interprocess communicatie tussen de applicatie programmeerinterfaces (API's). Service Mesh zorgt voor snelle, betrouwbare en veilige communicatie tussen containerized en vaak ephemerale applicatieservices. Service Mesh biedt mogelijkheden zoals servicetDiscovery, load balancing, encryptie, transparantie, tracing, authenticatie en autorisatie, evenals ondersteuning voor het automatische uitschakelpatroon (circuit breaker).
Service Mesh wordt doorgaans geĆÆmplementeerd door aan elke service-instantie een proxy-instantie te geven, die een Sidecar wordt genoemd. Sidecar verwerkt de communicatie tussen services, voert monitoring uit en lost beveiligingsproblemen op, dat wil zeggen alles wat kan worden geabstraheerd van afzonderlijke services. Op deze manier kunnen ontwikkelaars de applicatiecode in services schrijven, onderhouden en beheren, terwijl systeembeheerders met de Service Mesh kunnen werken en de applicatie kunnen draaien.
Istio van Google, IBM en Lyft is op dit moment de bekendste Service Mesh-architectuur. Kubernetes, dat aanvankelijk door Google is ontwikkeld, is nu het enige ondersteunende containerorkestratiekader voor Istio. Leveranciers proberen commerciƫle ondersteunde versies van Istio te creƫren. Het is interessant om te zien wat ze aan het open source project kunnen bijdragen.
Echter, Istio is niet de enige optie, aangezien er ook andere implementaties van Service Mesh worden ontwikkeld. Het patroon sidecar proxy is de meest populaire implementatie, zoals blijkt uit de projecten van Buoyant, HashiCorp, Solo.io en anderen. Er zijn ook alternatieve architecturen: de technologie toolset van Netflix is een van de benaderingen waarbij de functionaliteit van Service Mesh wordt geĆÆmplementeerd met behulp van de bibliotheken Ribbon, Hysterix, Eureka, Archaius, evenals platforms zoals Azure Service Fabric.
Service Mesh heeft ook zijn eigen terminologie voor services en hun functies:
- Container orchestration framework. Naarmate er steeds meer containers aan de applicatie-infrastructuur worden toegevoegd, ontstaat de behoefte aan een aparte tool voor het monitoren en beheren van containers - een containerorkestratieraamwerk. Kubernetes heeft deze niche stevig ingenomen, zĆ³ sterk dat zelfs zijn belangrijkste concurrenten, Docker Swarm en Mesosphere DC/OS, integratie met Kubernetes als alternatief aanbieden.
- Diensten en instanties (Kubernetes pods). Een instantie is een enkele draaiende kopie van een microservice. Soms is Ć©Ć©n instantie Ć©Ć©n container. In Kubernetes bestaat een instantie uit een kleine groep onafhankelijke containers, die een pod wordt genoemd. Klanten benaderen zelden direct een instantie of pod; ze benaderen vaker een dienst, die een set identieke, schaalbare en fouttolerante instanties of pods (replica's) vertegenwoordigt.
- Sidecar Proxy. De Sidecar Proxy werkt samen met Ć©Ć©n instantie of pod. Het doel van de Sidecar Proxy is om het verkeer dat van de container komt waarmee hij samenwerkt door te sturen of te proxy'en, evenals het terugverkeer. De Sidecar communiceert met andere Sidecar Proxies en wordt beheerd door het orkestratieraamwerk. Veel implementaties van Service Mesh gebruiken Sidecar Proxy om al het inkomende en uitgaande verkeer van de instantie of pod te onderscheppen en te beheren.
- Serviceontdekking. Wanneer een instantie met een andere dienst moet communiceren, moet deze een werkende en toegankelijke instantie van de andere dienst vinden (ontdekken). Gewoonlijk voert de instantie een zoekopdracht uit via DNS. Het containerorkestratieraamwerk houdt een lijst bij van instanties die klaar zijn om verzoeken te ontvangen en biedt een interface voor DNS-verzoeken.
- Lastenverdeling. De meeste containerorkestratieworkframes bieden load balancing op niveau 4 (transportlaag). Service Mesh implementeert meer geavanceerde load balancing op niveau 7 (applicatielaag), rijk aan algoritmen en efficiƫnter in het beheer van verkeer. De instellingen voor load balancing kunnen worden gewijzigd via de API, waardoor orkestratie van blue-green of canary deployments mogelijk is.
- Versleuteling. Service Mesh kan verzoeken en antwoorden versleutelen en ontsleutelen, waardoor deze belasting van de diensten wordt weggenomen. Service Mesh kan ook de prestaties verbeteren door prioriteit te geven aan of bestaande permanente verbindingen opnieuw te gebruiken, waardoor de noodzaak voor dure berekeningen voor het opzetten van nieuwe verbindingen wordt verminderd. De meest voorkomende implementatie van verkeer versleuteling is mutual TLS (mTLS), waar de infrastructuur voor openbare sleutels (PKI) certificaten en sleutels genereert en verspreidt voor gebruik in Sidecar Proxy.
- Authenticatie en autorisatie. Service Mesh kan verzoeken die van buiten of binnen de toepassing zijn gedaan, autoriseren en authentiseren door alleen gevalideerde verzoeken naar exemplaren te sturen.
- Ondersteuning voor het circuit breaker patroon. Service Mesh ondersteunt , dat ongezonde exemplaren isoleert en deze geleidelijk terugbrengt naar de pool van gezonde exemplaren wanneer dat nodig is.
Het deel van de Service Mesh dat het netwerkverkeer tussen exemplaren beheert, wordt Data Planegenoemd. Het creƫren en implementeren van configuratie die het gedrag beheert Data Plane, gebeurt met behulp van een aparte Control Plane. Control Plane die meestal is ontworpen om verbinding te maken met een API, CLI of GUI voor applicatiebeheer.
Het Control Plane in de Service Mesh verdeelt de configuratie tussen Sidecar Proxy en Data Plane.
De architectuur van Service Mesh wordt vaak toegepast om complexe operationele taken op te lossen met behulp van containers en microservices. Pioniers op dit gebied zijn bedrijven zoals Lyft, Netflix en Twitter, die stabiel werkende diensten aan miljoenen gebruikers over de hele wereld bieden. ( Hier kunt u kennismaken met een gedetailleerde beschrijving van enkele architecturale uitdagingen waarmee Netflix is geconfronteerdDe Service Mesh-architectuur zal waarschijnlijk nooit het antwoord zijn op alle vragen over applicaties en hun levering. Architecten en ontwikkelaars beschikken over een enorm arsenaal aan tools, en slechts een van hen is de hamer, die slechts Ć©Ć©n taak moet vervullen onder de vele ā spijkers inslaan.
Microservices Referentiearchitectuur van NGINX , bijvoorbeeld, omvat verschillende modellen die een continu spectrum aan benaderingen bieden voor het oplossen van problemen met behulp van microservices.
Elementen die samengebracht worden in de Service Mesh-architectuur, zoals NGINX, containers, Kubernetes en microservices als architectonische benadering, kunnen ook zonder Service Mesh even productief worden gebruikt. Bijvoorbeeld, Istio is ontwikkeld als een volledige Service Mesh-architectuur, maar de modulariteit geeft aan dat ontwikkelaars alleen de noodzakelijke technologiecomponenten kunnen kiezen en toepassen. In dat opzicht is het essentieel om een duidelijk begrip van het Service Mesh-concept te vormen, ook al ben je niet zeker of je het ooit volledig in een applicatie kunt implementeren.
Bron: habr.com
