Lösung entwickeln

Jeder Teil dieser Lösung wurde mit Java implementiert und verwendet Maven, um die erforderlichen Abhängigkeiten gemäß der POM-Datei abzurufen. Sie enthält ein einfaches Shellskript, mit dem die Anwendung ausgeführt wird, indem Maven aufgerufen wird, um den Code zu kompilieren und auszuführen.

Bevor Sie das Skript ausführen können, müssen Sie die Umgebungsklasse jeweils ändern, um die entsprechenden Verbindungsdetails zu definieren, z.B. die Queue-OCID, die Deployment-Region usw. Für die Funktion und den Microservice sind einige zusätzliche Schritte erforderlich, da der Code in einem Container ausgeführt wird. Die Readme-Datei im Repository beschreibt die Schritte, die zum Umschließen der JAR-Datei in einen Container erforderlich sind. Vor dem Deployment befinden sich die ausführbaren Artefakte für die Funktion und den von OKE gehosteten Microservice in einer Container Registry (OCIR).

Herstellercode anpassen

Die Producer-Implementierung (com.demo.samples.basic.QueueProducer) ist sehr einfach und besteht aus einer main-Methode und zwei zusätzlichen Methoden, mit denen der Nachrichteninhalt erstellt werden kann. Die Methode main erstellt die Verbindungs- und Übertragungsobjekte und geht dann in eine Endlosschleife, in der neue Nachrichten erstellt und gesendet werden. Um die Payload der Methode anzupassen, müssen Sie nur prepareMessage ändern. Derzeit erstellt diese Methode eine einfache Nachricht mit einer GUID und nutzt die Tatsache, dass die OCI-Queue es der API ermöglicht, zwanzig Nachrichten gleichzeitig zu senden.

Kundencode anpassen

Der Consumer (com.demo.consumer.QueueConsumer) verwendet seine Konfiguration aus Umgebungsvariablen, die aus der OKE-Konfiguration durchgeschoben wurden. Dadurch ist es sehr einfach, den Consumer in verschiedene Queues neu zu konfigurieren. Der Großteil der Arbeit wird in der Methode main ausgeführt, die nach einer Queueverbindung die Anforderung für Nachrichten ausführt. Eine Helper-Methode mit dem Namen prepareGetMessageRequest erstellt die Nachrichtenanforderung selbst. Die Methode identifiziert die spezifische Queue und legt die Dauer fest, die prepareGetMessageRequeston auf eine Antwort wartet (d.h. Sie können langes Polling konfigurieren) und die maximale Anzahl von Nachrichten (bis zu 20), die zurückgegeben werden können.

Nachdem die Nachrichten abgerufen wurden, verarbeitet die Methode processMessage sie.

Hinweis:

In diesem Playbook wird der Prozess einfach eingeschaltet, obwohl Sie verstehen sollten, dass eine echte Anwendung möglicherweise etwas Zeit für die Verarbeitung der Nachricht benötigen.

Wenn die Methode processMessage einen Thread-Schlaf anwendet, um eine Workload zur Verarbeitung von Backend-Nachrichten zu simulieren, wird das Skalierungsverfahren angezeigt. Nachdem alle empfangenen Nachrichten verarbeitet wurden, wird der Queue mitgeteilt, sie zu löschen.

Funktionscode für Warteschlangenlänge anpassen

Die Queue-Längenfunktion enthält die Klasse QueueLength (in Package com.example.fn), die so implementiert wird, dass eine OCI-Funktion konform ist. Dies wiederum verwendet die separate Klasse GetStats, die Umgebungsvariablen verwendet, die von der Konfiguration der OCI-Funktion injiziert wurden, um eine Verbindung zur Queue herzustellen und die Statistiken anzufordern. Die Ergebnisse werden aus der REST-Antwort übernommen und in einer JSON-Struktur zurückgegeben.

Angesichts der Einfachheit und der Entscheidung über die vertikale Skalierung, die außerhalb der Funktion ausgeführt wird, müssen Sie diesen Code nur wenig ändern.

Einstellungen zur Kontrolle der Skalierung konfigurieren

Neben der Konfiguration der Provider-, Consumer- und Funktionsparameter, damit die Lösung eine Verbindung zu einer Queue herstellen kann, müssen Sie die Einstellungen konfigurieren, um die mit KEDA implementierte Skalierung zu steuern. Dies wird in so-object.yaml angezeigt, die mit kubectl an OKE gesendet werden muss (alle Befehle werden in der entsprechenden Readme-Datei im Repository bereitgestellt).

Die Konfiguration enthält Details dazu, wie oft KEDA den Aufruf des API-Gateways auslösen muss, sowie Grenzwerte für die zulässige Anzahl von Zielserviceinstanzen und den Namen des Ziels. Die Konfiguration enthält auch die Triggerdefinition, die angibt, welche URL zum Abrufen des aktuellen Bedarfs aufgerufen werden soll, sowie den Schwellenwert, bei dem Instanzen vertikal oder horizontal skaliert werden können, einschließlich des Pfads zum JSON-Objekt, das an KEDA zurückgegeben wird, um die Entscheidung zu treffen.