Si una arquitectura de microservicio necesita una base de datos separada por microservicio, es demasiado costosa y no se puede administrar. ¿Por qué incluso lo necesitamos?

7

Leí sobre microservicios y me parece ilógico crear una base de datos separada por servicio solo para lograr el aislamiento. Puedo lograr lo mismo usando solo servicios web y una sola base de datos. ¿Por qué incluso lo necesitamos? Lo que la base de datos separada está fuera de discusión. ¿O me equivoco? ¿Puedes guiarme en esto?

    
pregunta Posting Questions 09.10.2018 - 10:15

4 respuestas

12
  

¿Por qué incluso lo necesitamos?

No.

La creación de una base de datos separada para cada servicio ayuda a imponer los límites del dominio, pero es solo un enfoque. No hay nada que le impida que todos sus servicios compartan la misma base de datos.

Mientras sus servicios se comporten y no hagan cosas inesperadas a los datos que son propiedad de otros servicios, estará bien.

No sé lo que lee, pero debe tener en cuenta que hay muchas opiniones diferentes sobre la arquitectura de los microservicios. Aquí hay una buena entrada de blog sobre el tema.

  

He visto a la gente referirse a esta idea en parte, de manera trivial, como "cada microservicio debe poseer y controlar su propia base de datos y no hay dos servicios que deban compartir una base de datos". La idea es sólida: no comparta una sola base de datos a través de los servicios porque entonces se encuentra con conflictos como patrones de lectura / escritura, conflictos de modelos de datos, desafíos de coordinación, etc.

     

Pero una sola base de datos nos brinda una gran cantidad de seguridad y conveniencias: transacciones ACID, un lugar único para mirar, bien entendido (¿un poco?), un lugar para administrar, etc.

     

El viaje a los microservicios es solo eso: un viaje . Será diferente para cada empresa. No hay reglas estrictas y rápidas, solo compensaciones.

     

La parte más difícil de los microservicios: sus datos

    
respondido por el Dan Wilson 09.10.2018 - 21:04
3

Como responde Dan Wilson, realmente no lo necesitas. Los microservicios son lo nuevo y, como todo lo nuevo, las personas los usan en muchos lugares, incluso cuando no proporcionan mucho valor.

Los microservicios le permiten implementar y escalar cosas de manera independiente a un nivel "micro". Esa granularidad proporciona una gran cantidad de beneficios técnicos y aún más beneficios no técnicos, ya que le permite separar mejor los equipos de desarrollo, lanzar según sea necesario en lugar de un gran lanzamiento, probar nuevas tecnologías o procesos de forma aislada, etc. Tener una base de datos compartida mata mucho de eso debido a la dependencia de la base de datos. Si no puede implementar su servicio sin preocuparse por los datos de otro servicio, ha perdido.

  

Lo que la base de datos separada está fuera de discusión. O estoy simplemente equivocado?

Dicho esto, también te equivocas.

Cuando estás trabajando en la nube, las bases de datos son baratas. ¡Por lo general gratis! Claro, el servidor cuesta dinero, pero no estamos hablando de un servidor individual por microservicio (al menos, no al principio). Un solo servidor con un grupo de bases de datos (lógicas) está bien siempre y cuando sea diligente en evitar consultas entre bases de datos (que introducen dependencias que dañan "escalable e implementable de forma independiente"). Demonios, las consultas de bases de datos cruzadas son imposibles en algunos servicios de bases de datos en la nube como Azure SQL. Ni siquiera necesitas ser diligente allí ...

E incluso he visto microservicios donde compartían una base de datos, pero cada servicio tiene su propio esquema. De nuevo, debe ser diligente para evitar consultas que crucen los límites de los datos.

Muchos lugares no son tan diligentes. Tienen desarrolladores de nivel de entrada, o personas que no valoran el enfoque de microservicio, o tienen jefes de equipo deficientes, o tienen una presión en la línea de tiempo que hace que las personas tomen atajos.

Tener una base de datos separada es la forma más limpia de imponer ese desacoplamiento que permite la independencia del servicio, pero no es la única. Y no es tan costoso, especialmente cuando lo comparas con el tiempo / salario empleado para imponer límites de datos en una base de datos compartida.

    
respondido por el Telastyn 09.10.2018 - 21:20
0

Depende de lo que considere "caro".

Una base de datos no necesariamente tiene que ser un servidor de base de datos comercial costoso (piense que Oracle) no necesariamente tiene que ser un asunto hambriento de recursos. Dependiendo de cuáles sean sus requisitos, puede usar la base de datos SQLite o incluso el sistema de archivos como un almacenamiento de datos persistente.

Todos esos servicios también podrían compartir una única base de datos / servidor y solo tener esquemas aislados por servicio.

El argumento clave aquí es que el servicio debe poseer y controlar sus datos. Cómo lograrlo, es una cuestión de elección y detalles técnicos.

La mejor forma en que un servicio puede poseer y controlar sus datos es tener su propia base de datos "personal". Esto permite una completa libertad de elección de la tecnología y la evolución del esquema de datos. La única forma en que cualquier otro servicio puede acceder a los datos que son propiedad de un servicio es solicitando los datos de un servicio. De esta manera, si es necesario cambiar la representación de datos internos, se puede cambiar fácilmente y ningún otro servicio se interrumpirá.

