Entwicklung eines Microservices mit AWS Serverless

Abbildung 7: Die CreatePayment-Methode akzeptiert ein Payment-Objekt und wandelt die Daten so um, dass sie für DynamoDB geeignet sind. Dafür weist sie dem Payment-Objekt eine "uuid" und dem Payer (der ebenso eine "uuid" hat) einen PartitionKey und einen SortKey zu. PartitionKey und SortKey sind Strings. Der PartitionKey enthält die Payer-ID und der SortKey eine Payment-ID. Schließlich persistiert sie die Daten mit der PutEntity-Funktion des AWS SDK.

Der vorliegende Beispielservice ist recht einfach und würde in einem Produktionsszenario nicht so verwendet werden, aber für Demonstrationszwecke ist er gut geeignet. Mit dieser Codebasis kann ein Benutzer über die REST-API-Schnittstelle des Services problemlos Zahlungen erstellen, abrufen und aktualisieren.

Bevor wir die Infrastruktur in AWS erstellen können, muss der Code als Zip-Datei erstellt und komprimiert werden und sich in dem Verzeichnis befinden, auf das später in einer serverless.yml-Datei verwiesen wird.

Wir können unseren Code mit dem Go-Build-Befehl erstellen (unter Angabe von Linux als Betriebssystem und dem korrekten Pfad zu unserer main.go-Datei):

              GOOS=linux go build -o bootstrap { main.go file location }

Sobald dies erledigt ist, können wir uns dem Infrastrukturteil widmen.

Abbildung 8: Grundlegende Serverless-Framework-Konfiguration in einer yaml-Datei, die den Servicenamen, den Service-Provider, die Runtime sowie die AWS-Region und einen Namen für die Deployment Stage definiert.

Als nächstes wird eine Lambda-Funktion definiert. Hierfür müssen wir einen Namen und einige andere Attribute wie folgt festlegen:
 

• Package.artifact: Pfad zu dem komprimierten Code, der in die Funktion hochgeladen werden soll (Abbildung 9, Zeile 2-3)
• Handler: Eintrittspunkt der Lambda-Funktion (muss “bootstrap” heißen in Serverless Framework Version 3, siehe Abbildung 9, Zeile 4)
• Wichtige Umgebungsvariablen (hier: DynamoDB Tabellenname, Abbildung 9, Zeile 5-6)
• Events (Abbildung 9, Zeile 7-22)
   

Der letzte Parameter „events“ gibt an, wie die Lambda-Funktion ausgeführt werden soll. In unserem Fall wird sie durch HTTP-Requests über das API-Gateway ausgelöst, daher der Wert „http“. Sie könnte aber auch durch eine Queue oder Notifikation über Amazon SQS oder Amazon SNS oder viele andere Services ausgelöst werden.

Abbildung 9: Definition einer AWS Lambda-Funktion in einer serverless.yml Datei

Außerdem müssen die Ressourcen für DynamoDB und die Standard-IAM-Rolle definiert werden. Für DynamoDB müssen die Partition und der Sortierschlüssel angegeben werden, da sie nach der Tabellenerstellung nicht mehr geändert werden können. Es ist wichtig, für die IAM-Rolle zwei Dinge zu definieren:

• Sie benötigt die Erlaubnis, die Lambda-Funktion zu übernehmen (Abbildung 10, Zeile 43-50)
• Die Lambda-Funktion benötigt Zugriff auf DynamoDB-Operationen (Abbildung 11)

Abbildung 10: DynamoDB und IAM Role Konfiguration mit dem Serverless Framework.

Abbildung 11: IAM Policy, welche DynamoDB Aktionen an der Tabelle “Payments” erlaubt.

Abbildung 12: payment-dev Stack in AWS CloudFormation nach erfolgreicher Erstellung der Ressourcen.

Von dort aus kann man zum API-Gateway navigieren und die Registerkarte „Stages“ aufrufen, um die Invoke-URL zu erhalten. Diese URL ist die Basis-URL für das Senden von Requests an den Payment Service (man muss beachten, dass sich die Invoke-URL nach dem Löschen und Neuanlegen des Stacks ändert). Außerdem kann man hier mehr als eine Stage haben, zum Beispiel für „dev“, „test“ und „prod“, um verschiedene Umgebungen eines Services zu verwalten. Amazon API Gateway zeigt auch alle REST-API-Endpunkte in einer hierarchischen Reihenfolge unter der Registerkarte „Resources“ an. Diese ermöglicht einen schnellen und umfassenden Überblick darüber, was der Service bietet (siehe Abbildung 13). Zudem wird die verwendete Autorisierungsmethode angezeigt. In diesem Fall sind „AWS_IAM“ für die gültige AWS-Anmeldeinformationen und die Berechtigung „execute-api“ erforderlich. Ansonsten wird bei Requests an den Service die Meldung „403 Forbidden“ zurückgegeben.

Abbildung 13: AWS Management Console für API Gateway zeigt die Registerkarte „Resource“ für den Payment Service mit allen verfügbaren REST-Endpunkten und der Autorisierungsmethode.

Abbildung 14: Ein erfolgreicher POST /payments REST Request mit Postman.

Wenn wir die Lambda-Funktion des Services in der AWS Management Console aufrufen, können wir feststellen, dass sie unter dem Abschnitt „Monitor“ getriggert wurde (siehe Abbildung 15). Von hier aus können wir auch direkt zu den in Amazon CloudWatch erstellten Logs des Services gehen, was für die Problembehandlung im Falle von Fehlern sehr nützlich ist.

Abbildung 15: Payment Lambda-Funktion mit Trigger um 15 Uhr (unteres linkes Diagramm), Dauer der Ausführung (unteres mittleres Diagramm), Fehlerzahl und Erfolgsquote (unteres rechtes Diagramm).

Man kann auch zur DynamoDB-Tabelle „Payments“ in der AWS Management Console navigieren, um die erstellte Payment Entity mit ihren Attributen anzuzeigen (siehe Abbildung 16).

Abbildung 16: DynamoDB-Tabelle „Payments“ mit einem Eintrag für ein Payment-Objekt, mit PartitionKey („Payer_Id“), SortKey („Payment_Id“) und den Attributen des Objekts, die in einer zusätzlichen Spalte („Data“) gespeichert sind.

Schließlich kann man den Stack bei Bedarf wieder entfernen, indem man den Befehl „serverless remove“ verwendet, der dafür sorgt, dass alle in der Datei serverless.yml angegebenen Ressourcen vernichtet werden.