APIs y MicroServicios en Empresas Monolíticas — Diseño de base de datos— Data Management #5
Cuando iniciamos el proceso del diseño o migración de aplicaciones a un patron de microservicios, debemos de realizarnos la siguiente pregunta.
¿Cuál es la arquitectura de la base de datos en un producto de microservicios?
Nuestros microservicios se deben de acoplar libremente y escalar de forma independiente, perooooooooooooo,
algunas transacciones de negocio pueden abarcar multiples servicios y aqui entra el tema del diseño de la base de datos, y de otra pregunta muy imporante
¿Qué estoy dispuesto a perder o no tener el mismo comportamiento al tener una arquitectura de microservicios?
Si por ejemplo:
Algunas transacciones comerciales, deben actualizar los datos de múltiples servicios.
Algunas transacciones comerciales necesitan consultar datos que son propiedad de múltiples servicios.
Algunas consultas deben unir datos que son propiedad de múltiples servicios.
Por ejemplo, obtener los créditos de un banco y sus clientes, para esto necesitamos hacer una consulta de clientes y créditos.
Las bases de datos a veces se deben replicar y fragmentar para escalar.
Los diferentes servicios tienen muy diferentes requisitos de almacenamiento de datos
Normalmente muchas de las aplicaciones usan bases de datos relacionales, pero en un esquema de microservicios, dependiendo del escenario, podemos usar bases de datos NoSQL, como Mongo, con ello almacenar estructuras complejas y no estructuradas o Neo4J, diseñada para almacenar y consultar datos de una forma muy eficiente. cada microservicio podria llamarse poliglota al tener diferentes tipos de bases de datos según la necesidad.
pero consejo del día….
Si ya te estas aventurandote en desacoplar tu monolito a microservicios y todavia piensas desfragmentar la base de datos y usar diferente engine para cada microservicio según la necesidad, no te quieras pasar de vivo, comienza poco a poco.
Primero la aplicación y luego la base de datos, es raro pero he visto grandes proyectos fracasar por tratar de comerse el pastel completamente.
No, no lo hagas, enserio.
Ahora, te daré una serie de consejos que te pueden servir al momento de estár diseñando o desfragmentando la base de datos de tu aplicación que estás realizando en microservicios.
1.- Manten los datos persistentes de cada microservicio privados, para cada servicio y solo pueden ser accesibles a través de su API.
En la imagen podemos ver que cada microservicio tiene sus datos privados y que solo se puede acceder a ellos vía su API de exposición, sin que el cliente acceda a las ordenes y las ordenes al cliente.
2.- La base de datos del servicio es parte de la implementación de ese servicio.
No se debe acceder directamente a la base de datos por otros servicios diferentes.
Hay algunas formas diferentes de mantener la privacidad de los datos persistentes de un servicio.
No es necesario aprovisionar un servidor de base de datos para cada servicio.
Si estas utilizando una base de datos relacional tienes de diferentes sopas:
tablas privadas por servicio: cada microervicio tiene un conjunto de tablas a las que solo debe acceder este micro.
Esquema por servicio: cada microservicio tiene un esquema de base de datos que es privado para ese micro
En mi experiencia he usado este patrón, ya que cuando iniciamos con todo esto de los microservicios, el mejor escenario y según la teoría que vamos a encontrar por todos lados de internet, nos dice que es “una base de datos por microservicio” patrón del cual hablamos más adelante, pero analicemos un poco.
Si cada microservicio tiene su propio engine y este posiblemente este contenerizado.
pongamos el siguiente escenario: hablemos de que tienes 20 microservicios. ok
1.- 20 bases de datos en contenedores
2.- 20 volumenes por cada engine de base de datos
ajamm
3.- estás bases de datos seguramente deben tener replicación automatica
ajammm
4.- estás bases de datos seguramente deben aplicarsles respaldos diarios
ajammmm
5.- y si a estas bases de datos les agregars factores de DRP, tambien debes de tenerlas en un esquema así.
6.- ahora, paga el consumo de la nube o onpremise de esos factores que ya mencione
Resultado:
20 engines, 20 volumenes, 20 contenedores, replicación y DRP, pagar el consumo de uso o de mi cluster de orquestación onpremise, para mantener la operación.
Te diría que la teoría que nos encontramos en internet nos puede dar una idea, pero al momento de implementar la teoría se queda corta para los escenarios que se nos presentan, y debemos de encontrar otras estrategías que se adapten a mis tiempos y recursos tanto de desarrollo como financieros.
Base de datos por microservicio: cada microservicio tiene su propio servidor de base de datos.
Las tablas privadas y el esquema por servicio hacen más claro el asunto.
Usar un esquema por microservicio es factible y claro, ya que hace que las tablas y sus propiedad sean más clara por cada micro
Algunos microservicios de alto rendimiento y transaccionalidad pueden necesitar su propio servidor de base de datos.
Es buena idea crear barreras que impongan esta modularidad, los desarrolladores siempre estarán tentados a pasar por alto la API de un microservicio y acceder directamente a sus datos.
3.- El uso de una base de datos por servicio, ayuda a asegurar que los servicios estén acoplados libremente.
Los cambios en la base de datos de un microservicio, no afecta a ningún otro micro.
4.- Cada microservicio puede utilizar el tipo de base de datos que mejor se adapte a sus necesidades.
ya lo vimos en el consejo 2.
Por ejemplo,
un microservicio que hace búsquedas de texto podría usar ElasticSearch,
un microservicio que manipula un gráfico social podría usar Neo4j,
un microservicio que realice un proceso altamente transaccional podría usar una base de datos relacional.
Podriamos considera el siguiente ejemplo:
Tenemos una UI, donde se consumen diferentes microservicios , para realizar un proceso de negocio, para poder acceder a ellos, podemos hacer uso de un API Gateway, el cual hablaremo en el próximo cápitulo.
El API Gateway nos ayudará a redireccionar el tráfico hacia nuestros microservicios y cada microservicio accede y persiste información a su base de datos independiente.
5.- El uso de una base de datos por microservicio tiene inconvenientes, por ejemplo:
Implementar transacciones comerciales que abarcan múltiples servicios no es sencillo.
Las transacciones distribuidas se evitan mejor debido al teorema de CAP.
Muchas bases de datos modernas (NoSQL) no las admiten. la mejor solución es usar el patrón saga,
Los microservicios publican eventos cuando se insertan o actualizan datos, otros micros se suscriben a eventos y actualizan sus datos en respuesta.
6.- Las consultas que unen datos de 1 o más fuentes distintas y están en múltiples bases de datos es un desafío.
Hay varias propuestas:
Composición de los resutaldos de la API: el microservicio o API Gateway realiza la unión, en lugar de la base de datos.
Por ejemplo, un microservicio “orquestador” o el API Gateway de la API, podría recuperar un cliente y sus creditos.
Primero recuperar al cliente del microservicio de cliente y luego consultar al microservicio de creditos para devolver las solicitudes de credito más recientes del cliente.
o
El API Gateway podria recuperar el cliente del microservicio cliente y luego lanzar una petición al microservicio de créditos para obtener sus créditos del cliente, una vez teniendo ambos resultados, realizar la composición de información vía mediacion, que ofrecen muchos API Gateways existentes en el mercado.
7.- Comando de segregación de responsabilidad de consultas (CQRS): Puedes manterner una o más vistas materializadas que contienen datos de múltiples microservicios.
Las vistas son mantenidas por los microservicios que se suscriben a los eventos que cada servicio publica cuando actualiza sus datos.
Por ejemplo:
El banco en línea, podría implementar una consulta que encuentre clientes y sus créditos recientes manteniendo una vista que se una a los clientes y los créditos, la vista se actualiza mediante un microservicio que se suscribe a eventos de clientes y pedidos.
En el siguiente artículo, hablaremos sobre transaccionalidad y como podemos implementarla en una aplicación diseñada como microservicios.
— — — — — — — — — — — — — — — — — — — — — — — — — —
Todo el año 2021 estaré impartiendo diferentes tranings, bootcamps y workshops de Apigee, Cloud y Microservicios en APIXCLOUD Service y Certificatic en la CIUDAD DE MÉXICO, les comparto el link donde vienen los telefonos y redes sociales de contacto.
BOOTCAMP : ARQUITECTO EN APIGEE Y MICROSERVICIOS CLOUD NATIVE:
🔻 Sede: APIX&CLOUD — Services / MODO ONLINE CON INSTRUCTOR EN TIEMPO REAL
🏆 Instructor: Jovani Arzate
⏰ Horario: 8:00am a 2:00pm.
⏳ Duración: 64 Horas dividido en 10 sesiones tomando 6 horas cada domingo.
🔻SOLO 15 LUGARES
📲 Contáctanos 👉 wa.link/v22o0v
contacto@apixcloudservice.com
Temas que se verán en el entranamiento:
- APIs — APIficando productos digitales
2. APIs — OpenAPI Spec 2.0 y 3.0
3. Gobierno de APIs, Metodología, Roles
4. API Management, Desarrollo en Apigee, CI/CD
5. Monolíticos, Arquitectura SOA y principios de diseño
6. Contenedores, despliegue y CI/CD
7. Microservicios — patrones de diseño, arquitectura y desarrollo
8. Kubernetes para despliegue de microservicios
#openapi #apificacion #apidevelopers #certificatic #microservices #k8s #containers #apis #apigee #patterns #domaindrivendesing #cloudnative #docker #servicediscovery #tracing #logs #monitoring #faulttolerance #eventdriven #scaling #apigateway #servicemesh #governance #arquitectura #cloud #12factores #contractfirst #apifirstdevelopment #rest #swagger #microservicios
Te invito a que leas el overview de microservicios en el siguiente Link.
y mi artículo del Patron Service Discovery en Kubernetes.
así como:
y por último:
Mi canal de youtube: https://www.youtube.com/channel/UC-eLSM45n_ZSYr1T749E6KA/videos?view_as=subscriber
Jovani Arzate Cabrera| Entrepreneur | Public Cloud Specialist | Cloud Governance | API Evangelist | API Architect | Apigee | Microservicios | AWS | Azure | GCP
