Identificación de los límites de microservicios
¿Cuál es el tamaño adecuado para un microservicio? A menudo escuchas algo sobre el efecto de, "no demasiado grande y no demasiado pequeño", y aunque eso es ciertamente correcto, no es muy útil en la práctica. Pero si empieza desde un modelo de dominio cuidadosamente diseñado, es mucho más fácil razonar sobre los microservicios.
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 determinado. Si encuentra que un microservicio combina diferentes modelos de dominio, es un signo que puede 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, como:
- 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 implica varios microservicios. Veremos un ejemplo de esto en la aplicación Drone Delivery.
Por último, 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 llevar a descomponer aún más un microservicio en dos o más servicios más pequeños, o bien hacer lo contrario y combinar varios microservicios en uno.
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, puede 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 dependencias entre dependencias que requieran que se implementen dos o más servicios en el paso de bloqueo. Siempre debe ser posible implementar un servicio sin volver a implementar ningún otro servicio.
- Los servicios no están estrechamente acoplados y pueden evolucionar de forma independiente.
- Los límites del servicio no crearán problemas con la coherencia o integridad de los datos. A veces es importante mantener la coherencia de los datos colocando la funcionalidad en un solo microservicio. Dicho esto, considere si realmente necesita una coherencia fuerte. Hay estrategias para abordar la coherencia final en un sistema distribuido y las ventajas de descomponer los servicios suelen superar los desafíos de administrar la coherencia final.
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
Recuerde que el equipo de desarrollo había identificado 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, no hemos considerado ningún requisito no funcional. Pensando en los requisitos de rendimiento de la aplicación, el equipo de desarrollo decidió crear un microservicio de ingesta independiente responsable de la ingesta de solicitudes de cliente. Este microservicio implementará la ordenación de carga colocando las solicitudes entrantes en un búfer para su procesamiento. Scheduler leerá las solicitudes del búfer y ejecutará el flujo de trabajo.
Los requisitos no funcionales llevaron al equipo a crear un servicio adicional. Todos los servicios hasta ahora han sido sobre el proceso de programación y entrega de paquetes en tiempo real. Pero el sistema también debe almacenar el historial de todas las entregas en el almacenamiento a largo plazo para el análisis de datos. El equipo consideró la responsabilidad del servicio de entrega. Sin embargo, los requisitos de almacenamiento de datos son bastante diferentes para el análisis histórico frente a las operaciones en curso (consulte Consideraciones sobre los datos). Por lo tanto, el equipo decidió crear un servicio de historial de entrega independiente, que escuchará los eventos deliveryTracking del servicio de entrega y escribirá los eventos en 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.