Nautilus

Appearance

Creación de topics ​

Introducción ​

En este apartado se explica el proceso de planteamiento de topics.

Importante: El equipo de Nautilus ofrece un formulario a rellenar para poder realizar la petición de creación de topics. Si necesitas más información, por favor contacta con nosotros.

Convención de nombres ​

Se ha definido una convención de nombres para asegurar que todos los topics cumplan con una nomenclatura en común y así permita distinguirlos y categorizarlos de forma rápida y sencilla.

Se ha de seguir la siguiente nomenglatura:

<product>-<environment>.<type>.<name>_<tenant>
<product>-<environment>.<type>.<name>_<tenant>

  • product: El primer nivel sirve para distinguir los topics de cada producto, que empezarán por su nombre (Ej. iot, acua).

  • environment: Si el topic es para cualquier entorno que no sea productivo, se tiene que incluir en el primer nivel con guión (Ej. iot-dev, acua-pre).

  • type: Actualmente existen tres tipos de topic:

    • event: Es el tipo estándar, donde mandar eventos sobre una entidad (Ej. nautilus.event.contract).
    • command: Este tipo indica que el topic es para envíar comandos (Ej. nautilus.command.sendemail).
    • response: Este tipo indica que el topic es para recibir las respuestas de un comando (Ej. nautilus.response.sendemail).
    • compact: Este tipo indica que el topic es compacto. (Ej. nautilus.compact.account).

  • name: Es el nombre que le damos al topic y puede tener los niveles que se quiera para describir el topic. Se tiene que usar solo el punto y no el guión para distinguir los niveles (Ej. iot.event.s.retry).

  • tenant: Es la identificación del tenant y puede ser lo que uno desee (Ej. iot.event.s.retry_31a7f6b1-2402-4156-bc9f-ccac39cb7e2c).

Importante: Los nombres no pueden incluir barra baja, ya que es el separador especificado para el tenant.

Importante: Para topics internos de una aplicación no usar topics multitenant.

Importante: Ha de valorarse el número de particiones que poseerá el topic a la hora de su creación ya que las particiones pueden reescalarse para aumentar en número pero no para ser reducidas. Además, se aconseja que no se excedan las 4000 particiones por broker y las 200000 por cluster.