Développement de la solution

Chaque partie de cette solution a été implémentée avec Java et utilise Maven pour extraire les dépendances nécessaires, telles que définies par son fichier POM. Il inclut un script shell simple qui exécute l'application en appelant Maven pour compiler et exécuter le code.

Pour pouvoir exécuter le script, vous devez modifier la classe d'environnement dans chaque cas afin de définir les détails de connexion appropriés. Par exemple, OCID de file d'attente, région de déploiement, etc. Pour la fonction et le microservice, le code étant exécuté dans un conteneur, des étapes supplémentaires sont nécessaires. Le fichier README du référentiel décrit les étapes nécessaires pour encapsuler le fichier JAR dans un conteneur. Avant le déploiement, les artefacts exécutables pour la fonction et le microservice hébergé par OKE se trouvent dans un registre de conteneurs (OCIR).

Personnaliser le code producteur

L'implémentation du producteur (com.demo.samples.basic.QueueProducer) est très simple, composée d'une méthode main et de deux méthodes supplémentaires permettant de produire le contenu du message. La méthode main crée les objets de connexion et de transmission, puis entre dans une boucle infinie de création de messages et de leur envoi. Pour personnaliser les données traitées de la méthode, vous devez uniquement modifier prepareMessage. Actuellement, cette méthode crée un message simple avec un GUID et tire parti du fait qu'OCI Queue permet à l'API d'envoyer vingt messages à la fois.

Personnaliser le code consommateur

Le consommateur (com.demo.consumer.QueueConsumer) utilise sa configuration à partir des variables d'environnement transmises à partir de la configuration OKE. Il est ainsi très facile de reconfigurer le consommateur dans différentes files d'attente. La majeure partie du travail est effectuée dans la méthode main qui, une fois qu'elle dispose d'une connexion de file d'attente, exécute la demande de messages. Une méthode d'aide appelée prepareGetMessageRequest crée la demande de message elle-même. La méthode identifie la file d'attente spécifique et définit la durée pendant laquelle prepareGetMessageRequeston attend une réponse (vous permettant de configurer l'interrogation longue) et le nombre maximal de messages (jusqu'à 20) pouvant être renvoyés.

Une fois les messages extraits, la méthode processMessage les traite.

Remarque :

Dans ce livre de jeux, le processus est simplement mis en veille, bien que vous devriez comprendre qu'une application réelle peut avoir besoin d'un certain temps pour traiter le message.

Lorsque la méthode processMessage applique un thread de veille pour simuler une charge globale de traitement des messages back-end, le mécanisme de redimensionnement fonctionne. Une fois tous les messages reçus traités, il est demandé à la file d'attente de les supprimer.

Personnaliser le code fonction de longueur de file d'attente

La fonction de longueur de file d'attente contient une classe nommée QueueLength (dans le package com.example.fn) qui est implémentée conformément à la façon dont une fonction OCI doit fonctionner. Cela utilise à son tour une classe distincte, GetStats, qui utilise les variables d'environnement injectées par la configuration de la fonction OCI pour se connecter à la file d'attente et demande les statistiques. Les résultats sont extraits de la réponse REST et renvoyés dans une structure JSON.

Compte tenu de la simplicité et de la décision de l'échelle verticale effectuée en dehors de la fonction, vous n'avez guère besoin de modifier ce code.

Configuration des paramètres pour contrôler la mise à l'échelle

Au-delà de la configuration des paramètres de fournisseur, de consommateur et de fonction afin que la solution puisse se connecter à une file d'attente, vous devez configurer les paramètres permettant de contrôler la mise à l'échelle implémentée à l'aide de KEDA. Vous pouvez le voir dans so-object.yaml, qui doit être envoyé à OKE à l'aide de kubectl (toutes les commandes sont fournies dans le fichier README approprié du référentiel).

La configuration fournit des détails décrivant la fréquence à laquelle KEDA doit déclencher l'appel vers API Gateway, les limites sur le nombre d'instances de service cible autorisées et le nom de la cible. La configuration inclut également la définition du déclencheur, qui indique l'URL à appeler pour obtenir la demande en cours, ainsi que le seuil auquel les instances peuvent augmenter ou réduire, y compris le chemin vers l'objet JSON renvoyé à KEDA pour prendre la décision.