Sviluppa la soluzione
Ogni parte di questa soluzione è stata implementata con Java e utilizza Maven per recuperare le dipendenze necessarie, come definito dal relativo file POM. Include uno script semplice della shell che esegue l'applicazione richiamando Maven per compilare ed eseguire il codice.
Prima di poter eseguire lo script, è necessario modificare la classe Ambiente in ogni caso per definire i dettagli di connessione appropriati, ad esempio l'OCID coda, l'area di distribuzione e così via. Per la funzione e il microservizio, poiché il codice viene eseguito all'interno di un contenitore, ciò richiede alcuni passi aggiuntivi. Il file Readme nel repository descrive i passi necessari per eseguire il wrapping del file JAR all'interno di un contenitore. Prima della distribuzione, gli artefatti eseguibili sia per la funzione che per il microservizio ospitato da OKE si trovano in un Container Registry (OCIR).
Personalizzare il codice del producer
com.demo.samples.basic.QueueProducer) è molto semplice, è costituita da un metodo main e da due metodi aggiuntivi che contribuiscono a produrre il contenuto del messaggio. Il metodo main crea gli oggetti di connessione e trasmissione, quindi passa a un ciclo infinito di creazione di nuovi messaggi e di invio. Per personalizzare il payload, è sufficiente modificare prepareMessage. Al momento, questo metodo crea un messaggio semplice con un GUID e sfrutta il fatto che la coda OCI consente all'API di inviare venti messaggi alla volta.
Personalizza codice consumatore
com.demo.consumer.QueueConsumer) recupera la propria configurazione dalle variabili di ambiente sottoposte a push dalla configurazione di OKE. Ciò semplifica notevolmente la riconfigurazione del consumatore in code diverse. La maggior parte del lavoro viene eseguita con il metodo main che, una volta stabilita una connessione alla coda, esegue la richiesta di messaggi. Un metodo di supporto denominato prepareGetMessageRequest crea la richiesta di messaggio. Il metodo identifica la coda specifica e imposta la durata che prepareGetMessageRequeston attenderà per una risposta (permettendo di configurare il polling a lungo termine) e il numero massimo di messaggi (fino a 20) che possono essere restituiti.
processMessage li elabora.
Nota:
In questa playbook, il processo è semplicemente messo in sonno, anche se si dovrebbe capire che una vera applicazione potrebbe avere bisogno di un po 'di tempo per elaborare il messaggio.processMessage applica l'interruzione di un thread per simulare un carico di lavoro di elaborazione di un messaggio backend, il meccanismo di ridimensionamento funzionerà. Una volta elaborati tutti i messaggi ricevuti, viene richiesto alla coda di eliminarli.
Personalizzare il codice della funzione Lunghezza coda
QueueLength (nel package com.example.fn) che viene implementata in modo conforme al funzionamento di una funzione OCI. A sua volta, utilizza una classe separata, GetStats, che utilizza le variabili di ambiente inserite dalla configurazione della funzione OCI per connettersi alla coda e richiedere le statistiche. I risultati vengono recuperati dalla risposta REST e restituiti in una struttura JSON.
Data la semplicità e la decisione del ridimensionamento verticale eseguito al di fuori della funzione, non è necessario modificare questo codice.
Configurazione delle impostazioni per controllare il ridimensionamento
so-object.yaml, che deve essere inviato a OKE utilizzando kubectl (tutti i comandi vengono forniti nel file Readme rilevante nel repository).
La configurazione fornisce i dettagli che descrivono la frequenza con cui KEDA deve attivare la chiamata al gateway API, i limiti del numero di istanze del servizio di destinazione consentite e il nome della destinazione. La configurazione include inoltre la definizione del trigger, che indica l'URL da richiamare per ottenere la domanda corrente e la soglia alla quale è possibile eseguire lo scale-up o lo scale-down delle istanze, incluso il percorso dell'oggetto JSON restituito a KEDA per prendere la decisione.