Een architectuur met een service mesh is bedoeld voor het beheren van complexe interacties tussen microservices via een aparte infrastructuurlaag. De service mesh biedt automatisch functies zoals routering, load balancing, service discovery, beveiliging (bijvoorbeeld mTLS), logging, tracking en het herhalen van verzoeken zonder dat dit in elke service hoeft te worden geïmplementeerd. Dit wordt allemaal bereikt door speciale proxies (sidecar) die naast elke microservice worden uitgevoerd en al het netwerkverkeer onderscheppen.
Een traditionele microservicesarchitectuur vereist dat de meeste van deze functies binnen de services zelf of op het platformniveau worden geïmplementeerd, wat het ontwikkelen en onderhouden van het project bemoeilijkt naarmate het aantal services toeneemt.
Voorbeeld van de configuratiecode voor Istio service mesh voor Kubernetes:
apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: my-service spec: hosts: - my-service http: - route: - destination: host: my-service subset: v1
Belangrijke kenmerken:
Gecentraliseerde routering en beheer van netwerkinteractiebeleidsregels.
Minimale duplicatie van de logica voor interactie in elke service.
Verbeterde beveiliging en monitoring zonder wijziging van de bedrijfslogica van applicaties.
Vervangt de service mesh volledig de API-gateway?
Nee, de service mesh en de API-gateway vullen elkaar aan: de API-gateway biedt inkomende controle en de service mesh beheert de east-west communicatie tussen services.
Moet de code van services worden aangepast bij het implementeren van de service mesh?
Normaal gesproken niet. In de meeste gevallen wordt de service proxy in sidecar-modus uitgevoerd en is het niet nodig om de bedrijfslogica te veranderen.
Verhoogt de service mesh de latency van microservices?
De service mesh voegt inderdaad enige vertraging toe door de verwerking van het proxyverkeer, maar voor de meeste scenarios is dit verwaarloosbaar in vergelijking met de winst in beheersbaarheid en betrouwbaarheid.