Compartir a través de

Soberanía de datos por microservicio

Sugerencia

Este contenido es un extracto del libro electrónico, ".NET Microservices Architecture for Containerized .NET Applications" (Arquitectura de microservicios de .NET para aplicaciones de .NET contenedorizadas), disponible en Documentación de .NET o como un PDF descargable y gratuito que se puede leer sin conexión.

Descargar PDF

Miniatura de la portada del libro electrónico 'Arquitectura de microservicios de .NET para aplicaciones .NET contenedorizadas'.

Una regla importante para la arquitectura de microservicios es que cada microservicio debe poseer sus datos de dominio y lógica. Al igual que una aplicación completa posee su lógica y sus datos, por lo que cada microservicio tiene su lógica y sus datos en un ciclo de vida autónomo, con implementación independiente por microservicio.

Esto significa que el modelo conceptual del dominio variará entre subsistemas o microservicios. Considere las aplicaciones empresariales, donde las aplicaciones de administración de relaciones con el cliente (CRM), los subsistemas de compra transaccional y los subsistemas de soporte al cliente utilizan atributos y datos únicos de entidades de cliente, y donde cada uno emplea un contexto delimitado (BC) diferente.

Este principio es similar en el diseño controlado por dominio (DDD), donde cada contexto enlazado o subsistema o servicio autónomo debe poseer su modelo de dominio (datos más lógica y comportamiento). Cada contexto enlazado de DDD se correlaciona con un microservicio empresarial (uno o varios servicios). Este punto sobre el patrón de Contexto Delimitado se expande en la sección siguiente.

Por otro lado, el enfoque tradicional (datos monolíticos) que se usa en muchas aplicaciones es tener una base de datos centralizada única o solo algunas bases de datos. Suele ser una base de datos SQL normalizada que se usa para toda la aplicación y todos sus subsistemas internos, como se muestra en la figura 4-7.

Diagrama que muestra los dos enfoques de la base de datos.

Figura 4-7. Comparación de soberanía de datos: base de datos monolítica frente a microservicios

En el enfoque tradicional, hay una base de datos única compartida en todos los servicios, normalmente en una arquitectura en capas. En el enfoque de microservicios, cada microservicio posee su modelo o datos. El enfoque centralizado de la base de datos se ve inicialmente más sencillo y parece permitir la reutilización de entidades en distintos subsistemas para que todo sea coherente. Pero la realidad es que termina con tablas enormes que sirven a muchos subsistemas diferentes y que incluyen atributos y columnas que no son necesarios en la mayoría de los casos. Es como intentar usar el mismo mapa físico para hacer senderismo en una ruta corta, realizar un viaje en coche de un día y aprender geografía.

Una aplicación monolítica con normalmente una base de datos relacional única tiene dos ventajas importantes: transacciones ACID y el lenguaje SQL, que funcionan en todas las tablas y datos relacionados con la aplicación. Este enfoque proporciona una manera de escribir fácilmente una consulta que combina datos de varias tablas.

Sin embargo, el acceso a datos se vuelve mucho más complicado al pasar a una arquitectura de microservicios. Incluso cuando se usan transacciones ACID dentro de un microservicio o contexto enlazado, es fundamental tener en cuenta que los datos que pertenecen a cada microservicio son privados para ese microservicio y solo se debe tener acceso de forma sincrónica a través de sus puntos de conexión de API (REST, gRPC, SOAP, etc.) o de forma asincrónica a través de mensajería (AMQP o similar).

Encapsular los datos garantiza que los microservicios están acoplados de forma flexible y pueden evolucionar independientemente entre sí. Si varios servicios tuvieran acceso a los mismos datos, las actualizaciones de esquema requerirían actualizaciones coordinadas para todos los servicios. Esto interrumpiría la autonomía del ciclo de vida del microservicio. Pero las estructuras de datos distribuidas significan que no se puede realizar una sola transacción ACID entre microservicios. Esto a su vez significa que debe usar la consistencia eventual cuando un proceso de negocio abarca varios microservicios. Esto es mucho más difícil de implementar que las combinaciones SQL simples, ya que no se pueden crear restricciones de integridad ni usar transacciones distribuidas entre bases de datos independientes, como explicaremos más adelante. Del mismo modo, muchas otras características de base de datos relacionales no están disponibles en varios microservicios.

A menudo, los microservicios diferentes usan diferentes tipos de bases de datos. Las aplicaciones modernas almacenan y procesan diversos tipos de datos y una base de datos relacional no siempre es la mejor opción. En algunos casos de uso, una base de datos NoSQL, como Azure CosmosDB o MongoDB, podría tener un modelo de datos más conveniente y ofrecer un mejor rendimiento y escalabilidad que una base de datos SQL como SQL Server o Azure SQL Database. En otros casos, una base de datos relacional sigue siendo el mejor enfoque. Por lo tanto, las aplicaciones basadas en microservicios suelen utilizar una mezcla de bases de datos SQL y NoSQL, que a veces se denomina enfoque de persistencia políglota.

Una arquitectura con particiones de persistencia políglota para el almacenamiento de datos tiene muchas ventajas. Estos incluyen servicios acoplados de forma flexible y un mejor rendimiento, escalabilidad, costos y capacidad de administración. Sin embargo, puede presentar algunos desafíos de administración de datos distribuidos, como se explica en "Identificación de límites del modelo de dominio" más adelante en este capítulo.

Relación entre microservicios y el patrón de contexto enlazado

El concepto de microservicio se deriva del patrón de Contexto Delimitado (BC) en diseño dirigido por el dominio (DDD). DDD trabaja con modelos grandes al dividirlos en varios contextos enlazados y ser explícito sobre sus límites. Cada BC debe tener su propio modelo y base de datos; del mismo modo, cada microservicio posee sus datos relacionados. Además, cada BC suele tener su propio lenguaje omnipresente para ayudar a la comunicación entre desarrolladores de software y expertos en dominios.

Esos términos (principalmente entidades de dominio) en el lenguaje omnipresente pueden tener nombres diferentes en contextos enlazados diferentes, incluso cuando diferentes entidades de dominio comparten la misma identidad (es decir, el identificador único que se usa para leer la entidad del almacenamiento). Por ejemplo, en un contexto enlazado de perfil de usuario, la entidad de dominio User puede compartir identidad con la entidad de dominio Buyer en el contexto enlazado Ordering.

Por lo tanto, un microservicio es como un contexto enlazado, pero también especifica que es un servicio distribuido. Se crea como un proceso independiente para cada contexto enlazado y debe usar los protocolos distribuidos indicados anteriormente, como HTTP/HTTPS, WebSockets o AMQP. Sin embargo, el patrón de contexto enlazado no especifica si el contexto enlazado es un servicio distribuido o si es simplemente un límite lógico (como un subsistema genérico) dentro de una aplicación de implementación monolítica.

Es importante resaltar que definir un servicio para cada contexto delimitado es un buen punto de partida. Pero no tienes que limitar tu diseño a eso. A veces, debe diseñar un microservicio de contexto enlazado o empresarial compuesto por varios servicios físicos. Pero en última instancia, ambos patrones -Bounded Contexto y microservicio- están estrechamente relacionados.

DDD se beneficia de los microservicios obteniendo límites reales en forma de microservicios distribuidos. Pero el concepto de no compartir el modelo entre microservicios es algo que también se busca en un Contexto Delimitado.

Recursos adicionales

Siguiente anterior