Gestión de datos descentralizada: encapsulación de bases de datos en microservicios [cerrado]

Recientemente he estado tomando un curso sobre diseño de software y recientemente hubo una discusión / recomendación sobre el uso de un modelo de 'microservicios' en el que los componentes de un servicio se separan en subcomponentes de microservicio que son lo más independientes posible.

Una parte que se mencionó fue que, en lugar de seguir el modelo muy frecuente de tener una sola base de datos con la que hablan todos los microservicios, tendría una base de datos separada ejecutándose para cada uno de los microservicios.

Puede encontrar una explicación mejor y más detallada de esto aquí: http://martinfowler.com/articles/microservices.html en la sección Gestión de datos descentralizada

la parte más destacada que dice esto:

Los microservicios prefieren dejar que cada servicio administre su propia base de datos, ya sea diferentes instancias de la misma tecnología de base de datos o sistemas de bases de datos completamente diferentes, un enfoque llamado Polyglot Persistence. Puede usar la persistencia políglota en un monolito, pero aparece con más frecuencia con microservicios.

Figura 4

Me gusta este concepto y, entre muchas otras cosas, lo veo como una gran mejora en el mantenimiento y tener proyectos con varias personas trabajando en ellos. Dicho esto, de ninguna manera soy un arquitecto de software con experiencia. ¿Alguien ha intentado alguna vez implementarlo? ¿Qué beneficios y obstáculos te encontraste?

Hablemos de aspectos positivos y negativos del enfoque de microservicio.

Primeros negativos. Cuando crea microservicios, agrega complejidad inherente a su código. Estás agregando gastos generales. Estás haciendo más difícil replicar el entorno (por ejemplo, para desarrolladores). Estás dificultando la depuración de problemas intermitentes.

Permítanme ilustrar un verdadero inconveniente. Considere hipotéticamente el caso en el que tiene 100 microservicios llamados mientras genera una página, cada uno de los cuales hace lo correcto el 99.9% del tiempo. Pero el 0.05% de las veces producen resultados incorrectos. Y el 0.05% del tiempo hay una solicitud de conexión lenta donde, por ejemplo, se necesita un tiempo de espera de TCP / IP para conectarse y eso lleva 5 segundos. Alrededor del 90.5% de las veces su solicitud funciona perfectamente. Pero alrededor del 5% del tiempo tiene resultados incorrectos y alrededor del 5% del tiempo su página es lenta. Y cada falla no reproducible tiene una causa diferente.

A menos que piense mucho en las herramientas para monitorear, reproducir, etc., esto se convertirá en un desastre. Particularmente cuando un microservicio llama a otro que llama a otro unas pocas capas de profundidad. Y una vez que tenga problemas, solo empeorará con el tiempo.

OK, esto suena como una pesadilla (y más de una compañía se ha creado enormes problemas al seguir este camino). El éxito solo es posible. Usted es claramente consciente del potencial inconveniente y trabaja constantemente para abordarlo.

Entonces, ¿qué pasa con ese enfoque monolítico?

Resulta que una aplicación monolítica es tan fácil de modularizar como los microservicios. Y una llamada a la función es más barata y más confiable en la práctica que una llamada RPC. Por lo tanto, puede desarrollar lo mismo, excepto que es más confiable, se ejecuta más rápido e implica menos código.

Bien, entonces ¿por qué las empresas recurren al enfoque de microservicios?

La respuesta es porque a medida que escala, hay un límite de lo que puede hacer con una aplicación monolítica. Después de tantos usuarios, tantas solicitudes, etc., llega a un punto en el que las bases de datos no se escalan, los servidores web no pueden guardar su código en la memoria, etc. Además, los enfoques de microservicio permiten actualizaciones independientes e incrementales de su aplicación. Por lo tanto, una arquitectura de microservicio es una solución para escalar su aplicación.

Mi regla general es que pasar del código en un lenguaje de script (por ejemplo, Python) a C ++ optimizado generalmente puede mejorar 1-2 órdenes de magnitud tanto en el rendimiento como en el uso de la memoria. Ir al otro lado a una arquitectura distribuida agrega una magnitud a los requisitos de recursos, pero le permite escalar indefinidamente. Puede hacer que una arquitectura distribuida funcione, pero hacerlo es más difícil.

Por lo tanto, diría que si está comenzando un proyecto personal, vaya monolítico. Aprende a hacerlo bien. No se distribuya porque (Google | eBay | Amazon | etc) son. Si aterriza en una gran empresa que se distribuye, preste mucha atención a cómo lo hacen funcionar y no lo arruine. Y si terminas teniendo que hacer la transición, ten mucho cuidado porque estás haciendo algo difícil que es muy fácil equivocarte.

Divulgación, tengo cerca de 20 años de experiencia en empresas de todos los tamaños. Y sí, he visto arquitecturas monolíticas y distribuidas de cerca y personal. Se basa en esa experiencia que le estoy diciendo que una arquitectura de microservicio distribuido realmente es algo que hace porque lo necesita, y no porque de alguna manera sea más limpia y mejor.

Estoy totalmente de acuerdo con la respuesta de btilly, pero solo quería agregar otro positivo para Microservices, que creo que es una inspiración original detrás de esto.

En un mundo de microservicios, los servicios están alineados con dominios y son administrados por equipos separados (un equipo puede administrar múltiples servicios). Esto significa que cada equipo puede lanzar servicios completamente por separado e independientemente de cualquier otro servicio (suponiendo que las versiones sean correctas, etc.).

Si bien eso puede parecer un beneficio trivial, considere lo contrario en un mundo monolítico. Aquí, donde una parte de la aplicación debe actualizarse con frecuencia, tendrá un impacto en todo el proyecto y en cualquier otro equipo que trabaje en él. Luego deberá introducir la programación, las revisiones, etc., y todo el proceso se ralentizará.

Para su elección, además de considerar sus requisitos de escala, también considere las estructuras de equipo requeridas. Estoy de acuerdo con la recomendación de btilly de que inicie Monolithic y luego identifique más adelante dónde los Microservicios podrían ser beneficiosos, pero tenga en cuenta que la escalabilidad no es el único beneficio.

Trabajé en un lugar que tenía una buena cantidad de fuentes de datos independientes. Los pusieron todos en una única base de datos, pero en diferentes esquemas a los que accedieron los servicios web. La idea era que cada servicio solo pudiera acceder a la cantidad mínima de datos que necesitaban para realizar su trabajo.

No fue una sobrecarga en comparación con una base de datos monolítica, pero supongo que esto se debió principalmente a la naturaleza de los datos que ya estaban en grupos aislados.

Los servicios web se llamaron desde el código del servidor web que generó una página, por lo que se parece mucho a su arquitectura de microservicios, aunque posiblemente no sea tan micro como sugiere la palabra y no se distribuyó, aunque podrían haber sido (tenga en cuenta que un WS sí llamó para obtener datos de un servicio de terceros, por lo que hubo 1 instancia de un servicio de datos distribuido allí). La compañía que hizo esto estaba más interesada en la seguridad que en la escala, sin embargo, estos servicios y los servicios de datos proporcionaron una superficie de ataque más segura ya que una falla explotable en uno no daría acceso completo a todo el sistema.

Roger Sessions en sus excelentes boletines de Objectwatch describió algo similar con su concepto de Software Fortresses (desafortunadamente los boletines ya no están en línea, pero puede comprar su libro).