Por lo tanto, para recapitular. No es necesariamente caro tener una base de datos por servicio ni es necesario. Es simplemente una decisión que debe tomar en algún momento al desarrollar microservicios. Cada una de las opciones tiene sus implicaciones y limitaciones. Estudia esos y haz tu propia elección.

    
respondido por el Roland Tepp 12.10.2018 - 19:49
0
  

¿Por qué incluso lo necesitamos?

El enorme beneficio de los microservicios, y más ampliamente, SOA, es el alto nivel de abstracción de los componentes internos, no solo la implementación, sino también las tecnologías que se utilizan. Por ejemplo, si un sistema se desarrolla en una forma de cinco microservicios por cinco equipos, un equipo puede decidir pasar a una pila tecnológica completamente diferente (por ejemplo, desde la pila de Microsoft a la LAMP) sin siquiera pedirle a otros equipos su opinión. p>

Mira a Amazon AWS o Twilio. ¿Sabes si sus servicios están implementados en Java o Ruby? ¿Usan Oracle o PostgreSQL o Cassandra o MongoDB? ¿Cuántas máquinas usan? ¿Incluso te importa eso? en otras palabras, ¿esas elecciones tecnológicas afectan la forma en que usa esos servicios? ... Y lo que es más importante, si se mueven a una base de datos diferente, ¿tendría que cambiar su aplicación de cliente en consecuencia?

Ahora, ¿qué sucede si dos servicios usan la misma base de datos? Aquí hay una pequeña parte de los problemas que pueden surgir:

  • El equipo que desarrolla el servicio 1 quiere pasar de SQL Server 2012 a SQL Server 2016. Sin embargo, el equipo 2 se basa en una función obsoleta que se eliminó en SQL Server 2016.

  • El servicio 1 es un gran éxito. Alojar la base de datos en dos máquinas (maestra y conmutación por error) ya no es una opción. Pero escalar el clúster a múltiples máquinas requiere estrategias como fragmentación. Mientras tanto, el equipo 2 está contento con la escala actual y no ve razón para moverse a otra cosa.

  • El servicio 1 debe moverse a UTF-8 como su codificación predeterminada. Sin embargo, el servicio 2 está satisfecho con el uso de la página de códigos 1252 de Windows Latin 1.

  • El servicio 1 decide agregar un usuario con un nombre específico. Sin embargo, este usuario ya existe, creado hace unos meses por el segundo equipo.

  • El servicio 1 necesita muchas características diferentes. El Servicio 2 es un componente altamente crítico y necesita mantener las características de la base de datos al mínimo para reducir el riesgo de ataques.

  • El servicio 1 requiere 15 TB de espacio en disco; La velocidad no es importante, por lo que los discos duros normales están perfectamente bien. El servicio 2 requiere 50 GB como máximo, pero necesita acceder a él lo más rápido posible, lo que significa que los datos deben almacenarse en un SSD.

  • ...

Cada pequeña elección afecta a todos. Cada decisión debe ser tomada en colaboración, por personas de cada equipo. Hay que hacer compromisos. Compare eso con una total libertad para hacer lo que quiera en un contexto de SOA.

  

es demasiado [...] inmanejable.

Entonces lo estás haciendo mal. Supongo que estás implementando manualmente .

Esto no es cómo se deben hacer las cosas. Debe automatizar la implementación de máquinas virtuales (o contenedores Docker) que ejecutan la base de datos. Una vez que los automatiza, la implementación de dos servidores o veinte servidores o dos mil servidores no es muy diferente.

Lo mágico de las bases de datos aisladas es que es extremadamente manejable . ¿Has intentado administrar una gran base de datos utilizada por docenas de equipos? Es una pesadilla. Cada equipo tiene solicitudes específicas, y tan pronto como tocas algo, afecta a alguien. Con una base de datos emparejada con una aplicación, el alcance se vuelve muy limitado, lo que significa que hay mucho menos que pensar.

Si una base de datos enorme requiere administradores de sistemas especializados, las bases de datos que solo usa un equipo pueden ser manejadas esencialmente por este equipo (DevOps es también al respecto), liberando tiempo de los administradores del sistema.

  

es demasiado costoso

Define el costo.

Los costos de licencias dependen de la base de datos. En la era de la computación en la nube, estoy bastante seguro de que todos los jugadores principales rediseñaron sus licencias para adaptarse al contexto donde, en lugar de una gran base de datos, hay muchos pequeños. Si no, puede considerar mudarse a una base de datos diferente. Hay muchos de código abierto, por cierto.

Si está hablando de poder de procesamiento, tanto las máquinas virtuales como los contenedores son compatibles con la CPU, y no sería muy afirmativo que una gran base de datos consumirá menos CPU que muchos pequeños que hacen el mismo trabajo. / p>

Si su problema es la memoria, las máquinas virtuales no son una buena opción para usted. Los contenedores son. Podrá abarcar la cantidad que desee, sabiendo que no consumirán más RAM de la necesaria. Si bien el consumo total de memoria será mayor para muchas bases de datos pequeñas en comparación con una gran base de datos, supongo que la diferencia no será demasiado importante. YMMV.

    
respondido por el Arseni Mourzenko 12.10.2018 - 20:45

Lea otras preguntas en las etiquetas