Tenemos una aplicación monolítica que ahora estamos convirtiendo a una arquitectura de microservicio usando contenedores.
Nuestros microservicios tienen estado (es decir, necesitan insertar/recuperar datos de db). Según la arquitectura de microservicio, cada microservicio debe tener sus propios datos (es decir, base de datos en nuestro caso).
Mi pregunta es dónde se debe implementar la base de datos de cada microservicio, si debe estar en el mismo host en el que se implementa el microservicio, en el mismo contenedor en el que se implementa el microservicio o debe estar en un servidor separado como azure db ¿o algo?
¿Cuáles serían los pros y los contras de cada enfoque y cuál es el mejor enfoque de acuerdo con las mejores prácticas de microservicios? *
Tiene razón, cada microservicio debe usar su propio almacén de datos que mejor se adapte a sus necesidades. Puede haber un servicio que desee almacenar sus datos en un almacenamiento de blobs, otro puede almacenar sus datos en un almacenamiento de tablas o DocumentDb o SQL Database.
Probablemente desee utilizar la base de datos como servicio , por lo que no alojará su propia base de datos porque no tendrá que preocuparse por la disponibilidad, el escalado, las copias de seguridad...
La respuesta de Martin es buena, pero quiero agregar que debido a que está utilizando una aplicación en contenedores, definitivamente debe implementar la base de datos por separado de sus contenedores de servicios. La razón es que sus servicios pueden evolucionar (independientemente) y uno de los mayores beneficios de los contenedores de servicios sin estado es que, si tiene un grupo de ellos, puede actualizarlos mediante actualizaciones continuas sin ningún impacto en la disponibilidad de su aplicación. Las actualizaciones de los servicios de base de datos con estado son más difíciles, pero también se espera que sean menos frecuentes (y nuevas tecnologías como cockroachdb están en el horizonte). Buena lectura
No importa mucho dónde , excepto que no puede estar dentro del mismo contenedor que su aplicación, como se indicó anteriormente en este hilo.
La parte importante es que solo un (1) microservicio tiene la propiedad de los datos. Si más de un microservicio necesita acceder a los datos, debe acceder a ellos a través de una API proporcionada por el microservicio que posee esos datos.
Podrías estructurarlo así:
"Microservicio Sql": maneja todo el tráfico hacia y desde SQL Server. Todos los microservicios que necesitan datos de Sql hablan con estos chicos. Tendrá un microservicio similar para TableStorage.
Si el "microservicio A" usa un almacén de datos distinto de Sql/TableStorage y ese almacén de datos es local para el microservicio A, crearía 2 microservicios.
El microservicio A1 sería donde se ejecuta su código El microservicio A2 tiene una API que expone la operación de la base de datos a A1. Cuando A1 necesita datos, habla con A2.
Además de que este patrón le permite escalar su capa de datos independientemente de los nodos de la aplicación, también se asegura de que los datos solo sean propiedad de un (1) microservicio y esa es la clave.