Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Pfad-Routing-Muster

Routing nach Pfaden ist der Mechanismus, mehrere oder alle APIs unter demselben Hostnamen zu gruppieren und einen Anforderungs-URI zu verwenden, um Services zu isolieren; z. B. api.example.com/service-a oder api.example.com/service-b.

Typische Anwendungsfälle

Die meisten Teams entscheiden sich für diese Methode, weil sie eine einfache Architektur wollen – ein Entwickler muss sich nur eine URL merken, zum Beispiel api.example.com, um mit der HTTP-API zu interagieren. Die API-Dokumentation ist oft leichter zu verarbeiten, da sie oft zusammen gehalten wird, anstatt auf verschiedene Portale oder PDFs aufgeteilt zu sein.

Path-based Routing wird als einfacher Mechanismus für die gemeinsame Nutzung einer HTTP-API angesehen. Es ist jedoch mit betrieblichem Aufwand wie Konfiguration, Autorisierung, Integrationen und zusätzlicher Latenz aufgrund mehrerer Übergaben verbunden. Außerdem sind ausgereifte Änderungsmanagementprozesse erforderlich, um sicherzustellen, dass eine Fehlkonfiguration nicht zu einer Unterbrechung aller Services führt.

Bei gibt es mehrere Möglichkeiten AWS, eine API gemeinsam zu nutzen und effektiv zum richtigen Dienst weiterzuleiten. In den folgenden Abschnitten werden drei Ansätze behandelt: HTTP Service Reverse Proxy, API Gateway und Amazon CloudFront. Keiner der vorgeschlagenen Ansätze zur Vereinheitlichung von API-Services stützt sich auf die Downstream-Services, die auf AWS laufen. Die Dienste könnten überall ohne Probleme oder mit jeder Technologie ausgeführt werden, solange sie es sind HTTP-compatible.

HTTP-Service-Reverse-Proxy

Sie können einen HTTP-Server wie NGINX verwenden, um dynamische Routing-Konfigurationen zu erstellen. In einer Kubernetes-Architektur können Sie auch eine Eingangsregel erstellen, die dem Pfad zu einem Service entspricht. (Dieser Leitfaden behandelt nicht den Kubernetes-Eingang. Weitere Informationen finden Sie in der Kubernetes-Dokumentation.)

Die folgende Konfiguration für NGINX ordnet dynamisch eine HTTP-Anfrage von api.example.com/my-service/ zu my-service.internal.api.example.com zu.

server {
    listen  80;

    location (^/[\w-]+)/(.*) {
        proxy_pass $scheme://$1.internal.api.example.com/$2;
    }
}

Das folgende Diagramm veranschaulicht die Methode des HTTP-Service-Reverse-Proxy.

Dieser Ansatz kann für einige Anwendungsfälle ausreichend sein, in denen keine zusätzlichen Konfigurationen verwendet werden, um die Verarbeitung von Anfragen zu starten, sodass die nachgelagerte API Metriken und Protokolle sammeln kann.

Um für die Produktion betriebsbereit zu sein, müssen Sie in der Lage sein, die Beobachtbarkeit auf jeder Ebene Ihres Stacks hinzuzufügen, zusätzliche Konfigurationen vorzunehmen oder Skripte hinzuzufügen, um Ihren API-Eingangspunkt so anzupassen, dass fortgeschrittene Features wie Ratenbegrenzung oder Nutzungs-Tokens möglich sind.

Vorteile

Das ultimative Ziel der Methode des HTTP-Service-Reverse-Proxy ist es, einen skalierbaren und verwaltbaren Ansatz zur Vereinheitlichung von APIs in einer einzigen Domain zu schaffen, so dass sie für jeden API-Verbraucher kohärent erscheint. Dieser Ansatz ermöglicht es Ihren Serviceteams auch, ihre eigenen APIs bereitzustellen und zu verwalten, wobei der Aufwand nach der Bereitstellung minimal ist. AWS verwaltete Dienste für die Nachverfolgung, wie AWS X-Rayoder AWS WAF, sind hier weiterhin anwendbar.

