Serverloses Ping Pong

Tischtennis ist ein interessantes Spiel. Es ist ein Spiel, bei dem zwei Spieler einen leichten Ball mit kleinen Schlägern über einen Tisch hin und her schlagen. Das Spiel findet auf einem harten Tisch statt, der durch ein Netz getrennt ist. Wenn Sie das Spiel als Beobachter betrachten, sehen Sie einige interessante Dinge. Die Spieler agieren nur, wenn sich der Ball auf ihrer Seite des Tisches befindet. Erst dann schwingt ein Spieler den Schläger und der Ball beginnt sich in die andere Richtung zu bewegen. Wenn Sie in der IT arbeiten, erkennen Sie auch andere Dinge. Im Spiel gibt es einen asynchronen Prozess. Die Spieler reagieren auf den Ball und agieren auf ihn. Außerdem bewegt sich der Ball von links nach rechts und von rechts nach links. Eine weitere interessante Sache ist, dass die Spieler nur dann schwingen, wenn der Ball getroffen werden kann, aber dazwischen tun sie nichts anderes. Lassen Sie uns versuchen, diesen Prozess auf eine serverlose Weise zu modellieren.

Das Ping-Pong-Modell

Um das Spiel serverlos zu modellieren, können wir AWS Lambda als Spieler verwenden. Für den Ball können wir eine Nachricht nehmen. Für den Spieltisch können wir zwei Nachrichten-Warteschlangen nehmen, eine für die Bewegung von links nach rechts und eine für die Bewegung von rechts nach links, und AWS SNS passt perfekt. Für die Schläger können wir den Akt der 'Veröffentlichung einer Nachricht' verwenden. Wir müssen auch eine Möglichkeit haben, das Spiel zu starten, und zwar durch das 'Aufschlagen des Balls'. AWS CloudWatch Events ist perfekt für diese Aufgabe geeignet. Es sendet eine Nachricht an den Lambda, um das Serving zu starten. Natürlich können Sie nur einmal servieren, also müssen wir das berücksichtigen. Um die Logik zu definieren, genügen einfache Python-Skripte in Kombination mit dem Python SDK für Python. Das Spiel wird mit Hilfe von Sceptre auf AWS bereitgestellt, wobei die gewünschte Statuskonfiguration der serverlosen Infrastruktur mit AWS CloudFormation-Vorlagen definiert wird. Ich glaube, das kann tatsächlich funktionieren!

Die Spieler

Für die Spieler nehmen wir zwei Lambdas, die einfache Python-Skripte ausführen. Ein Lambda heißt 'ping', das das Spiel startet, und das andere heißt 'pong', das darauf reagiert, indem es den Ball zurückschlägt.

Ping Actor:

# remember the serve
started = False

def handler(event, ctx) -> None:
    global started
    if event.get('detail-type'): # cloudwatch event
        if not started:
            started = True
            # hit the ball
            publish(ctx.invoked_function_arn, 'ping-topic', 'ping')
    else: # other event
        # hit the ball
        publish(ctx.invoked_function_arn, 'ping-topic', 'ping')

Pong Schauspieler:

def handler(event, ctx):
    # hit the ball
    publish(ctx.invoked_function_arn, 'pong-topic', 'pong')

Der Spieltisch

Wir können die Tabelle modellieren, indem wir zwei Amazon SNS-Warteschlangen verwenden, die die Nachrichten von einem Akteur empfangen und den Nachrichtenstrom an den anderen Akteur weiterleiten. Die Warteschlangen müssen die Berechtigung haben, die Lambdas aufzurufen.

  PingTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: ping-topic
      Subscription:
      - Endpoint: !GetAtt PongFunction.Arn
        Protocol: lambda

  PongTopic:
    Type: AWS::SNS::Topic
    Properties:
      TopicName: pong-topic
      Subscription:
      - Endpoint: !GetAtt PingFunction.Arn
        Protocol: lambda

  InvokePingPermission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt PingFunction.Arn
      Action: lambda:invokeFunction
      Principal: sns.amazonaws.com
      SourceArn: !Ref PongTopic

  InvokePongPermission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt PongFunction.Arn
      Action: lambda:invokeFunction
      Principal: sns.amazonaws.com
      SourceArn: !Ref PingTopic

Servieren beginnen

Um das Spiel tatsächlich zu starten, muss ein Spieler mit dem Aufschlag beginnen. Der Ping-Akteur hat die Logik dafür bereits eingerichtet. Ein CloudWatch-Ereignis löst den Ping-Actor aus, um das Spiel zu starten. CloudWatch muss die Erlaubnis haben, das Lambda aufzurufen.

  CloudWatchEventsRule:
    Type: AWS::Events::Rule
    Properties:
      ScheduleExpression: rate(1 minute)
      State: ENABLED
      Targets:
      - Arn: !GetAtt PingFunction.Arn
        Id: scheduled-event

  InvokeLambdaPermission:
    Type: AWS::Lambda::Permission
    Properties:
      FunctionName: !GetAtt PingFunction.Arn
      Action: lambda:invokeFunction
      Principal: events.amazonaws.com
      SourceArn: !GetAtt CloudWatchEventsRule.Arn

Beispiel

Das Beispielprojekt zeigt, wie Sie ein Projekt konfigurieren, um ein serverloses Ping-Pong-Spiel zu erstellen. Das Beispiel kann mit make deploy bereitgestellt und mit make delete entfernt werden.

Fazit

Ein Spiel wie Tischtennis ist von Natur aus asynchron. Die Spieler spielen das Spiel, indem sie auf Ereignisse reagieren, die gerade passieren. Wenn ein Ereignis eintritt, müssen die Spieler nur einfache Dinge wie das Zurückschlagen des Balls tun. Serverlose Architekturen sind die perfekte Lösung für asynchrone Prozesse. Durch die Verwendung von Nachrichtenwarteschlangen, asynchroner Nachrichtenübermittlung und serverlosen Berechnungen können reale Prozesse ereignisgesteuert modelliert werden. Ereignisgesteuerte Architekturen (Event Driven Architectures, EDA) wie das Ping-Pong-Spiel, das wir gerade erstellt haben, ermöglichen eine effiziente Nutzung von Rechenzentrumsressourcen und sind ein zentrales Architekturmuster, das für serverloses Cloud Computing unerlässlich ist. Nächstes Mal werden wir uns ansehen, wie wir das, was wir aus dem Ping-Pong-Spiel gelernt haben, anwenden und daraus einige Integrationsmuster ableiten können!