Le diagramme d'architecture indique le déploiement des services OCI, y compris les noeuds de processus actif Kubernetes et les flux de données associés, pour implémenter ce livre de jeux. Il contient une région OCI et des utilisateurs Internet externes.

La région OCI comprenait un réseau cloud virtuel (VCN) qui couvre trois domaines de pannes et ces services réseau OCI : Il contient également une passerelle d'API et des instances d'OKE, d'OCI Functions et d'OCI Queue. L'accès au VCN est contrôlé par une passerelle Internet et une passerelle de service.

Le VCN de la région contient un sous-réseau privé qui contient lui-même un cluster OKE. Ce sous-réseau couvre également les trois domaines de pannes. Le cluster OKE du sous-réseau couvre également les domaines de pannes et s'étend au-delà du sous-réseau pour contenir l'instance OKE susmentionnée. Dans OKE, deux des domaines de pannes contiennent des noeuds de processus actif.

En dehors de la région, le composant Internet contient un processus d'écoute de messages et des groupes d'utilisateurs Internet.

Le flux de données de ce diagramme est décrit par des numéros dans le diagramme précédent et représente cette séquence d'événements :
  1. Le producteur hébergé localement place les messages dans la file d'attente OCI.
  2. Nos instances de consommateur OCI extraient des messages de la file d'attente. Dans le code, le taux de consommation est limité en utilisant un délai. Cela garantit que le fournisseur génère plus de messages qu'un seul consommateur ne peut les supprimer de la file d'attente. En conséquence, les mécanismes de redimensionnement fonctionneront.
  3. Périodiquement, un travail programmé Kubernetes prendra en charge KEDA pour appeler l'API publiée afin d'obtenir le nombre de messages dans la file d'attente.
  4. API Gateway dirige la demande vers une instance de la fonction OCI.
  5. La fonction OCI interroge la file d'attente OCI.
  6. La réponse est renvoyée, ce qui entraîne le déclenchement par KEDA d'une augmentation ou d'une diminution des instances du microservice.
De plus, cette implémentation permet également à l'utilisateur d'interroger à tout moment l'état de la profondeur de la file d'attente est étiqueté a.