Nachteile

Der größte Nachteil dieses Ansatzes ist das umfangreiche Testen und Verwalten der erforderlichen Infrastrukturkomponenten, obwohl dies möglicherweise kein Problem darstellt, wenn Sie über Teams für Site Reliability Engineering (SRE) verfügen.

Bei dieser Methode gibt es einen Kostenschwellenwert. Bei niedrigen bis mittleren Mengen ist sie teurer als einige der anderen Methoden, die in diesem Handbuch beschrieben werden. Bei hohen Volumen ist sie sehr kostengünstig (etwa 100 000 Transaktionen pro Sekunde oder besser).

API Gateway

Der Amazon-API-Gateway-Service (REST-APIs und HTTP-APIs) kann den Datenverkehr auf eine Weise weiterleiten, die der Methode des HTTP-Service-Reverse-Proxys ähnelt. Die Verwendung eines API-Gateways im HTTP-Proxymodus bietet eine einfache Möglichkeit, viele Services in einen Einstiegspunkt zur Top-Level-Subdomain api.example.com einzubinden und dann Anfragen an den verschachtelten Service weiterzuleiten, zum Beispiel billing.internal.api.example.com.

Sie möchten wahrscheinlich nicht zu differenziert vorgehen und jeden Pfad in jedem Service im Root- oder Core-API-Gateway abbilden. Entscheiden Sie sich stattdessen für Wildcard-Pfade, wie z. B. /billing/*, um Anfragen an den Abrechnungsservice weiterzuleiten. Indem Sie nicht jeden Pfad im Root- oder Core-API-Gateway zuordnen, gewinnen Sie mehr Flexibilität bei Ihren APIs, da Sie das Root-API-Gateway nicht bei jeder API-Änderung aktualisieren müssen.

Vorteile

Für die Kontrolle über komplexere Workflows, wie z. B. die Änderung von Anfrageattributen, stellen REST-APIs die Apache Velocity Template Language (VTL) zur Verfügung, mit der Sie die Anfrage und die Antwort ändern können. REST-APIs können zusätzliche Vorteile wie die folgenden bieten:

Nachteile

Bei hohem Volumen könnten die Kosten für einige Benutzer ein Problem darstellen.

CloudFront

Sie können die dynamische Herkunftsauswahlfunktion in Amazon verwenden CloudFront, um bedingt einen Ursprung (einen Service) auszuwählen, um die Anfrage weiterzuleiten. Sie können dieses Feature verwenden, um eine Reihe von Services über einen einzigen Hostnamen weiterzuleiten, z. B. api.example.com.

Typische Anwendungsfälle

Die Routing-Logik ist als Code in der Lambda @Edge -Funktion enthalten und unterstützt daher hochgradig anpassbare Routing-Mechanismen wie A/B Tests, Canary-Releases, Feature-Flagging und Pfadumschreibung. Dies wird im folgenden Diagramm veranschaulicht.

Vorteile

Wenn Sie API-Antworten zwischenspeichern müssen, ist diese Methode eine gute Möglichkeit, eine Sammlung von Services hinter einem einzigen Endpunkt zu vereinen. Es ist eine kostengünstige Methode, um Sammlungen von APIs zu vereinheitlichen.

CloudFront Unterstützt außerdem die Verschlüsselung auf Feldebene sowie die Integration mit grundlegenden AWS WAF Ratenbegrenzungen und Basis-ACLs.

Nachteile

Diese Methode unterstützt maximal 250 Ursprünge (Services), die vereinheitlicht werden können. Dieses Limit ist für die meisten Bereitstellungen ausreichend, kann jedoch zu Problemen mit einer großen Anzahl von APIs führen, wenn Sie Ihr Serviceportfolio erweitern.

Die Aktualisierung der Lambda @Edge -Funktionen dauert derzeit einige Minuten. CloudFront es dauert außerdem bis zu 30 Minuten, bis die Übertragung der Änderungen an allen Präsenzpunkten abgeschlossen ist. Dadurch werden letztlich weitere Updates blockiert, bis sie abgeschlossen sind.