Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Azure DevOps
Los arquitectos y desarrolladores tienen dificultades para definir el tamaño correcto para un microservicio. Las instrucciones a menudo enfatizan la evitación de extremos demasiado grandes o demasiado pequeños, pero ese consejo puede ser impreciso en la práctica. Pero si empieza desde un modelo de dominio cuidadosamente diseñado, puede definir más fácilmente el tamaño y el ámbito correctos de cada microservicio.
En este artículo se usa un servicio de entrega de drones como ejemplo en ejecución. Puede leer más sobre el escenario y la implementación de referencia correspondiente aquí.
De modelo de dominio a microservicios
En el artículo anterior, definimos un conjunto de contextos enlazados para una aplicación Drone Delivery. A continuación, examinamos más detenidamente uno de estos contextos enlazados, el contexto enlazado Shipping y identificamos un conjunto de entidades, agregados y servicios de dominio para ese contexto enlazado.
Ahora estamos listos para pasar del modelo de dominio al diseño de aplicaciones. Este es un enfoque que puede usar para derivar microservicios del modelo de dominio.
Comience con un contexto delimitado. En general, la funcionalidad de un microservicio no debe abarcar más de un contexto enlazado. Por definición, un contexto enlazado marca el límite de un modelo de dominio específico. Si encuentra que un microservicio combina diferentes modelos de dominio, es posible que tenga que volver atrás y refinar el análisis de dominio.
A continuación, examine los agregados en el modelo de dominio. Los agregados suelen ser buenos candidatos para microservicios. Un agregado bien diseñado muestra muchas de las características de un microservicio bien diseñado:
- Un agregado se deriva de los requisitos empresariales, en lugar de problemas técnicos, como el acceso a datos o la mensajería.
- Un agregado debe tener una cohesión funcional alta.
- Un agregado es un límite de persistencia.
- Los agregados deben acoplarse de forma flexible.
Los servicios de dominio también son buenos candidatos para microservicios. Los servicios de dominio son operaciones sin estado en varios agregados. Un ejemplo típico es un flujo de trabajo que incluye varios microservicios. La aplicación Drone Delivery muestra un ejemplo.
Considere los requisitos no funcionales. Examine factores como el tamaño del equipo, los tipos de datos, las tecnologías, los requisitos de escalabilidad, los requisitos de disponibilidad y los requisitos de seguridad. Estos factores pueden provocar que se interrumpa un microservicio en varios servicios más pequeños. En otros casos, pueden provocar que combine varios microservicios en un solo microservicio.
Después de identificar los microservicios de la aplicación, valide el diseño con los criterios siguientes:
Cada servicio tiene una sola responsabilidad.
No hay llamadas entre servicios. Si la división de la funcionalidad en dos servicios hace que sean demasiado chatsas, podría ser un síntoma de que estas funciones pertenecen al mismo servicio.
Cada servicio es lo suficientemente pequeño como para que un equipo pequeño trabaje de forma independiente.
No hay ninguna dependencia que requiera que se implementen dos o más servicios juntos. Cada servicio debe implementarse de forma independiente, sin necesidad de volver a implementar otros.
Los servicios no están estrechamente acoplados y pueden evolucionar de forma independiente.
Los límites de servicio están diseñados para evitar problemas de coherencia o integridad de los datos. En algunos casos, mantener la coherencia de los datos significa agrupar la funcionalidad relacionada en un solo microservicio. Sin embargo, la coherencia fuerte no siempre es necesaria. Los sistemas distribuidos proporcionan estrategias para controlar la coherencia final y las ventajas de descomponer los servicios suelen superar la complejidad de administrarlos.
Sobre todo, es importante ser pragmático y recordar que el diseño controlado por dominio es un proceso iterativo. En caso de duda, comience con microservicios más generales. Dividir un microservicio en dos servicios más pequeños es más fácil que refactorizar la funcionalidad en varios microservicios existentes.
Ejemplo: Definición de microservicios para la aplicación Drone Delivery
El equipo de desarrollo identificó previamente los cuatro agregados, Entrega, Paquete, Drone y Cuenta, y dos servicios de dominio, Scheduler y Supervisor.
La entrega y el paquete son candidatos obvios para los microservicios. Scheduler y Supervisor coordinan las actividades realizadas por otros microservicios, por lo que tiene sentido implementar estos servicios de dominio como microservicios.
Drone y Account son interesantes porque pertenecen a otros contextos enlazados. Una opción es que scheduler llame directamente a los contextos enlazados drone y account. Otra opción es crear microservicios Drone y Account dentro del contexto enlazado Envío. Estos microservicios mediarían entre los contextos enlazados, mediante la exposición de API o esquemas de datos más adecuados para el contexto de envío.
Los detalles de los contextos enlazados Drone y Account están fuera del ámbito de esta guía, por lo que creamos servicios ficticios para ellos en nuestra implementación de referencia. Pero estos son algunos factores que se deben tener en cuenta en esta situación:
¿Cuál es la sobrecarga de red de llamar directamente al otro contexto enlazado?
¿Es adecuado el esquema de datos para el otro contexto enlazado para este contexto o es mejor tener un esquema adaptado a este contexto limitado?
¿El otro contexto enlazado es un sistema heredado? Si es así, puede crear un servicio que actúe como una capa contra daños para traducir entre el sistema heredado y la aplicación moderna.
¿Cuál es la estructura del equipo? ¿Es fácil comunicarse con el equipo responsable del otro contexto limitado? Si no es así, crear un servicio que media entre los dos contextos puede ayudar a mitigar el costo de la comunicación entre equipos.
Hasta ahora, el equipo no ha considerado ningún requisito no funcional. Después de evaluar las necesidades de rendimiento de la aplicación, el equipo de desarrollo crea un microservicio de ingesta independiente para controlar las solicitudes de cliente. Este microservicio implementa la ordenación de carga colocando solicitudes entrantes en un búfer para su procesamiento. A continuación, scheduler lee las solicitudes del búfer e implementa el flujo de trabajo.
Los requisitos no funcionales también llevan al equipo a crear un servicio más. Los servicios existentes se centran en programar y entregar paquetes en tiempo real. Sin embargo, el sistema también debe almacenar el historial de entrega en el almacenamiento a largo plazo para el análisis de datos. Inicialmente, el equipo considera que esta tarea forma parte del servicio de entrega. Pero los requisitos de almacenamiento de datos para el análisis histórico difieren de los requisitos de las operaciones en curso. Para obtener más información, consulte Consideraciones sobre los datos. Como resultado, el equipo creó un servicio de historial de entrega independiente. Este servicio escucha los eventos DeliveryTracking del servicio de entrega y los escribe en el almacenamiento a largo plazo.
En el diagrama siguiente se muestra el diseño en este punto:
Descargar un archivo de Visio de esta arquitectura.
Pasos siguientes
En este momento, debe tener una comprensión clara del propósito y la funcionalidad de cada microservicio en el diseño. Ahora puede diseñar el sistema.