Microservicios y almacenamiento de datos.

Estoy considerando mover una API REST monolítica a una arquitectura de microservicio, y me estoy confundiendo un poco sobre el almacenamiento de datos. A mi entender, algunos de los beneficios de los microservicios serían:

• Escalable horizontalmente: puedo ejecutar múltiples copias redundantes de un microservicio para hacer frente a la carga y / o la caída de un servidor.
• Acoplado libremente: puedo cambiar las implementaciones internas de microservicios sin tener que cambiar los demás, y puedo implementarlos y cambiarlos de forma independiente, etc.

Mi problema es con el almacenamiento de datos. A mi modo de ver, hay varias opciones:

1. Un único servicio de base de datos compartido por todos los microservicios; esto parece eliminar por completo cualquier beneficio del acoplamiento flexible.
2. Una instancia de base de datos instalada localmente en cada microservicio: no puedo ver una forma de escalar horizontalmente esto, por lo que no creo que sea una opción.
3. Cada microservicio tiene su propio servicio de base de datos; esto parece ser el más prometedor, ya que conserva los beneficios del acoplamiento suelto y el escalado horizontal (utilizando copias redundantes de la base de datos y / o fragmentación en varios)

Para mí, la tercera opción parece ser la única opción, pero me parece increíblemente pesada y una solución muy ingeniosa. Si lo entiendo bien, entonces para una aplicación simple con 4-5 microservicios, tendría que ejecutar 16-20 servidores: dos instancias de microservicio reales por microservicio (en caso de falla del servidor y para implementar sin tiempo de inactividad), y dos instancias de servicio de base de datos por microservicio (en caso de falla del servidor, etc.).

Esto, francamente, parece un poco ridículo. ¿16-20 servidores para ejecutar una API simple, teniendo en cuenta que un proyecto realista probablemente tendrá más de 4-5 servicios? ¿Hay algún concepto fundamental que me falta que explique esto?

Algunas cosas que pueden ayudar al responder:

• Soy el único desarrollador de este proyecto, y lo seré en el futuro previsible.
• Estoy usando Node.js y MongoDB, pero me interesarían las respuestas independientes del lenguaje, ¡una respuesta podría incluso ser que solo estoy usando las tecnologías incorrectas!

De sus tres opciones, la primera (una única base de datos compartida) y la tercera (un "servicio de base de datos") son las más comunes.

El primero se llama una base de datos de integración . Esto generalmente no se ve como una buena solución en una arquitectura de microservicio. Agrega acoplamiento a sus servicios. También hace que sea muy fácil para un servicio simplemente pasar por alto los otros servicios y consultar directamente en una base de datos. Podría perder cualquier tipo de integridad de datos o validación proporcionada por el nivel de aplicación que no se aplica a nivel de base de datos.

Su tercera idea se llama una base de datos de aplicaciones . Y tiene razón: le permite imponer el acoplamiento suelto en el nivel API entre servicios y le permite escalar más fácilmente los servicios en el nivel de la base de datos. También facilita la sustitución de la tecnología de base de datos subyacente por algo apropiado con cada servicio, así como puede cambiar la tecnología u otros detalles de implementación de cada servicio. Muy flexible.

Sin embargo, propondría una solución intermedia.

En lugar de crear un servicio de base de datos para cada microservicio, cree un esquema para cada servicio. Si está utilizando múltiples tecnologías de bases de datos, es posible que deba dividirse de manera ligeramente diferente, pero la idea sería minimizar la cantidad de servidores de bases de datos que está ejecutando, pero hacer que sea muy fácil dividir un servicio en su propio servidor de bases de datos si y cuando sea necesario Siempre y cuando solo permita que una base de datos acceda a su propio esquema, tiene las ventajas de una base de datos de aplicaciones pero sin la sobrecarga de servidores de bases de datos existentes para cada aplicación o servicio.

Sin embargo, como desarrollador en solitario, desafiaría toda la noción de microservicios en este momento: Martin Fowler escribe sobre Monolith First y Microservice Premium , Simon Brown habla sobre monolitos modulares y DHH habla sobre Majestic Monolith. No estoy seguro de qué tan bien está organizado su monolito, pero refactorice y organícelo. Identifique los componentes y realice separaciones limpias entre ellos para extraer piezas fácilmente en un servicio. Lo mismo aplica para la estructura de su base de datos. Concéntrese en una arquitectura buena, limpia y basada en componentes que pueda admitir la refactorización en los servicios. Los microservicios agregan una gran cantidad de gastos generales para que un solo desarrollador construya y soporte en las operaciones. Sin embargo, una vez que realmente necesite escalar parte del sistema, use sus sistemas de monitoreo e informes para identificar los cuellos de botella, extraer a un servicio y escalar según sea necesario.

Cada microservicio tiene su propio servicio de base de datos; esto parece ser el más prometedor, ya que conserva los beneficios del acoplamiento suelto y el escalado horizontal (utilizando copias redundantes de la base de datos y / o fragmentación en varios)

De acuerdo. La tercera opción es la opción natural para los micro servicios. Si el micro servicio está destinado a ser realmente independiente (y no parte de un monolito distribuido ), es normal que tengan, cada uno, una base de datos.

