Diseño de aplicaciones basadas en contenedores y microservicios

Los microservicios ofrecen grandes ventajas, pero también generan grandes desafíos nuevos. Los patrones de arquitectura de microservicios son pilares fundamentales al crear una aplicación basada en microservicios.

Anteriormente en esta guía, ha aprendido conceptos básicos sobre contenedores y Docker. Esa información era el mínimo necesario para empezar a trabajar con contenedores. Aunque los contenedores son habilitadores de y una excelente opción para los microservicios, no son obligatorios para una arquitectura de microservicios. Muchos conceptos arquitectónicos de esta sección de arquitectura se podrían aplicar sin contenedores. Sin embargo, esta guía se centra en la intersección de ambos debido a la importancia ya introducida de los contenedores.

Las aplicaciones empresariales pueden ser complejas y a menudo se componen de varios servicios en lugar de una sola aplicación basada en servicios. Para esos casos, debe comprender otros enfoques arquitectónicos, como los microservicios y ciertos patrones de diseño de Domain-Driven (DDD), además de conceptos de orquestación de contenedores. Tenga en cuenta que en este capítulo se describen no solo microservicios en contenedores, sino también cualquier aplicación en contenedor.

Principios de diseño de contenedores

En el modelo de contenedor, una instancia de imagen de contenedor representa un único proceso. Al definir una imagen de contenedor como límite de proceso, puede crear primitivos que se pueden usar para escalar o procesar por lotes el proceso.

Al diseñar una imagen de contenedor, visualizarás una definición ENTRYPOINT en el Dockerfile. Esta definición define el proceso cuya duración controla la duración del contenedor. Cuando se completa el proceso, finaliza el ciclo de vida del contenedor. Los contenedores pueden representar procesos de ejecución prolongada como servidores web, pero también pueden representar procesos de corta duración, como trabajos por lotes, que anteriormente podrían haberse implementado como Azure WebJobs.

Si se produce un error en el proceso, el contenedor finaliza y lo sustituye el orquestador. Si el orquestador se configuró para mantener cinco instancias en ejecución y se produce un error, el orquestador creará otra instancia de contenedor para reemplazar el proceso con errores. En un trabajo por lotes, el proceso se inicia con parámetros. Cuando el proceso finaliza, el trabajo está terminado. Más adelante en esta guía se exploran en profundidad los orquestadores.

Es posible que encuentre un escenario en el que quiera que varios procesos se ejecuten en un único contenedor. En ese escenario, dado que solo puede haber un punto de entrada por contenedor, podría ejecutar un script dentro del contenedor que inicie tantos programas como sea necesario. Por ejemplo, puede usar Supervisor o una herramienta similar para encargarse de iniciar varios procesos dentro de un único contenedor. Sin embargo, aunque puede encontrar arquitecturas que contienen varios procesos por contenedor, ese enfoque no es muy común.