Primeros planteamientos de la Arquitectura de Microservicios

[dmlls]

Generar un diseño preliminar de cómo se organizarán los diferentes microservicios que componen el sistema.

[dmlls]

Se ha decidido que se seguirá el patrón de API Gateway, en el que para el cliente existe un único punto de conexión, Ese punto de conexión, por detrás, realiza las peticiones necesarias a los diferentes microservicios de manera transparente al cliente.

Fuente de la imagen.

En nuestro caso, el cliente realizaría una petición al API Gateway incluyendo el texto a traducir. El API Gateway se comunicaría con los distintos microservicios (pre-procesador, motor de resumen, post-procesador, etc.) a fin de confeccionar el resumen, y finalmente respondería al cliente con el resumen generado.

Este patrón, además, ofrece la ventaja de que se puede llevar la adición, eliminación o refactorización de los microservicios, sin que el cliente tenga que preocuparse de estos cambios.

[clopezno]

Me parece correcto el patrón arquitectónico que has elegido. Yo no le hubiera elegido mejor ;-)

Pero creo que deberíamos definir los microservicios y su interfaz concreta para nuestro framework de resumen de textos. Quizás un diagrama UML generado con draw.io nos puede ayudar a describir gráficamente la arquitectura.

Saludos Carlos López

[dmlls]

Totalmente de acuerdo, Carlos.

Se trata de una historia de usuario en progreso, estoy considerando diferentes patrones de diseño en profundidad, para determinar cuál se adaptaría mejor a nuestra situación.

El output esperado de esta historia de usuario es un diagrama como el que propones.

[clopezno]

He estado dando una vuelta al diseño arquitectónico y entiendo que la comunicación entre mcro servicios en nuestro framework de resumen de nlp es un patrón arquitectónico clásico de filtro tubería. Pero tengo mis dudas si con el modelo de microservicios encaja service mesh para mediar en la gestión del flujo (filtro-tubería) los diferentes modelos preentrenados https://microservices.io/patterns/deployment/service-mesh.html .

[dmlls]

En mi opinión el patrón de routing slips podría encajar muy bien en nuestro workflow. He estado valorando hasta qué punto sería nesario un elemento adicional encargado de la orquestración de los microservicios. El link adjuntado anteriormente ha resuelto todas mis dudas: en el patrón routing slips "the process of steps is well-defined and known up front, and individual steps shouldn’t need to make decisions about what’s next. Nor is there a need for a central controller to figure out the next step – we already know the steps up front!".

Es exactamente nuestro caso, los pasos están bien definidos y deben serguir un orden estricto: preprocesado, motor de resumen, post-procesado.

Sin embargo, en nuestro caso sería también necesaria la adición de mecanismos asíncronos, puesto que el proceso de resumen puede demorarse en el tiempo; no es una tarea instantánea. Además, pensando en la escalabilidad del sistema, será necesario diseñar la política de servicio de las peticiones. Aunque varias instancias de estos microservicios se ejecutarán en paralelo gracias a Docker y Kubernetes, parece evidente que el uso de colas será también necesario.

Algunos puntos de partida para este último punto pueden ser los siguientes links:

• https://stackoverflow.com/questions/33009721/long-running-rest-api-with-queues
• http://billhiggins.us/blog/2011/04/27/resty-long-ops/

[clopezno]

Como bien indicas el patrón routing slips nos gestiona el flujo de trabajo (filtro y tuberia), pero mi duda es ¿cómo se modelan y orquestan las variantes del servicio que pertenecen a cada modelo de NLP preentrenado? Me explico, si solo se considera un servicio de preprocesado independiente del modelo ¿cómo sabe el motor de resumen que modelo aplicar?

[dmlls]

La arquitectura final se explica con detalle en la Issue #67.