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. # API-Routing-Muster In agilen Entwicklungsumgebungen besitzen autonome Teams (z. B. Squads und Tribes) einen oder mehrere Services, die viele Microservices umfassen. Die Teams stellen diese Dienste so APIs zur Verfügung, dass ihre Verbraucher mit ihrer Gruppe von Diensten und Aktionen interagieren können. Es gibt drei Hauptmethoden, APIs um HTTP mithilfe von Hostnamen und Pfaden für Upstream-Verbraucher verfügbar zu machen: | | | **Methode** | **Beschreibung** | **Beispiel** | | --- |--- |--- | | [**Hostnamen-Routing**](api-routing-hostname.md) | Stellt jeden Service als Hostnamen bereit. | `billing.api.example.com` | | [**Pfad-Routing**](api-routing-path.md) | Stellt jeden Service als Pfad bereit. | `api.example.com/billing` | | [**Header-basiertes Routing**](api-routing-http.md) | Stellt jeden Service als HTTP-Header bereit. | `x-example-action: something` | In diesem Abschnitt werden typische Anwendungsfälle für diese drei Routing-Methoden und ihre Vorteile beschrieben, damit Sie entscheiden können, welche Methode am besten zu Ihren Anforderungen und Ihrer Organisationsstruktur passt. # Hostname-Routing-Muster Das Routing nach Hostnamen ist ein Mechanismus zur Isolierung von API-Services, indem jeder API ein eigener Hostname zugewiesen wird, z. B. `service-a.api.example.com` oder `service-a.example.com`. ## Typische Anwendungsfälle Das Routing unter Verwendung von Hostnamen reduziert die Reibungsverluste in Versionen, da nichts zwischen den Serviceteams ausgetauscht wird. Die Teams sind dafür verantwortlich, alles zu verwalten, von DNS-Einträgen bis hin zu Servicevorgängen in der Produktion. ![\[Hostnamen-Routing-Muster, um HTTP für Upstream-Verbraucher verfügbar APIs zu machen.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-1.png) ## Vorteile Hostname-Routing ist bei weitem die einfachste und skalierbarste Methode für HTTP-API-Routing. Sie können jeden relevanten AWS Service verwenden, um eine Architektur zu erstellen, die dieser Methode folgt — Sie können eine Architektur mit [Amazon API Gateway [AWS AppSync](https://aws.amazon.com/appsync/)](https://aws.amazon.com/api-gateway/), [Application Load Balancers](https://aws.amazon.com/elasticloadbalancing/) und [Amazon Elastic Compute Cloud (Amazon EC2)](https://aws.amazon.com/ec2/) oder einem anderen HTTP-kompatiblen Service erstellen. Teams können Hostnamen-Routing verwenden, um ihre Subdomain vollständig zu besitzen. Es macht es auch einfacher, Bereitstellungen für bestimmte Versionen zu isolieren, zu testen und zu orchestrieren, z. AWS-Regionen B. für. `region.service-a.api.example.com` `dev.region.service-a.api.example.com` ## Nachteile Wenn Sie Hostnamen-Routing verwenden, müssen sich Ihre Verbraucher unterschiedliche Hostnamen merken, um mit den einzelnen APIs, die Sie bereitstellen, interagieren zu können. Sie können dieses Problem beheben, indem Sie ein Client-SDK bereitstellen. Die Kunden SDKs stehen jedoch vor ihren eigenen Herausforderungen. Sie müssen zum Beispiel fortlaufende Updates, mehrere Sprachen, die Versionsverwaltung, die Übermittlung von fehlerhaften Änderungen aufgrund von Sicherheitsproblemen oder Fehlerkorrekturen, die Dokumentation und so weiter unterstützen. Wenn Sie Hostnamen-Routing verwenden, müssen Sie auch die Subdomain oder Domain jedes Mal registrieren, wenn Sie einen neuen Dienst erstellen. # Pfad-Routing-Muster Beim Routing nach Pfaden werden mehrere oder alle APIs unter demselben Hostnamen gruppiert und Dienste mithilfe eines Anforderungs-URI isoliert, z. B. oder. `api.example.com/service-a` `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 verdauen, da sie häufig zusammengehalten wird, anstatt auf verschiedene Portale aufgeteilt zu werden oder. PDFs Pfadbasiertes Routing gilt als einfacher Mechanismus für die gemeinsame Nutzung einer HTTP-API. 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 Service 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 Services können überall ohne Probleme oder mit jeder Technologie ausgeführt werden, solange sie HTTP-kompatibel sind. ## HTTP-Service-Reverse-Proxy Sie können einen HTTP-Server wie [NGINX](https://www.f5.com/go/product/welcome-to-nginx) verwenden, um dynamische Routing-Konfigurationen zu erstellen. In einer [Kubernetes-Architektur](https://kubernetes.io/) 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](https://kubernetes.io/docs/concepts/services-networking/ingress/#the-ingress-resource).) 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. ![\[Verwenden eines HTTP-Service-Reverse-Proxys für das Pfad-Routing.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-2.png) 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 Reverse-Proxy-Methode für den HTTP-Service besteht darin, einen skalierbaren und verwaltbaren Ansatz für die Vereinheitlichung APIs in einer einzigen Domain zu schaffen, sodass diese für jeden API-Nutzer kohärent erscheint. Dieser Ansatz ermöglicht es Ihren Serviceteams auch, ihre eigenen Lösungen bereitzustellen und zu verwalten APIs, wobei der Aufwand nach der Bereitstellung minimal ist. AWS verwaltete Dienste für die Rückverfolgung, wie [AWS X-Ray](https://aws.amazon.com/xray/)oder [AWS WAF](https://aws.amazon.com/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 Gateway-Service](https://aws.amazon.com/api-gateway/) (REST APIs und HTTP APIs) kann den Datenverkehr auf eine Weise weiterleiten, die der Reverse-Proxy-Methode des HTTP-Service ä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 APIs, da Sie das Root-API-Gateway nicht bei jeder API-Änderung aktualisieren müssen. ![\[Pfad-Routing über API-Gateway.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-3.png) ### Vorteile Für die Steuerung komplexerer Workflows, wie z. B. das Ändern von Anforderungsattributen, stellt APIs REST die Apache Velocity Template Language (VTL) zur Verfügung, sodass Sie die Anfrage und Antwort ändern können. REST APIs kann zusätzliche Vorteile wie diese bieten: + [Authentifizierung N/Z mit AWS Identity and Access Management (IAM),](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/authentication.html) [[Amazon Cognito](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-net-applications-security/cognito.html) oder Autorisierern AWS Lambda](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html) + [AWS X-Ray zur Rückverfolgung](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-understanding-xray-traces.html) + [Integration mit AWS WAF](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) + [Grundsätzliche Ratenbegrenzung](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) + Nutzungs-Tokens für die Einteilung der Verbraucher in verschiedene Buckets (siehe [Drosselung von API-Anfragen für besseren Durchsatz](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html) in der API-Gateway-Dokumentation) ### Nachteile Bei hohem Volumen könnten die Kosten für einige Benutzer ein Problem darstellen. ## CloudFront Sie können die [dynamische Herkunftsauswahlfunktion](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-event-structure.html) in [Amazon](https://aws.amazon.com/cloudfront/) 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. ![\[Pfadweiterleitung durch. CloudFront\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-4.png) ### 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 zur Vereinheitlichung von Sammlungen von APIs. CloudFront Unterstützt außerdem die [Verschlüsselung auf Feldebene](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/field-level-encryption.html) sowie die Integration mit AWS WAF Basic Rate Limiting und Basic. 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 bei einer großen Anzahl von APIs Diensten zu Problemen 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. # HTTP-Header-Routing-Muster Header-basiertes Routing ermöglicht es Ihnen, für jede Anfrage den richtigen Service als Ziel festzulegen, indem Sie in der HTTP-Anfrage einen HTTP-Header angeben. Wenn Sie den Header `x-service-a-action: get-thing` senden, können Sie beispielsweise `get thing` von `Service A` abrufen. Der Pfad der Anfrage ist immer noch wichtig, da er Hinweise darauf bietet, an welcher Ressource Sie arbeiten möchten. Sie können das HTTP-Header-Routing nicht nur für Aktionen verwenden, sondern es auch als Mechanismus für das Versions-Routing verwenden, um Feature-Flags, A/B Tests oder ähnliche Anforderungen zu aktivieren. In der Realität werden Sie wahrscheinlich Header-Routing zusammen mit einer der anderen Routing-Methoden verwenden, um ein robustes Routing zu erreichen APIs. Die Architektur für HTTP-Header-Routing hat typischerweise eine einfache Routing-Schicht vor den Microservices, die zum richtigen Service weiterleitet und eine Antwort zurückgibt, wie im folgenden Diagramm dargestellt. Diese Routing-Schicht könnte alle oder nur einige Services umfassen, um einen Vorgang wie das versionsbasierte Routing zu ermöglichen. ![\[HTTP-Header-Routing.\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/cloud-design-patterns/images/routing-5.png) ## Vorteile Konfigurationsänderungen erfordern nur minimalen Aufwand und können einfach automatisiert werden. Außerdem ist diese Methode flexibel und bietet kreative Möglichkeiten, um lediglich bestimmte Vorgänge, die Sie von einem Service erwarten, darzustellen. ## Nachteile Wie bei der Hostnamen-Routing-Methode geht das HTTP-Header-Routing davon aus, dass Sie die volle Kontrolle über den Client haben und benutzerdefinierte HTTP-Header bearbeiten können. Proxys, Content Delivery Networks (CDNs) und Load Balancer können die Header-Größe einschränken. Obwohl dies wahrscheinlich nicht bedenklich ist, könnte es ein Problem darstellen, je nachdem, wie viele Header und Cookies Sie hinzufügen.