Los microservicios son una forma de dividir una aplicación grande en módulos poco acoplados que se comunican entre sí a través de una API simple.
Últimamente sólo los tontos no hablan de microservicios. Esto se está volviendo cada vez más popular. El estilo arquitectónico modular parece particularmente adecuado para entornos basados en la nube y está ganando popularidad. Antes de entrar en detalles, echemos un vistazo a todo a vista de pájaro . Por lo tanto: Los microservicios son una forma de dividir un gran proyecto en módulos pequeños, independientes y poco acoplados. Los módulos independientes son responsables de tareas discretas y claramente definidas y se comunican entre sí a través de una API simple y accesible. En otras palabras, los microservicios son simplemente un estilo arquitectónico diferente para diseñar aplicaciones complejas, en su mayoría web. Pero ¿qué tienen de malo las soluciones arquitectónicas existentes como SOA (arquitectura orientada a servicios)? La mayoría de las soluciones empresariales modernas escritas utilizando SOA parecen funcionar bastante bien. Este podría ser un buen momento para hablar sobre algunos de los desafíos que enfrenta la industria en estos días... Comencemos con un ejemplo simple. Digamos que necesito ejecutar una aplicación clásica escrita en Java. Primero desarrollaré la interfaz de usuario, luego la capa de lógica de negocios, con varios componentes que interactuarán con la interfaz de usuario, y finalmente la capa de base de datos, a la que podrá acceder la base de datos persistente. Ahora, de acuerdo con el hecho de que quiero ejecutar la aplicación, crearé un WAR/EAR/JAR y lo montaré en un servidor (como JBoss, Tomcat o WebLogic). Como esto se hace todo en uno, obtengo una aplicación monolítica, lo que significa que todos los componentes están en un solo lugar... Ejemplo en la imagen:
Lo más probable es que ya esté familiarizado con este enfoque y lo haya utilizado, pero la idea es utilizar este ejemplo para mostrar los desafíos que los desarrolladores tendrán que enfrentar al utilizar esta solución arquitectónica. Aplicación monolítica: desafíos desafíos
A medida que la aplicación crece, también crece la cantidad de código escrito, lo que bien puede sobrecargar el entorno de desarrollo cada vez que necesita abrirla. Esto definitivamente reduce la eficiencia del desarrollador.
Como todo tiene que estar montado en un solo lugar, esto lleva al hecho de que cambiar a otro lenguaje de programación o cambiar a otras tecnologías es un gran problema. Por ejemplo, escribiste una aplicación en Java y, después de un tiempo, apareció Kotlin y estabas ansioso por reescribirla, porque se promocionó como más genial, mejor y más rápido. Con una aplicación monolítica, incluso pensar en refactorizar causará un verdadero dolor, sin mencionar el proceso en sí. Actualmente existen muchas aplicaciones que están hechas de esta manera y la cantidad de líneas de código es simplemente increíble.
Si alguno de los componentes deja de funcionar por algún motivo , toda la aplicación también fallará. Imagínense que existe una aplicación web que tiene módulos como autorización, pago, historial, etc. Y por alguna razón uno de ellos se rompe. Esto es simplemente un shock para las empresas y, en consecuencia, para los desarrolladores.
El escalado de una aplicación monolítica solo se puede lograr generando otra aplicación del mismo tipo. Pero, ¿qué pasa si solo necesita escalar un componente y no toda la aplicación? ¿Cuántos recursos se desperdiciarán?...
Esto puede tener un gran impacto en el proceso de desarrollo y el proceso de instalación de la aplicación. Cuanto más grande es la aplicación, más importante es que los desarrolladores puedan dividirla en partes de trabajo más pequeñas. Debido a que todos los módulos de una aplicación monolítica están conectados entre sí, los desarrolladores no pueden trabajar/montar estos módulos de forma independiente unos de otros. Dado que los desarrolladores dependen unos de otros, el tiempo de desarrollo aumenta.
Al mismo tiempo, estamos preparados para considerar y comprender el significado de los microservicios, es decir, cómo se pueden utilizar para restaurar la flexibilidad que se perdió con el estilo SOA. Dios Microservicios al rescate Una de las características más importantes en cualquier solución arquitectónica es la escalabilidad. Mientras aprendía sobre microservicios por primera vez, vi que todo era muy parecido a las citas del libro "El arte de la escalabilidad". Este es un gran comienzo y lugar para la discusión. Este libro define el llamado modelo "Cubo de escalabilidad", que describe un sistema de escalabilidad tridimensional:
Como puede ver, el eje X describe el "escalado horizontal" (que hemos visto también está disponible para arquitecturas monolíticas), el eje Y representa el escalado en el sentido de separar diferentes componentes de servicio . La idea del eje Z se entiende cuando se dividen los datos y la aplicación envía solicitudes exactamente a donde se encuentran los datos. Es decir, no están todos en un mismo lugar. La idea del eje Y es en la que nos centraremos con más detalle. Este eje representa una descomposición funcional . En esta estrategia, diferentes funciones pueden considerarse servicios independientes. Por lo tanto, al montar la aplicación completa sólo cuando todo esté hecho, los desarrolladores pueden montar servicios individuales de forma independiente y no esperar a que otros terminen de trabajar en sus módulos. Esto no sólo mejorará el tiempo de desarrollo, sino que también ofrecerá la flexibilidad de cambiar y volver a cablear sin tener que preocuparse por el resto de los componentes de la aplicación. Comparemos este diagrama con el monolítico anterior:
Microservicios: beneficios Los beneficios de los microservicios parecen ser suficientes para convencer a los desarrolladores empresariales como Amazon, Netflix y Ebay de que comiencen a utilizar este enfoque. A diferencia de las aplicaciones de arquitectura monolítica, los microservicios:
Mejora el aislamiento de fallas de los componentes: las aplicaciones grandes pueden continuar ejecutándose de manera eficiente incluso si falla un solo módulo.
Elimina el compromiso de la aplicación con una pila de tecnología: si desea probar una nueva pila de tecnología en algún servicio, adelante. Las dependencias serán mucho más ligeras que con una monolítica y también será mucho más fácil revertir todo. Cuanto menos código haya en una aplicación, más fácil será trabajar.
Hace que sea mucho más fácil para los nuevos empleados comprender la funcionalidad del servicio.
Microservicios: características de montaje y virtualización Ahora entendemos qué son los microservicios. Y la mayor ventaja es que está montado por más de un archivo WAR/EAR/JAR. ¿Pero cómo se instala? La mejor forma de montar microservicios dentro de contenedores. Un contenedor es un sistema operativo virtual completamente configurado con el entorno necesario configurado, lo que ayuda a aislar el acceso a los recursos del sistema de hardware en el que está instalado el contenedor. La solución más famosa del mercado es, por supuesto, Docker . Las máquinas virtuales de IaaS (infraestructura como servicio), como AWS, también pueden funcionar bien para montar microservicios, pero es posible que los microservicios relativamente livianos no utilicen todos los recursos que hay en la máquina virtual, lo que puede reducir la rentabilidad de uso. También puede montar sus microservicios utilizando el paquete OSGI (Open Service Gateway Initiative). En este caso, todos los microservicios se ejecutarán en una única JVM, pero esto implica problemas de equilibrio entre control y aislamiento. Microservicios: desventajas El hecho de que “todo esto está bien” y “no hemos visto esto antes” no significa que no haya desventajas. A continuación se muestra una lista de posibles áreas problemáticas que trae consigo la arquitectura de microservicios:
Desarrollar sistemas distribuidos puede resultar complicado. Con esto quiero decir que ahora todos los componentes son servicios independientes; es necesario manejar con mucho cuidado las solicitudes que pasan entre módulos. Puede haber un escenario en el que un módulo no responda, lo que le obligará a escribir código adicional para evitar que el sistema falle. Esto puede resultar más difícil si las llamadas remotas son sensibles a la latencia .
Múltiples bases de datos y gestión de transacciones pueden ser una verdadera molestia.
probar aplicaciones de microservicios puede resultar engorroso. Usando una aplicación monolítica, solo necesitamos ejecutar el archivo WAR/EAR/JAR en el servidor y asegurarnos de que esté conectado a la base de datos. Y en los microservicios, cada servicio individual debe iniciarse antes de que puedan comenzar las pruebas.
Las aplicaciones de montaje pueden ser complicadas. Es posible que requieran coordinación en torno a múltiples servicios que pueden no ser tan fáciles de montar como un contenedor WAR.
.... Por supuesto, con las herramientas y enfoques adecuados estas desventajas se pueden evitar. Pero ellos mismos requieren apoyo y no resuelven completamente todos los problemas. El artículo fue traducido del sitio web de CloudAcademy . Traducción libre. Todos son libres de expresar todos sus pensamientos en los comentarios. Definitivamente serán leídos. Artículo original Mi cuenta de Github
GO TO FULL VERSION