Welches Ziel erreicht der Kundenservice über „Versandstatus-Routen“?

Den Versanddienst. Der Kundenservice ruft dafür das API-Gateway auf.

Der Katalogdienst bekommt eine neue interne Adresse. Welche Clients müssen angepasst werden?

Keine. Browser und Kundenservice adressieren das API-Gateway; nur dessen Katalog-Route zeigt auf das neue Ziel.

Sollen Browser den Katalogdienst direkt aufrufen statt über das Gateway? Wie wägst du ab?

Es spart einen Zwischenschritt. Dafür kennen Clients interne Ziele, und Zugangsregeln müssten pro Dienst wiederholt werden. Das Gateway bündelt beides, ist aber ein zusätzlicher Baustein am Rand.

MusterfamilieKapitel II · Kommunikation · Baustein 8 von 9

Gateway, Mesh & Discovery

Ein API-Gateway bündelt den externen Zugang zu mehreren internen Zielen. Es übernimmt Routing und gemeinsame Zugangsregeln am Systemrand.

Von Michael Meierhoff · Meierhoff Systems

Gemeinsamer ZugangClients kennen nur das Gateway.
RoutingJede Route zum zuständigen Ziel.
SystemrandZugangsregeln gebündelt am Rand.

Einordnung

Warum das wichtig ist

Ohne gemeinsamen Zugang kennen Clients jedes interne Ziel einzeln, und Änderungen an internen Diensten treffen sie direkt. Interne Dienstkommunikation und Vertragsinhalte sind eigene Bausteine.

Dieser Baustein erklärt das API-Gateway am externen Zugang. Service Discovery und Mesh betreffen interne Dienstkommunikation; für fachliche Schnittstelleninhalte siehe API-Verträge.

Auf einen Blick · Ein Eingang für viele Dienste

Web und Mobile sprechen nur mit dem API-Gateway, das Anfragen an den passenden Dienst weiterleitet.

Shop-Beispiel · Bausteine und Beziehungen

Ein externer Zugang für drei interne Ziele

Variante: Katalog und Versand wurden aus belegten Betriebsgründen als Dienste getrennt. Browser und Kundenservice greifen ausschließlich über das API-Gateway auf Shop-Routen zu.

So liest du das Bild

Gemeinsamer Zugang Die Pfeile Browser und Kundenservice zum API-Gateway, beide über HTTPS.
Routing Die Pfeile „Checkout-Routen“, „Katalog-Routen“ und „Versandstatus-Routen“ vom API-Gateway.
Systemrand Der Kasten API-Gateway im Bereich Plattform, vor den Kästen im Bereich Interne Dienste.

Clients adressieren das Gateway; es leitet jede Route an das zuständige interne Ziel weiter.

Nutzen & Grenzen

Hilft, wenn

Ein gemeinsamer Eintrittspunkt bündelt Querschnittsregeln für externe Zugriffe.
Ein Mesh vermittelt interne Verbindungen und unterstützt deren Absicherung und Beobachtung.
Dynamisch entstehende Dienstinstanzen bleiben über Discovery auffindbar.

Grenzen

Mit Fachregeln im Gateway wird es zum Änderungsengpass; halte seine Rolle auf Querschnittsfunktionen wie Routing und Zugang.
Gateway, Service Mesh und Discovery haben verschiedene Vertrauensgrenzen; Richtlinien müssen je Verbindung eindeutig zugeordnet sein.
Ein zentraler Eintrittspunkt ersetzt keine Prüfung je Zone; siehe Trust Boundaries.

In der Praxis

Ordne Gateway, Mesh und Discovery getrennte Zuständigkeiten zu. Halte fachliche Entscheidung aus generischer Weiterleitung heraus und prüfe, wo Identität durchgesetzt wird.
Lege Zeitbudget, Authentisierung und Fehlerantwort für jede Verbindung fest. Beobachte, welcher Layer eine Anfrage abweist oder umleitet.
Teste Discovery bei wechselnden Instanzen und Mesh-Ausfall. Trust Boundaries klärt Vertrauenszonen; Observability verbindet Signale.

Ausführliche Erklärung lesen

Gateway, Service Mesh und Discovery haben getrennte Rollen. Ein Gateway bündelt externen Eintritt und Richtlinien. Ein Mesh vermittelt interne Dienstverbindungen. Discovery findet aktuell erreichbare Instanzen eines Dienstes.

Eine klare Grenze verhindert, dass Routing, Sicherheitsregeln und fachliche Entscheidungen ununterscheidbar zusammenwachsen. Konfiguration, Identität, Zeitbudgets und Ausfälle müssen über die jeweiligen Verbindungen hinweg nachvollziehbar bleiben.

Trust Boundaries markieren, wo Identität und Eingaben neu geprüft werden; Observability verbindet Ablehnungen und Weiterleitungen über mehrere Laufzeitkomponenten.

Ein Gateway steuert den Nord-Süd-Verkehr, also Anfragen von außen herein; ein Service Mesh steuert den Ost-West-Verkehr zwischen Diensten. Im modularen Monolithen braucht es meist keines von beiden.

Selbst prüfen

Teste dich in drei Stufen

AblesenIm Bild nachsehen
Welches Ziel erreicht der Kundenservice über „Versandstatus-Routen“?
Lösung mit Begründung ansehen
Den Versanddienst. Der Kundenservice ruft dafür das API-Gateway auf.
AnwendenAuf eine neue Lage übertragen
Der Katalogdienst bekommt eine neue interne Adresse. Welche Clients müssen angepasst werden?
Lösung mit Begründung ansehen
Keine. Browser und Kundenservice adressieren das API-Gateway; nur dessen Katalog-Route zeigt auf das neue Ziel.
BewertenEine Alternative abwägen
Sollen Browser den Katalogdienst direkt aufrufen statt über das Gateway? Wie wägst du ab?
Lösung mit Begründung ansehen
Es spart einen Zwischenschritt. Dafür kennen Clients interne Ziele, und Zugangsregeln müssten pro Dienst wiederholt werden. Das Gateway bündelt beides, ist aber ein zusätzlicher Baustein am Rand.

Vertiefen

Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.

Backend for Frontend

Ein Backend for Frontend (BFF) ist ein client-spezifischer Vermittlungsdienst, der Daten mehrerer zuständiger Dienste passend für eine Web- oder Mobiloberfläche zusammenstellt. Damit kann er Anfragen bündeln und unnötige Details auslassen. Fachregeln und Datenhoheit bleiben bei den zuständigen Diensten; der zusätzliche Vermittlungspunkt braucht eigene Zuständigkeit und Beobachtbarkeit.

Zum AusprobierenBFF am Shop vergleichen. Stelle für die mobile Bestellansicht einen kompakten Status aus Bestellung, Zahlung und Versand zusammen. Prüfe, welche zusätzlichen Details die Webansicht braucht und welche fachlichen Regeln bei den zuständigen Diensten bleiben.

Quellen

Weiter im Lernpfad

Als Nächstes in Kommunikation & APIs: API-Versionierung.

9 Bausteine

Weiter mitAPI-Versionierung