View a markdown version of this page

So funktioniert die Lösung - Virtuelles Wartezimmer auf AWS

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.

So funktioniert die Lösung

In diesem Abschnitt werden die Schritte eines Workflows für AWS virtuelle Wartezimmer auf allgemeiner Ebene beschrieben. Einzelheiten zum Erstellen, Anpassen und Integrieren eines Warteraums GitHub für Ihre Website finden Sie im Entwicklerhandbuch unter.

Die öffentliche API des Wartezimmers kann sich hinter der Perimetersicherheit Ihres Standorts befinden oder sie kann ohne Autorisierung verfügbar sein. Je nachdem, welchen Ansatz Sie für die Integration des Warteraums in die Website verwenden, muss sich der Benutzer möglicherweise zuerst auf der Website authentifizieren, bevor er zum Wartezimmer navigieren und sich eine Position in der Warteschlange sichern darf.

Die Client-Software muss über die Event-ID verfügen, um den Warteraum betreten und andere Anfragen stellen zu können. Eine Event-ID ist eine eindeutige ID, die für die meisten Anfragen an öffentliche und private Nutzer erforderlich ist APIs. Die Event-ID wird bei der Installation des Core-API-Stacks festgelegt. Während des Betriebs kann die Event-ID als URL-Parameter oder Cookie über die Warteraum-Seite bereitgestellt werden. Sie kann als Teil von Authentifizierungstoken-Ansprüchen bereitgestellt werden oder sie kann über einen anderen Datenpfad an die Clients verteilt werden.

Es gibt Fälle, in denen der Client sowohl die Event-ID als auch die Anforderungs-ID benötigt, um bestimmte API-Aufrufe zu tätigen. Die Anfrage-ID ist eine eindeutige ID, die vom Wartezimmer ausgestellt wird und einen bestimmten Kunden in der Warteschlange repräsentiert.

Die folgenden Schritte beschreiben den Ablauf von API-Anfragen für den Eintritt in die Warteschlange, das Warten auf den Fortgang der Warteschlange und das Verlassen des Warteraums mit einem Zugriffstoken für die Website.

Der Benutzer betritt den Warteraum:

  1. Dem Benutzer wird ein Bildschirm oder eine Seite angezeigt, die den Eingangspunkt für den Warteraum darstellt. Der Benutzer entscheidet sich dafür, in die Warteschlange einzutreten, und die Client-Software (Browser, Mobilgerät, Gerät) ruft die assign_queue_num öffentliche API auf, um eine Warteschlangenposition anzufordern.

  2. Die API-Anfrage wird sofort von API Gateway an die Amazon SQS SQS-Warteschlange übermittelt.

  3. Der assign_queue_num API-Aufruf kehrt zurück, wenn die Anfrage in die Warteschlange gestellt wird. Der Client erhält eine eindeutige Anforderungs-ID, die später verwendet werden kann, um die Warteschlangenposition, die Uhrzeit der Anfrage und ein Zugriffstoken abzurufen.

  4. Die AssignQueueNum Lambda-Funktion empfängt Stapel von bis zu zehn Anfragen aus der SQS-Warteschlange. Der Lambda-Service fächert Aufrufe auf, um mehrere Batches von Anfragen zu verarbeiten.

  5. Die AssignQueueNum Lambda-Funktion validiert jede Nachricht in ihrem Batch, erhöht den Warteschlangenzähler in Elasticache (Redis OSS) und speichert jede Anfrage in Elasticache (Redis OSS) mit der zugehörigen Warteschlangenposition.

  6. Jede Nachricht wird gelöscht, wenn sie erfolgreich verarbeitet wurde. Nachrichten, bei denen ein Fehler aufgetreten ist, werden in einem späteren Batch einmal erneut verarbeitet. Nach einem zweiten Ausfall werden sie an einen Alarm gesendet, der dead-letter-queue mit einem CloudWatchAlarm verbunden ist.

  7. Der Client kann mit der Abfrage der queue_num API beginnen, nachdem er die Anforderungs-ID aus dem assign_queue_num Anruf erhalten hat. Der Client sendet die Ereignis-ID und die Anforderungs-ID an die queue_num API und erhält eine numerische Warteschlangenposition oder eine Antwort, die angibt, dass die Anfrage noch nicht bearbeitet wurde. Bei großen Ereignissen muss der Client diesen Anruf möglicherweise mehr als einmal tätigen. Die GetQueueNum Lambda-Funktion wird von API Gateway aufgerufen und gibt die numerische Position des Clients in der Warteschlange von DynamoDB zurück.

