Il diagramma dell'architettura mostra la distribuzione di servizi OCI, inclusi i nodi di lavoro Kubernetes e i flussi di dati associati, per implementare questa playbook. Contiene un'area OCI e utenti Internet esterni.

L'area OCI comprende una rete cloud virtuale (VCN) che si estende su tre domini di errore e su questi servizi di rete OCI: Contiene anche un gateway API e istanze di OKE, funzioni OCI e coda OCI. L'accesso alla VCN è controllato da un gateway Internet e da un gateway di servizi.

La VCN all'interno dell'area contiene una subnet privata, che a sua volta contiene un cluster OKE. Anche questa subnet occupa i tre domini di errore. Il cluster OKE all'interno della subnet occupa anche i domini di errore e si estende oltre la subnet per contenere la summenzionata istanza OKE. Nel cluster OKE mancano due domini di errore contenenti nodi di lavoro.

All'esterno dell'area, il componente Internet contiene un listener dei messaggi e gruppi di utenti Internet.

Il flusso di dati in questo diagramma viene descritto dai numeri nel diagramma precedente e rappresenta la sequenza di eventi riportata di seguito.
  1. Il producer ospitato localmente inserisce i messaggi nella coda OCI.
  2. Le istanze di consumer OCI recuperano i messaggi dalla coda. All'interno del codice, il tasso di consumo è vincolato utilizzando un ritardo. Ciò garantisce che il provider generi più messaggi che un singolo consumer può rimuovere dalla coda. Di conseguenza, i meccanismi di ridimensionamento funzioneranno.
  3. Periodicamente, un job pianificato Kubernetes supporterà KEDA per richiamare l'API pubblicata per ottenere il numero di messaggi nella coda.
  4. Il gateway API indirizza la richiesta a un'istanza della funzione OCI.
  5. La funzione OCI interroga la coda OCI.
  6. Viene restituita la risposta, che comporterà l'attivazione di un aumento o una riduzione delle istanze del microservizio.
Inoltre, questa implementazione consente all'utente di interrogare in qualsiasi momento lo stato della profondità di coda con l'etichetta a.