In einer auf Microservices basierenden Architektur für ein System auf Unternehmensebene wie Clumio ist es nicht praktikabel, für jeden Microservice einen öffentlichen Endpunkt zu haben. Eines der größten Probleme ist die enge Kopplung, die dadurch zwischen Client und Server entsteht. Zudem muss jeder Microservice die gemeinsamen Komponenten wie Protokollierung, Tracing und Sicherheit (Authentifizierung, Autorisierung, Ratenbegrenzung) implementieren und warten.
Ein API-Gateway ist zwischen einem Client und einem Server geschaltet und fungiert als Proxy für Anfragen und Antworten zwischen den beiden.
Ein API-Gateway bietet einen einheitlichen Einstiegspunkt für alle externen Clients und ein Framework, das alle oben genannten gemeinsamen Komponenten abdeckt. Dies ermöglicht es zudem jedem Microservice, unabhängig vom Gateway sein eigenes Kommunikationsprotokoll zu implementieren, das seinen Anforderungen am besten entspricht.
AWS API Gateway
Neben den oben genannten Vorteilen, die API-Gateways bieten, hatten wir noch weitere Anforderungen, die bei der Auswahl eine Rolle spielten:
- Ein Mechanismus, der eine nahtlose Integration mit dem API-Gateway ermöglicht, sodass die Einführung neuer APIs und die Pflege bestehender APIs reibungslos bzw. mit minimalem Aufwand erfolgen, damit sich die Entwickler in erster Linie auf ihre Geschäftslogik konzentrieren können
- Da ein API-Gateway potenziell einen Single Point of Failure darstellen könnte, sollte es sich um ein vollständig verwaltetes Angebot handeln, das ausfallsicher und hoch skalierbar ist.
- Unterstützung für WebSockets
Das AWS API Gateway erfüllt all diese Anforderungen und bietet eine gute Integration mit anderen AWS-Diensten, auf deren Grundlage sich weitere Lösungen entwickeln lassen.
Nutzung des AWS API Gateway
Swagger-Spezifikation
Swagger bietet eine leistungsstarke Darstellung für RESTful-APIs.
Wir haben das Tool „go-swagger“ eingesetzt, mit dem sich aus mit Annotationen versehenem Go-Code eine Swagger-Spezifikation generieren lässt.
Daher müssen Entwickler ihre REST-API lediglich gemäß der oben genannten Spezifikation mit Annotationen versehen und es unserem Framework (auf das später noch eingegangen wird) überlassen, die Integration in das AWS API Gateway zu übernehmen.
Integration mit dem AWS API Gateway
Bei Clumio wird unsere gesamte AWS-Infrastruktur als Code über Terraform verwaltet. Das AWS API Gateway lässt sich mithilfe der von Terraform bereitgestellten Ressourcen konfigurieren.
Wir verwenden die Ressource „aws_api_gateway_rest_api“, mit der wir die gesamte Swagger-Spezifikation in das AWS API Gateway einspeisen können. Das AWS API Gateway kann jedoch keine reine Swagger-Spezifikation verarbeiten. Es erwartet verschiedene Erweiterungen (wie x-amazon-apigateway-integration), damit es eine API nahtlos konfigurieren kann. Hierfür haben wir ein Framework implementiert, das die erforderlichen Erweiterungen in eine rohe Swagger-Spezifikation einfügt, damit diese mit dem AWS API Gateway funktioniert!
VPC-Link-Integrationstyp
Das AWS API Gateway bietet verschiedene Integrationsmöglichkeiten mit Ihren Backend-Servern, um die eingehenden API-Anfragen weiterzuleiten.
Da alle unsere Microservices aus Sicherheitsgründen an eine VPC gebunden sind, nutzen wir die VPC Link Integration. Dadurch kann das AWS API Gateway sicher auf private API-Endpunkte innerhalb der VPC zugreifen.
Benutzerdefinierte Domainnamen und API-Zuordnungen
Standardmäßig generiert AWS API Gateway einen eindeutigen Domainnamen für die API, etwa aabbccdd12.execute-api.us-west-2.amazonaws.com. Als Unternehmen möchten wir natürlich den öffentlichen Domainnamen der APIs für unsere Nutzer individuell anpassen. AWS API Gateway ermöglicht uns dies über benutzerdefinierte Domainnamen.
Darüber hinaus erstellen wir im API Gateway separate APIs, die einigen unserer am stärksten frequentierten API-Basispfade entsprechen. Alle diese APIs werden dann, wie unten dargestellt, über API-Zuordnungen miteinander verknüpft. Auf diese Weise können wir unsere APIs horizontal skalieren und verfügen dennoch über einen einzigen, nach außen gerichteten Domainnamen für sie.
Lambda-Authorizer, Nutzungspläne und API-Schlüssel
Wie bereits erwähnt, besteht einer der Hauptanwendungsfälle für ein API-Gateway darin, die Authentifizierung und Autorisierung gleich zu Beginn des Lebenszyklus einer API-Anfrage durchzusetzen, damit nur der relevante Datenverkehr die Backend-Server erreicht.
Für die Authentifizierung und Autorisierung nutzen wir den Lambda Authorizer, während die Nutzungspläne und API-Schlüssel dazu dienen, die Ratenbegrenzung bzw. Drosselung für unsere APIs durchzusetzen.
Wir haben einen tokenbasierten Lambda-Authorizer implementiert, der folgende Eingabe erwartet:
Das authorizationToken (in Form eines JWT) kann verwendet werden, um die erforderliche Authentifizierungs-/Autorisierungslogik innerhalb des Lambda-Authorizers zu implementieren, um die folgende Ausgabe zurückzugeben:
Die Entscheidung zur Authentifizierung/Autorisierung richtet sich nach dem Wert von Effect (Allow|Deny) und die Drosselungsentscheidung vom API-Schlüssel-Identifikator in usageIdentifierKey. Der API-Schlüssel muss einem Nutzungsplan zugeordnet sein, der das durchzusetzende Anforderungslimit (in Form von Anfragen pro Sekunde) festlegt. Wir stellen für jeden Kunden einen API-Schlüssel aus und können somit die Drosselung auf Kundenebene durchsetzen.
Ein weiterer interessanter Aspekt in der Ausgabe ist context , dass sie je nach den Anforderungen der Anwendung beliebige Schlüssel-Wert-Paare enthalten kann. Wir nutzen dies intensiv, um die Client-Informationen zu erfassen, die wir dann während des gesamten Lebenszyklus der API-Anfrage weitergeben. Dadurch entfällt die Notwendigkeit, Client-Details nachzuschlagen, während die Anfrage im Backend mehrere Microservices durchläuft.
Fazit
Wir hoffen, dass Sie einen Einblick darin gewonnen haben, wie wir bei Clumio das AWS API Gateway nutzen, und dass Sie einen kleinen Einblick in unsere allgemeinen technischen Aktivitäten erhalten haben. Wir legen größten Wert auf Sicherheit, Skalierbarkeit und vor allem auf die Einführung entwicklerfreundlicher Prozesse. Dies erleichtert die Wartung unserer Produkte im Zuge unserer Weiterentwicklung und Skalierung und gewährleistet gleichzeitig genügend Flexibilität, um neue Funktionen zu integrieren.