Der Benutzer wartet im Wartezimmer:

  1. Sobald der Client seine Position in der Warteschlange hat, kann er in regelmäßigen Abständen mit dem Abfragen der serving_num API beginnen. Die serving_num API wird mit der Event-ID aufgerufen und gibt die aktuelle Bereitstellungsposition der Warteschlange zurück. Die Antwort der serving_num API teilt dem Kunden mit, wann er vom Wartezimmer zum eigentlichen Zielstandort wechseln kann, an dem die endgültige Transaktion stattfinden kann. Die GetServingNum Lambda-Funktion gibt die aktuelle Servierposition des Wartezimmers zurück.

  2. Wenn die Bereitstellungsposition gleich oder größer als die Warteschlangenposition (Anfrage) des Clients ist, kann der Client ein JSON-Web-Token (JWT) von der öffentlichen API anfordern. Das Token kann zusammen mit der Ziel-Site verwendet werden, um die Transaktion abzuschließen. Die generate_token API wird mit der Event ID und der Request ID aufgerufen. API Gateway ruft die GenerateToken Lambda-Funktion mit den Parametern auf.

  3. Die GenerateToken Lambda-Funktion validiert die Anfrage und prüft, ob dieses Token zuvor generiert wurde. Die Lambda-Funktion fragt die DynamoDB-Tabelle nach einem passenden Token ab. Wenn dieses Token gefunden wird, wird es an den Aufrufer zurückgegeben und nicht neu generiert. Dieser Prozess verhindert, dass eine einzelne Anforderungs-ID verwendet wird, um mehrere unterschiedliche Token mit neuen Ablaufzeiten zu generieren.

  4. Wenn das Token nicht in DynamoDB gefunden wird, ruft die Lambda-Funktion Schlüssel ab, um das Token zu erstellen, und speichert das Token in DynamoDB mit der Event-ID und der Anforderungs-ID des Clients. Die Lambda-Funktion schreibt ein Ereignis, um EventBridge zu signalisieren, dass ein neues Token generiert wurde. Die Lambda-Funktion erhöht einen Elasticache-Zähler (Redis OSS), der die Anzahl der für das Ereignis generierten Token verfolgt.

  5. Wenn queue_pos_expiry aktiviert, kann der Client die verbleibende Zeit vor ihrem Ablauf abfragen, indem er die queue_pos_expiry API aufruft, die die GetQueuePositionExpiryTime Lambda-Funktion aufruft.

Der Benutzer verlässt das Wartezimmer:

  1. Wenn der Client sein Token erhält, betritt er die Ziel-Site, um mit der Transaktion zu beginnen. Je nachdem, wie Ihre Infrastruktur eine Integration mit JWT unterstützt, muss der Client das Token möglicherweise in einem Anforderungsheader, einem Cookie oder auf andere Weise präsentieren. Der Authorizer für API Gateway kann verwendet werden, um das in der Anfrage eines Kunden enthaltene Token zu validieren. Alle kommerziellen oder Open-Source-Bibliotheken für die Validierung und Verwaltung JWTs können mit Virtual Waiting Room auf Tokens verwendet werden. AWS Wenn das Token gültig ist, darf der Kunde seine Transaktion fortsetzen.

  2. Nachdem der Client seine Transaktion abgeschlossen hat, wird eine private API aufgerufen, um den Status des Kunden-Tokens zu aktualisieren, und wird in DynamoDB abgeschlossen.

Ablauf der Warteschlangenposition:

  1. Wenn diese Funktion aktiviert ist, kann anhand der Anforderungs-ID, die einer bestimmten Warteschlangenposition entspricht, nur für ein bestimmtes Zeitintervall ein Token generiert werden.

Erhöhen Sie den Bereitstellungszähler bei Ablauf der Warteschlangenposition:

  1. Wenn diese Funktion aktiviert ist, wird der Leistungszähler automatisch auf der Grundlage abgelaufener Warteschlangenpositionen erhöht, für die keine Tokens generiert werden konnten.