Dmitry Nikolaev - stock.adobe.co
Service-Mesh versus API-Gateway: Warum und wie man sie nutzt
Service-Mesh und API-Gateways sind für die Kommunikation zwischen Anwendungen von zentraler Bedeutung. Entwickler sollten daher die grundlegenden Unterschiede verstehen.
API-Gateways und Service-Mesh haben sich bei der Anwendungskommunikation schon längst einen Namen gemacht: Sie stellen Mittel bereit zur Verwaltung der komplexen Austauschprozesse innerhalb eines verteilten Systems. Beide tragen auf ihre Weise dazu bei, skalierbare Hochleistungsanwendungen zu unterstützen.
Architekten und Entwickler verwenden sie zum Beispiel, um:
- die Kommunikation zwischen verschiedenen Softwareressourcen zu optimieren
- die erforderlichen Daten verfügbar zu machen, die für die Überwachung und Beobachtung von Transaktionen innerhalb von Anwendungen erforderlich sind
- zu vermeiden, dass kommunikationsbasierte Logik direkt in einen einzelnen Dienst oder eine Anwendung codiert werden muss
Wenn beide Ähnliches leisten, stellt sich allerdings die Frage, welches zu bevorzugen ist. Sollte Ihr Entwicklungsteam also besser ein API-Gateway oder ein Service-Mesh implementieren? In vielen Fällen benötigen Sie beides. Daher ist es für Entwickler und Architekten wichtig, die Unterschiede zwischen diesen beiden Ansätzen der Softwarekommunikation ebenso gut zu verstehen wie ihre Gemeinsamkeiten.
Nur dann können Teams fundierte Entscheidungen darüber treffen, welche Rolle diese Kommunikationsansätze in ihrem Anwendungssystem spielen sollen. Ebenso wird ihnen dann klarer, ob sie in der Lage sind, entweder ein API-Gateway oder ein Service-Mesh effektiv zu verwalten.
Wir betrachten zunächst die Grundlagen der beiden Ansätze für die Anwendungskommunikation. Anschließend zeigen wir die wichtigsten Hauptunterschiede auf. Diese legen fest, wann ein Service-Mesh implementiert werden sollte und wann besser ein API-Gateway angebracht ist.
Was ist ein API-Gateway?
Ein API-Gateway ist ein Dienst,
- der eingehende API-Anforderungen von Clients annimmt,
- die Anforderung an den entsprechenden Anwendungsdienst weiterleitet,
- die Antwort dieses Dienstes verarbeitet und
- diese Antwort an den anfordernden Client weiterleitet.
Um zu verstehen, wie ein API-Gateway funktioniert, betrachten wir als Beispiel eine Banksoftware, die eine Sammlung verschiedener Microservices enthält. Ein Microservice ruft beispielsweise Kontodaten ab, während ein anderer Service diese Kontodaten für die Anzeige auf einer Webseite formatiert. Die Kontoanfrage eines Benutzers löst Aufrufe an diese beiden Microservices aus. Sie benötigen also einen Vermittler, der sicherstellt, dass diese Anfrage korrekt und in der richtigen Reihenfolge bearbeitet wird.
In dem Beispielfall dient das API-Gateway als Vermittler und zentraler Punkt, der die Anfragen entgegennimmt. Anschließend leitet das Gateway die Anfrage an die beiden Microservices weiter und sendet die Informationen zurück an die Anwendung, damit diese die Ergebnisse für den Benutzer anzeigen kann.
Technisch gesehen ist ein API-Gateway nicht erforderlich. Die Entwickler können einfach Code in die Anwendung einbetten, der dieser mitteilt, wie Anfragen zu behandeln sind, das heißt, wohin Anfragen zu senden sind und wie die zurückgegebenen Daten zu formatieren sind. Dieser Ansatz erfordert jedoch einen erheblichen Mehraufwand bei der Entwicklung. Außerdem können sich dadurch die Sicherheitsrisiken erhöhen. Schließlich kann eine API durch eine Reihe von Codierungsfehlern dem unbefugten Zugriff und potenziellen Missbrauch ausgesetzt sein.
Durch die Verwaltung von API-Anfragen von externen Systemen über ein zentrales Gateway außerhalb der Anwendung können Entwickler eine sicherere Applikation erstellen und gleichzeitig das Kommunikationsmanagement vereinfachen. API-Gateways erleichtern auch die Überwachung von API-Anfragen und die Verteilung von Anfragen auf mehrere Instanzen eines Microservices. Sie ermöglichen zudem das Verschieben von Microservices von einem Endpunkt zu einem anderen, ohne die Verarbeitung von API-Anfragen zu unterbrechen.
Was ist ein Service-Mesh?
Ein Service-Mesh ist eine Komponente der IT-Infrastruktur, die die Kommunikation zwischen internen Microservices und Komponenten verwaltet. Sie unterstützt bei der gemeinsamen Nutzung der Daten und optimiert die Anwendungsfunktionalität. In der oben beschriebenen Bankanwendung muss der Microservice, der die Kontodaten abruft, möglicherweise eine weitere Anforderung an einen anderen Microservice senden, der die Benutzeridentitäten validiert. Das Service-Mesh hilft diesen beiden Microservices, miteinander zu kommunizieren und die richtigen Ergebnisse zu liefern.
Wie API-Gateways ist auch das Service-Mesh nicht zwingend erforderlich: Es ist möglich, den Code, der diese Transaktionen überwacht, in jeden Microservice einzubetten. Dies ist jedoch eine schwierige Programmieraufgabe, zumal sich die Netzwerkadressen, die den einzelnen Microservices zugewiesen sind, häufig ändern. Um damit Schritt zu halten, müssten Entwickler den Anwendungscode bei jeder Änderung eines Microservice aktualisieren. Oder sie müssten codebasierte Mechanismen implementieren, die den Microservices helfen, sich automatisch selbst zu erkennen. Zudem müssten sie die sich ändernden Netzwerkadressen ständig verfolgen - oder andere, möglicherweise wechselnde Identifizierungsmerkmale.
Ein Service-Mesh löst dieses Problem, indem es automatisch den Standort und die Identifizierung jedes Microservices verfolgt und Daten zwischen ihnen verschiebt. Angenommen, ein bestimmter Microservice – nennen wir ihn Service A – möchte Daten mit einem anderen Microservice – Service B – austauschen. In diesem Fall leitet Service A diese Daten einfach an die Service-Mesh-Implementierung weiter. Diese wiederum leitet die Daten dann an Service B weiter. Das Service-Mesh sammelt anschließend eine Antwort von Service B, dass es zu Service A zurückkehrt.
Service-Mesh versus API-Gateway: fünf Hauptunterschiede
Nachdem wir nun sowohl API-Gateways als auch Service-Mesh definiert haben, wollen wir uns die wichtigsten Unterschiede zwischen den beiden Ansätzen ansehen:
Externe versus interne Kommunikation
API-Gateways verwalten Anfragen, die von außen kommen. Dies kann zum Beispiel die Anfrage eines Anwenders sein, eine bestimmte Seite anzuzeigen. Im Gegensatz dazu handhabt ein Service-Mesh interne Anfragen, die Microservices an andere Microservices innerhalb einer Anwendung stellen. Technisch gesehen überwachen API-Gateways die Kommunikation zwischen Clients und Servern, während das Service-Mesh die Service-zu-Service-Kommunikation übernimmt.
Platzierung innerhalb einer Architektur
API-Gateways und Service-Meshs arbeiten in verschiedenen Schichten einer typischen Softwarearchitektur. Das API-Gateway ist in der Regel eine öffentlich zugängliche Infrastrukturkomponente. Diese befindet sich zwischen dem Rand eines Netzwerks und dem Backend einer Anwendung – einschließlich des Service-Mesh. Wenn externe Komponenten und Systeme Anfragen an die Anwendung stellen, werden diese Anfragen vom API-Gateway empfangen und validiert.
Letztendlich hilft das Service-Mesh dabei, die von einem API-Gateway genehmigten und an das Backend weitergeleiteten Anforderungen zu übertragen. Der Prozess beginnt jedoch am API-Gateway.
Bereitstellung und Verwaltung
Im Vergleich zu einem Service-Mesh sind API-Gateways für den durchschnittlichen Entwickler in der Regel einfacher zu verwalten. Normalerweise müssen Sie ein Gateway nur einmal in Ihrem Software-Stack bereitstellen. Sie eignen sich normalerweise für eine einfache, zentralisierte Überwachung.
Ein Service-Mesh muss sich in jeden Anwendungsdienst, den es verwaltet, integrieren und an diesen anpassen. Der gängigste Implementierungsansatz ist die Ausführung von Service-Mesh-Agenten in einem Proxy-Container – was oft als Sidecar bezeichnet wird. Dieser arbeitet neben jeder Instanz eines containerisierten Microservices und abstrahiert die kommunikationsbezogene Logik von diesem Microservice. Ein Service-Mesh führt also zu einer Vielzahl von beweglichen Teilen und zu einer exponentiellen Komplexität bei der Bereitstellung und Überwachung.
Überwachung
API-Gateway-Metriken sind besonders nützlich bei der Überwachung und Verfolgung des Gesamtzustands einer Anwendung. Beispielsweise, wenn Sie wissen möchten, wie lange es dauert, dass auf bestimmte API-Anforderungen reagiert wird, oder wie stark die Leistung durch hohen Datenverkehr beeinträchtigt wird. API-Gateway-Metriken können dabei helfen, Probleme mit bestimmten APIs zu identifizieren, insbesondere wenn diese Probleme nicht auf einen Netzwerkausfall, einen Anwendungsabsturz oder eine andere allgemeine Ursache zurückgeführt werden können.
Service-Mesh-Metriken helfen Teams bei der Identifizierung von Problemen mit einzelnen Microservices und Komponenten, die das Backend einer Anwendung bilden. Die Service-Mesh-Überwachung ist hilfreich, um die Ursache für bestimmte Probleme mit der Anwendungsleistung zu lokalisieren. Service-Mesh-Metriken liefern jedoch wahrscheinlich keine Hinweise auf die Auswirkungen dieser Probleme aus einer externen Perspektive – beispielsweise, wie sich ein Problem mit der Antwortzeit eines bestimmten Microservices auf die Erfahrung eines Endbenutzers auswirkt.
Werkzeug und Unterstützung
API-Gateway-Tools oder -Plattformen sind selten quelloffene Open-Source-Systeme. Die meisten API-Gateways funktionieren jedoch mit jeder Art von Anwendung oder Architektur.
Umgekehrt gibt es viele Open-Source-Optionen für die Unterstützung eines Service-Mesh. Dazu gehören beispielsweise Istio, Linkerd und Envoy. Beachten Sie jedoch, dass einige Service-Mesh-Tools nur für bestimmte Arten von Umgebungen ausgelegt sind. AWS App Mesh funktioniert zum Beispiel nur innerhalb der AWS-Cloud. Andere Service-Mesh-Optionen, wie Linkerd, unterstützen Microservices, die über Kubernetes bereitgestellt werden.
Welches benötigen Sie?
Die meisten Anwendungen profitieren von der parallelen Verwendung von API-Gateways und Service-Meshs. Während ein API-Gateway den Umgang der Anwendung mit externen Anfragen vereinfachen kann, spielt das Service-Mesh eine entscheidende Rolle bei der Optimierung der internen Kommunikation. Ein API-Gateway kann eine Anfrage an einen bestimmten Microservice weiterleiten, aber dieser Microservice muss mit anderen Microservices kommunizieren – und hier kommt das Service-Mesh ins Spiel.
Wie bereits erwähnt, ist es möglich, ein API-Gateway ohne Service-Mesh zu verwenden und umgekehrt. Dies ist jedoch immer seltener der Fall. Wenn Sie die Agilität Ihrer Anwendung maximieren und den Aufwand der Entwickler für die Verwaltung der Kommunikation minimieren möchten, sollten Sie beides verwenden.
