Entiendo que cada servicio en una arquitectura de microservicio debe tener su propia base de datos. Sin embargo, al tener su propia base de datos, ¿significa realmente simplemente tener otra base de datos dentro de la misma instancia de base de datos o literalmente tener otra instancia de base de datos?
Con esto, no me refiero a compartir bases de datos, que es un no-no, sino más bien la instancia de la base de datos.
Por ejemplo, si estaba usando AWS y tengo 3 servicios, ¿creo 3 bases de datos para cada servicio en una sola instancia de RDS o creo 3 instancias de RDS que contengan una base de datos que cada uno de los 3 servicios usa de manera independiente?
Si usar múltiples bases de datos en una sola instancia de RDS es una mejor idea, ¿anulará el propósito de tener servicios independientes porque:
El recurso de la instancia RDS se compartirá entre los servicios. ¿El Servicio A, que puede tener un uso intensivo de la base de datos en un momento determinado, afectará al Servicio B, que usa una base de datos diferente pero en la misma instancia de RDS?
Todos los servicios dependerán de la versión de la base de datos en esa instancia de RDS.
Respuestas:
Realmente depende de sus requisitos de escalabilidad y de cómo / si sus instancias de microservicio deben cooperar para proporcionar un resultado único. Es útil saber cuáles son las compensaciones:
Manteniéndolo todo en una base de datos
Mantener las bases de datos separadas
¿Cuál es el problema que estás resolviendo?
En algunos casos, solo le preocupan los datos efímeros. Si la base de datos se cae, no es un gran problema. En esos casos, es posible que ni siquiera necesite una base de datos para empezar. Solo manténgalo todo en la memoria y haga las cosas increíblemente rápidas. Esta es la solución más fácil para trabajar.
En otros casos, necesita la integridad de los datos, pero su base de datos es capaz de expandir su capacidad en función del número de nodos que tiene. En este caso, una sola base de datos es probablemente más que suficiente, y administrar su capacidad de respuesta de forma independiente es la respuesta correcta.
Hay una serie de casos en el medio. Por ejemplo, es posible que tenga bases de datos que son regionalmente específicas, por lo que para cada instancia de su servicio en una región diferente, tiene una base de datos separada. Por lo general, las bases de datos de fragmentación no funcionan bien en todas las regiones, por lo que esta es una forma de localizar un poco los datos y controlar la coordinación usted mismo.
Doctrina y realidad
He leído varios artículos sobre microservicios y qué tan modulares deberían ser. Las recomendaciones van desde mantener el front-end, el microservicio y el nivel de datos como una unidad completa hasta compartir la base de datos y / o el código de front-end para todas las instancias. Por lo general, un mayor aislamiento proporciona la mayor escalabilidad, pero tiene el costo de una mayor complejidad.
Si su microservicio es pesado en el cálculo, tiene sentido permitir que el número de esos microservicios escale según sea necesario; compartir la base de datos o incluso el código front-end no perjudica ni obstaculiza este enfoque.
La realidad es que las necesidades específicas de su proyecto necesitarán un conjunto diferente de compromisos para realizar el trabajo de manera oportuna y manejar la carga del sistema que está midiendo (además de un poco más). Considere que el trío de nivel de datos, microservicio y front-end completamente aislado es el objetivo principal. Mientras más demanda exista en su sistema, más cerca de ese objetivo probablemente necesitará estar. No somos todos
[insert name of highly successful web entity here], y no comenzaron donde están ahora. A veces solo necesitas comenzar con una situación menos que perfecta, y ser feliz con eso.fuente
Suponiendo que tiene algunos servicios que pueden usar el mismo tipo de sistema y versión de base de datos, si usa diferentes bases de datos o instancias de base de datos es una decisión que no debe tomar en el momento del diseño. En cambio, debe poder tomar la decisión en el momento de la implementación, algo que simplemente puede configurar. Diseñe sus servicios para que sean independientes del lugar donde se alojan las bases de datos de otros servicios.
Durante la operación, puede comenzar con una instancia, y si el sistema funciona bien, déjelo así. Sin embargo, si nota que esto no se adapta bien a su sistema, ya que las diferentes bases de datos en una instancia comparten demasiados recursos, siempre tiene la opción de usar diferentes instancias, si eso ayuda.
Por lo tanto, un servicio no viola la arquitectura del microservicio solo porque dejas que dos de ellos compartan algún recurso; lo viola cuando compartir el recurso se vuelve obligatorio.
fuente
No importa.
El único escenario en el que teóricamente podría importar es si un servicio necesita migrar a versiones diferentes de la base de datos. Pero incluso entonces, no hay una diferencia real entre tener instancias separadas desde el principio versus migrar ese servicio de una instancia compartida a otra. De hecho, diría que tener instancias separadas solo por este escenario es un ejemplo de YAGNI.
fuente
Una instancia de RDS es un cuadro único. Si tiene varias bases de datos en una sola instancia, entonces comparten la CPU / Memoria, etc.
Si el rendimiento de su microservicio está limitado por el rendimiento de su base de datos : luego implemente varias copias del microservicio, cada una utilizando una base de datos diferente, pero con cada base de datos en la misma instancia de RDS. No tiene sentido * (excepto para la conmutación por error). Su clúster de microservicios se ejecutará a la misma velocidad que un microservicio único
Sin embargo , diría que un microservicio que está sujeto al rendimiento de la base de datos es inusual.
Por lo general, su microservicio obtendrá datos de una base de datos, realizará cierta lógica y escribirá información en la base de datos. El cuello de botella en el rendimiento es la lógica , no la selección y / o inserción.
En este caso, simplemente puede compartir la misma base de datos en todas sus instancias de microservicio
fuente
El objetivo de mantener una base de datos privada para un servicio es la encapsulación. Su microservicio es una caja negra que otros servicios en el sistema usarán a través de una interfaz pública.
Hay dos planos en los que opera esta encapsulación:
El primero es lógico, a nivel de aplicación. Su servicio posee algunos objetos comerciales en su sistema, y necesita mantener el estado de estos objetos. Que alguna base de datos particular respalde estos objetos comerciales es solo un detalle de implementación. Al mantener una base de datos separada, evita que otros servicios tengan acceso de puerta trasera a su implementación, forzándolos a usar su interfaz pública. El objetivo aquí es una arquitectura limpia y una programación disciplinada. La ubicación exacta de la base de datos es irrelevante en este nivel, siempre que su servicio tenga los detalles de conexión correctos para que pueda encontrarlo.
El segundo nivel es operativo. Incluso si su diseño es una caja negra perfecta, como señala, diferentes trabajos colocados en una sola máquina pueden competir por los recursos. Esta es una buena razón para colocar bases de datos lógicas separadas en máquinas separadas. Como han señalado otras respuestas, si sus necesidades no son muy exigentes y su presupuesto es ajustado, este es un argumento pragmático para la colocación en una sola máquina. Sin embargo, como siempre, compensa: esta configuración puede requerir más cuidado de niños a medida que su sistema crece. Si el presupuesto lo permite, casi siempre prefiero dos máquinas pequeñas separadas para ejecutar dos tareas en lugar de compartir una máquina más grande.
fuente
Creo que podría ayudar ser un poco más teórico aquí. Una de las ideas motivadoras detrás de los microservicios son los procesos de transmisión de mensajes que no comparten nada. Un microservicio es como un actor en el modelo de actor. Esto significa que cada proceso mantiene su propio estado local y la única forma de que un proceso acceda al estado de otro es mediante el envío de mensajes (e incluso entonces el otro proceso puede responder como quiera a esos mensajes). Lo que se entiende por "cada microservicio tiene su propia base de datos" es realmente que el estado de un proceso (es decir, microservicio) es local y privado . En gran medida, esto sugiere que la "base de datos" debería estar colocadacon el microservicio, es decir, la "base de datos" debe almacenarse y ejecutarse en el mismo nodo lógico que el microservicio. Las diferentes "instancias" del microservicio son procesos separados y, por lo tanto, cada una debe tener su propia "base de datos".
Desde esta perspectiva, una base de datos global o una base de datos compartida entre microservicios o incluso instancias de un microservicio constituiría un estado compartido. La forma "apropiada" de manejar esto desde la perspectiva de los microservicios es tener la base de datos compartida mediada por un microservicio de "base de datos". Otros microservicios que quisieran saber sobre el contenido de la base de datos enviarían mensajes a ese "microservicio de base de datos". ¡Esto normalmente no eliminará la necesidad de un estado local (es decir, por "bases de datos" de instancia de microservicio) para los microservicios originales! Lo que cambia es lo que representa ese estado local. En lugar de almacenar "El usuario Sally es un administrador", almacenaría "El microservicio de la base de datos dijo 'El usuario Sally es un administrador' hace cinco minutos". En otras palabras, sobre el estado de otros microservicios.
El beneficio de esto es que cada microservicio es autónomo. Esto hace que un microservicio sea una unidad atómica de falla. Usted (en su mayoría) no tiene que preocuparse por un microservicio en algún estado parcialmente funcional. Por supuesto, el problema se ha trasladado a la red de microservicios. Es posible que un microservicio no pueda realizar la función deseada debido a que no puede contactar otros microservicios. Sin embargo, el beneficio es que el microservicio estará en un estado bien definido y bien podrá ofrecer un servicio degradado o limitado, por ejemplo, trabajando con creencias anticuadas. La desventaja es que es muy difícil obtener una instantánea coherente del sistema en su conjunto, y puede haber una gran cantidad de redundancia (no deseada) y duplicación.
Por supuesto, la sugerencia no es pegar una instancia de Oracle en cada contenedor Docker. Primero, no todos los microservicios necesitan una "base de datos". Algunos procesos no necesitan ningún estado persistente para funcionar correctamente. Por ejemplo, un microservicio que se traduce entre dos protocolos no necesariamente necesita ningún estado persistente. Para cuando se necesita un estado persistente, la palabra "base de datos" es solo una palabra para "estado persistente". Puede ser un archivo con JSON o una base de datos Sqlite o una copia de Oracle que se ejecute localmente si lo desea o cualquier otro medio local.almacenamiento persistente de datos. Si la "base de datos" no es local, desde una perspectiva pura de microservicios, debe tratarse como un servicio (micro) separado. Con este fin, nunca tiene sentido que una instancia de RDS sea la "base de datos" para un microservicio. Nuevamente, la perspectiva no es "un montón de microservicios con sus propias bases de datos RDS" sino "un montón de microservicios que se comunican con bases de datos RDS". En este punto, no importa si los datos se almacenan en la misma instancia de la base de datos o no.
Pragmáticamente, una arquitectura de microservicios agrega una gran cantidad de complejidad. Esta complejidad es solo el precio de tratar seriamente con una falla parcial. Para muchos, es una exageración que posiblemente no valga la pena los beneficios. Debe sentirse libre de diseñar su sistema de la forma que le parezca más beneficiosa. Existe una buena posibilidad de que las preocupaciones sobre la simplicidad y la eficiencia puedan conducir a desviaciones de una arquitectura de microservicios puros. El costo será un acoplamiento adicional que introduce sus propias complejidades, como las interacciones invisibles entre los servicios y las restricciones sobre su libertad de implementación y escalado a su gusto.
fuente