¿Cómo se ubican típicamente los datos en la arquitectura de microservicios?

En la arquitectura de microservicios, cada microservicio almacena sus datos dentro de sí mismo. Pero eso no significa que cada instancia del mismo Microservicio tendrá su propio almacén de datos.

Para mejorar el rendimiento, si implementamos Sharding, cada instancia del mismo Microservice mantiene su propio fragmento. Los datos específicos de una instancia de Microservice se almacenan en su fragmento.

Hay escenarios en los que tenemos que mantener un almacén de datos común entre Microservicios. Esto generalmente se hace para microservicios que requieren un uso intensivo de la computación. En tal escenario, implementamos un microservicio para almacenar en caché los datos que no se actualizan con mucha frecuencia.

En mi humilde opinión, la respuesta a esta pregunta depende del problema que un microservicio específico está tratando de resolver.

Referencia : Libro de preguntas sobre microservicios

Sígueme en Gautam Gupta si quieres aprender más sobre la arquitectura de Microservicios.

Wow, ten cuidado! Cómo se almacena la información es “muy” importante.

Siempre uso el término “disco de oro” cuando se trata básicamente de cualquier sistema de información. Este término comienza a mostrarse cuando ese sistema sigue una arquitectura de microservicio.

Es vital para un sistema de información comprender quién tiene el récord de oro en cada caso de uso.

La pregunta aquí no es SQL vs MySQL o RDBMS vs Document DB; no permita que la elección de la herramienta enturbie la importancia del tema. En un diseño de microservicio, puede utilizar “la herramienta adecuada para el trabajo correcto”. Los datos en algún momento podrían incluso almacenarse como hipertexto (Json / Xml, etc.) en archivos simples en un almacenamiento en la nube, o incluso podría usar la búsqueda elástica como almacenamiento para su microservicio de “búsqueda”. ¿Tiene que ser una base de datos? De ningún modo. ¿Tiene que ser almacenado en el lugar correcto? Absolutamente.

Cada microservicio puede (presumiblemente) tener su propio almacenamiento de datos (lo llamo almacenamiento, ya que la elección de la herramienta podría ahogar el punto). Sin embargo, hay casos en los que necesita tener lo que se llama “un estado poligónico”. Datos que deben compartirse entre más de un microservicio (información del usuario, por ejemplo,?)

Al final del día, su aplicación (la presentación visual) también necesita un estado y se le permite tener su propio almacenamiento de datos. Es la libertad que tiene y el arte de cómo dividir una estructura de datos monolítica en responsabilidades y distribuirlas correctamente entre todos sus microservicios.

El objetivo al final es dividir la estructura en piezas independientes más pequeñas. Por lo tanto, mientras almacena información, también debe tener cuidado con el mantenimiento de los datos. (¿Una copia de seguridad para toda la información de usuarios, clientes y contratos? ¿O las copias de seguridad separadas serían beneficiarias? Eso realmente depende de cuán GRANDE sea el tráfico y los datos que enfrenta).

Siempre me refiero a la arquitectura de microservicios como un movimiento cultural en lugar de simplemente diseñar aplicaciones de manera diferente. Básicamente:

1. Recuerde mantener el equilibrio. No divida las cosas en pedazos más pequeños a menos que estén comenzando a convertirse en un “monolito”.

2. Tenga en cuenta los esfuerzos de implementación. Una vez que divida una aplicación en 20 servicios / aplicaciones diferentes, tendrá que realizar mayores esfuerzos de implementación. Aunque podría equilibrar esto al liberar de forma independiente cada microservicio si tiene un equipo pequeño. En equipos más grandes, esto requiere más coordinación y comunicación.

3. Vigile sus discos de oro.