Desarrollar la solución

Cada parte de esta solución se ha implantado con Java y utiliza Maven para recuperar las dependencias necesarias, según lo definido por su archivo POM. Incluye un script de shell simple que ejecuta la aplicación llamando a Maven para compilar y ejecutar el código.

Antes de ejecutar el script, debe modificar la clase Environment en cada caso para definir los detalles de conexión adecuados; por ejemplo, el OCID de la cola, la región de despliegue, etc. Para la función y el microservicio, debido a que el código se ejecuta dentro de un contenedor, esto requiere algunos pasos adicionales. El archivo Léame del repositorio describe los pasos necesarios para ajustar el JAR dentro de un contenedor. Antes del despliegue, los artefactos ejecutables para la función y el microservicio alojado por OKE se encuentran en un registro de contenedor (OCIR).

Adaptar el código de productor

La implantación del productor (com.demo.samples.basic.QueueProducer) es muy sencilla, compuesta por un método main y dos métodos adicionales que ayudan a producir el contenido del mensaje. El método main crea los objetos de conexión y transmisión y, a continuación, entra en un bucle infinito de creación de nuevos mensajes y envío de los mismos. Para adaptar la carga útil del método, solo necesita modificar prepareMessage. Actualmente, este método crea un mensaje simple con un GUID y aprovecha el hecho de que la cola de OCI permite a la API enviar veinte mensajes a la vez.

Adaptar el código de consumidor

El consumidor (com.demo.consumer.QueueConsumer) toma su configuración de las variables de entorno transferidas desde la configuración de OKE. Esto facilita la reconfiguración del consumidor en diferentes colas. La mayor parte del trabajo se realiza en el método main que, una vez que tiene una conexión de cola, ejecuta la solicitud de mensajes. Un método de ayuda denominado prepareGetMessageRequest crea la propia solicitud de mensaje. El método identifica la cola específica y define la duración que prepareGetMessageRequeston esperará una respuesta (lo que le permite configurar el sondeo largo) y el número máximo de mensajes (hasta 20) que se pueden devolver.
Una vez recuperados los mensajes, el método processMessage los procesa.

Nota:

En este manual, el proceso simplemente se pone a dormir, aunque debe entender que una aplicación real puede necesitar algún tiempo para procesar el mensaje.
Dado que el método processMessage aplica un thread de suspensión para simular una carga de trabajo de procesamiento de mensajes de backend, verá el funcionamiento del mecanismo de ampliación. Una vez procesados todos los mensajes recibidos, se indica a la cola que los suprima.

Adaptar el código de función de longitud de cola

La función de longitud de cola contiene una clase denominada QueueLength (en el paquete com.example.fn) que se implanta de forma compatible con el funcionamiento de una función de OCI. A su vez, utiliza una clase independiente, GetStats, que utiliza variables de entorno inyectadas por la configuración de la función de OCI para conectarse a la cola y solicita las estadísticas. Los resultados se toman de la respuesta REST y se devuelven en una estructura JSON.

Dada la simplicidad y la toma de decisiones de la escala vertical realizada fuera de la función, no es necesario modificar este código.

Configuración de Valores para Controlar la Escala

Además de configurar los parámetros de proveedor, consumidor y función para que la solución se pueda conectar a una cola, debe configurar los valores para controlar la ampliación implantada mediante KEDA. Puede ver esto en so-object.yaml, que se debe enviar a OKE mediante kubectl (todos los comandos se proporcionan en el archivo Léame correspondiente del repositorio).

La configuración proporciona detalles que describen la frecuencia con la que KEDA necesita disparar la llamada al gateway de API, los límites del número de instancias de servicio de destino permitidas y el nombre del destino. La configuración también incluye la definición del disparador, que indica la URL a la que se debe llamar para obtener la demanda actual, así como el umbral en el que las instancias se pueden ampliar o reducir, incluida la ruta de acceso al objeto JSON devuelto a KEDA para tomar la decisión.