[...] dos instancias de microservicio reales por microservicio (en caso de falla del servidor y para implementación sin tiempo de inactividad), y dos instancias de servicio de base de datos por microservicio (en caso de falla del servidor, etc.).

Tiene razón acerca de la cantidad de micro servicios que se ejecutan si desea tener un equilibrio de carga. Si planea tener 4 micro servicios, debe preparar al menos 2 instancias de cada micro servicio (8 en total), como ya explicó.

¿Pero dos bases de datos por micro servicio? Esto es realmente cuestionable. No conozco los detalles sobre el problema comercial al que atenderán sus micro servicios, pero tener una redundancia de base de datos es bastante para la mayoría de los productos / proyectos. Recomendaré comenzar con una sola base de datos con una buena copia de seguridad y minimizar (al menos inicialmente) la complejidad de su infraestructura.

Esto, francamente, parece un poco ridículo. ¿16-20 servidores para ejecutar una API simple, teniendo en cuenta que un proyecto realista probablemente tendrá más de 4-5 servicios? ¿Hay algún concepto fundamental que me falta que explique esto?

Para una API simple, estos números no coinciden. Presta atención si no estás cayendo en una de las trampas "Microservice First" .

Los microservicios son una forma de arquitectura orientada a servicios, quizás en extremo. Su propósito general es reducir el acoplamiento y permitir el desarrollo y la implementación independientes.

Hablando en términos arquitectónicos, microservicios es un término que se aplica, digamos, a un nivel lógico. Los microservicios están separados lógicamente entre sí. Desde esta perspectiva, los microservicios deberían ser propietarios y proporcionar su propio almacenamiento, que debería estar desacoplado del almacenamiento de otros microservicios. Para los microservicios, esta independencia de almacenamiento es clave para su objetivo de modularidad y acoplamiento flexible.

Desde una perspectiva arquitectónica, la escala horizontal se aplica en un nivel inferior, más cercano a la implementación, digamos, en un nivel físico. En este nivel, estamos implementando un microservicio, y podemos descomponer este microservicio individual, internamente, en un componente sin estado que es escalable horizontalmente, y un componente con estado que es compartido por todos los componentes sin estado.  Pero no confundamos solo la parte sin estado con el microservicio mismo.

Entonces, cuando hablamos de microservicios individuales, estamos en el nivel lógico hablando de API y responsabilidades separadas y ciclos separados de desarrollo / implementación. Y cuando hablamos de escala horizontal, estamos en el nivel físico hablando de la implementación de un microservicio (único) y su descomposición en componentes sin estado y con estado.

Al implementar múltiples microservicios, tenemos opciones para reutilizar la tecnología de base de datos para los componentes con estado:

• base de datos separada por microservicio
• base de datos compartida con:
  • esquema separado / privado por microservicio
  • tablas separadas / privadas por microservicio

Ver más aquí .

Un único servicio de base de datos compartido por todos los microservicios; esto parece eliminar por completo cualquier beneficio del acoplamiento flexible.

De acuerdo, si te refieres a compartir tablas, filas y columnas, eso no sería realmente microservicios.

Si podemos desacoplar, en nuestros procesos de pensamiento, la noción lógica de microservicios de la noción más física de componentes con estado y sin estado de un microservicio, podemos encontrar más fácil lograr el acoplamiento flexible que ofrecen los microservicios, al tiempo que conservamos la eficiencia de un servicio compartido bases de datos

En general, hay una buena cantidad escrita sobre microservicios y persistencia con estado, ver también aquí .

Bueno, he leído todas las publicaciones en este hilo y puedo decirte que estoy confundido con la pregunta: combina microservicios (MS) con servicios con servicio de acceso a datos (servicio DB) con bases de datos y servidores ...

Si MS es un componente independiente (desplegable) que resuelve una tarea más simple de una manera sin estado, ¿QUÉ base de datos necesita? Si se debe resolver una tarea más compleja, que requiere resolver más de una subtarea más simple (¿MS?) Juntas, ¿sigue siendo una MS? En SOA, se llama un servicio de orquestación. Implementa el "proceso" y coordina la invocación de MS, por lo tanto, necesita mantener su estado (todas las orquestaciones / organizadores / compositores / etc. tienen estado) y necesita un almacén de datos personal: nadie más puede moderar el estado del orquestador.

Sin embargo, no hablamos de la base de datos sino de MS / Service de acceso a la base de datos, y este es un asunto totalmente diferente. Una MS puede necesitar algunos datos recopilados en la empresa (no en la Aplicación en la que opera) y no puede solicitar a otra MS a través de su API / interfaz los datos. Este es el escenario más común y realista. Y otra MS de la misma o diferente aplicación podría necesitar estos datos o incluso cambiarlos. Sí, compiten por los datos como siempre antes de que surgiera la EM.

¿Por qué bloqueamos la 'puerta', que es bien conocida y abierta? ¿Cuál es la diferencia a este respecto entre una EM y un objeto regular de auto persistencia? ¿Por qué necesitamos una base de datos individual para la EM si debe (para fines de flexibilidad y composibilidad) comprometer su Servicio de acceso a datos (DAS) de todos modos? No olvide que DAS protege a la MS con una tarea empresarial de la conciencia sobre la conectividad física a la base de datos. Este acoplamiento flexible y la flexibilidad que MS debe preservar para participar libremente en múltiples aplicaciones sin anclaje de base de datos.