Introducción En la economía moderna, la creación de software es toda una industria. Por un lado, ayuda a las empresas a automatizar y digitalizar todos los procesos y, por otro lado, genera ganancias y crea activos virtuales. Actualmente, la I+D se ha vuelto más complicada, el número de programadores crece constantemente y las tareas de TI se vuelven más complejas. Estas razones han llevado al surgimiento de nuevas metodologías de desarrollo de software y tipos de arquitectura. Las aplicaciones web modernas son multifuncionales y la transformación digital aumenta los requisitos de software. La aplicación debe ser: fácilmente escalable, flexible y multiplataforma, y modificable para las tareas del usuario. Los administradores de tareas establecen estos requisitos en la etapa de desarrollo de dicho software. En primer lugar, para crear software para empresas modernas, debe estudiar seriamente el proceso de desarrollo de software y elegir la arquitectura adecuada. La elección de la arquitectura en el desarrollo de software Por regla general, anteriormente todas las aplicaciones se desarrollaban sobre la base de una arquitectura monolítica. Echemos un vistazo a lo que es una aplicación monolítica. Las aplicaciones monolíticas se desarrollan como un todo. La lógica para el procesamiento de solicitudes se coloca dentro de un solo proceso. Las aplicaciones web de Monolith se pueden estructurar en forma de módulos y bloques. Se utilizan clases separadas, funciones, etc., dependiendo del lenguaje de programación utilizado. Pero las conexiones entre los módulos son muy fuertes. Esto lleva a la siguiente conclusión: cambiar cualquier módulo afectará en gran medida el funcionamiento de toda la aplicación. Por ejemplo, podemos considerar una aplicación web típica para LMS (sistema de gestión de aprendizaje). Este software tiene una arquitectura de tres niveles, que incluye: interfaz de usuario; el componente del lado del servidor para la lógica empresarial del software y el acceso a los datos; la base de datos. Las funciones comerciales de una aplicación de este tipo son muy diferentes. Incluye los siguientes bloques: "Cursos y formación", "Catálogo de cursos", "Estructura organizativa de la empresa", "Calendario de eventos", "Informes", "Mensajes", "Novedades", etc. Sin embargo, todos están combinados en un solo bloque monolítico y están ubicados en un servidor. Es bastante difícil escalar y cambiar una aplicación de este tipo. Destaquemos las desventajas de la arquitectura monolítica: Incluso un pequeño cambio en una aplicación web conduce al ensamblaje y la implementación de una nueva versión de todo el software. Solo puede escalar toda la aplicación. Es imposible escalar un bloque separado. Si algún módulo de la aplicación falla, como resultado, la operación de toda la aplicación puede verse interrumpida. Las herramientas de desarrollo siempre se limitan a la pila tecnológica seleccionada. Inconveniencia en la gestión de un gran equipo de desarrolladores calificados. Cada desarrollador debe comprender toda la funcionalidad de la aplicación, no solo su módulo. Cualquier actualización afecta a toda la funcionalidad del software. Conduce al riesgo de falla de la aplicación después de las actualizaciones. Por lo tanto, solo se realizan lanzamientos raros de actualizaciones. Cualquier cambio en la base de datos puede afectar el funcionamiento de toda la aplicación y necesita cambios en el código. Si este es un pequeño programa gratuito para enseñar algunas habilidades individuales a un usuario común, e incluso se actualiza raramente, entonces una arquitectura monolítica es bastante adecuada para tal desarrollo. Si estamos hablando de software corporativo (por ejemplo, LMS), e incluso actualizado con frecuencia, entonces es necesario elegir una arquitectura de microservicio. La es el enfoque óptimo para el desarrollo de software. En una arquitectura de microservicios, la aplicación web se divide en componentes pequeños y autónomos (microservicios) con interfaces específicas. Dicha arquitectura ha encontrado su aplicación en el campo de la computación en la nube. arquitectura de microservicios ¿Cuál es la diferencia entre microservicio y arquitectura monolítica? En una arquitectura de microservicios, la aplicación web se desarrolla como un conjunto de componentes pequeños y mal interconectados, que se denominan microservicios. Los microservicios se desarrollan, implementan y mantienen casi independientemente unos de otros. Por ejemplo, una aplicación web para LMS. Cada microservicio está orientado a resolver solo su tarea comercial específica, tiene su base de datos y contactos con otros microservicios a través de la API. Así, será necesario desarrollar los siguientes microservicios para la aplicación web LMS: “Cursos y capacitaciones”, “Catálogo de cursos”, “Estructura organizacional de la empresa”, “Calendario de eventos”, “Reportes”, “Mensajes”, "Noticias", etc Pero debe tenerse en cuenta que existe otro tipo de arquitectura: una arquitectura orientada a servicios (SOA). A veces se confunde con microservicio. Parece que las diferencias entre la arquitectura de microservicios y SOA no son tan obvias. Pero hay diferencias entre microservicios y SOA. Esto se refiere al papel del bus de servicios empresariales (ESB). SOA es una arquitectura para toda la empresa. Su objetivo es estandarizar la interacción e integración de los servicios web de la empresa. El propósito de la arquitectura de microservicios es desarrollar una aplicación específica. Las siguientes plantillas están relacionadas con SOA: CORBA, servicios web, colas de mensajes, ESB, etc. A continuación te contamos en detalle las ventajas de los microservicios para el desarrollo de aplicaciones web. Las principales ventajas de la arquitectura de microservicios Evaluaremos las ventajas de los microservicios en comparación con una arquitectura monolítica. Sencillez e independencia en el despliegue de aplicaciones. En el caso de los microservicios, puede implementar solo un módulo de aplicación. Por ejemplo, en nuestro caso con LMS, puede implementar solo un módulo ("Calendario de eventos"), dejando el resto de los componentes de la aplicación sin cambios. Si necesita volver a escribir el código en el módulo "Informes", entonces no es necesario obtener muchos permisos. Este componente ("Informes") es un microservicio separado e independiente. Escalabilidad: precisión y eficiencia. En primer lugar, debe determinar qué microservicios requerirán escalabilidad frecuente y cuáles no. Los módulos que no necesitan escalarse con frecuencia, se pueden colocar en servidores más débiles y, a menudo, los escalables se pueden escalar por separado del resto del software. Mayor resiliencia de la aplicación. El diseño de aplicaciones racionales y la creación de conexiones independientes entre módulos brindan la siguiente ventaja: la falla de uno de los módulos no provoca la falla de todo el software. Por ejemplo, si el módulo "Mensajes" ha fallado, el usuario recibirá una notificación sobre la indisponibilidad temporal de este bloque. Todos los demás bloques de aplicaciones funcionarán. Selección de pilas tecnológicas. Al desarrollar cada microservicio, puede elegir la pila tecnológica más adecuada. Flexibilidad en la gestión de equipos. Por ejemplo, el equipo No. 1 desarrolla el servicio "Catálogo de cursos", el equipo No. 2 — "Calendario de eventos" y el equipo No. 3 — "Noticias". Es por eso que es más fácil para un nuevo especialista comenzar a trabajar más rápido. No es necesario estudiar la funcionalidad de toda la aplicación durante mucho tiempo, basta con aprender la pila de tecnología para un microservicio específico. La capacidad de reutilizar la funcionalidad (para diferentes propósitos y de diferentes maneras). La sustitución o eliminación de servicios innecesarios se soluciona de forma rápida y sencilla. Por ejemplo, si un cliente específico no usará el bloque "Noticias" en el LMS, entonces este módulo simplemente puede eliminarse, sin cambios globales en todo el software. Cada microservicio utiliza su base de datos. Este hecho conduce a la independencia de los modelos de datos. Por ejemplo, si un programador ha cambiado el modelo de datos en un servicio en particular, no afectará el funcionamiento de otros servicios. Como podemos ver, la arquitectura de microservicios tiene ventajas significativas y atrae cada vez más a los desarrolladores. Sin embargo, antes de elegir una arquitectura para el desarrollo de software, se deben considerar las desventajas de los microservicios. Vamos a enumerar los siguientes. Desventajas de los microservicios El sistema de microservicios es distribuido. Por un lado, esto es una ventaja en el trabajo del software. Por otro lado, si hay demasiados microservicios y cada uno de ellos realiza solicitudes a otros servicios, el tiempo de respuesta resultante aumentará y aparecerán "puntos de falla". Hay dos formas de resolver este problema: cambiar los detalles de la llamada, lo que puede conducir a una disminución en su número; la introducción de la asincronía, las llamadas se realizan en paralelo, como resultado, esto lleva al hecho de que el tiempo de respuesta final es el tiempo más lento de todos, y no el tiempo total de todos los retrasos. La constante complicación del proceso de desarrollo, que conduce a mayores requisitos para la cualificación de los programadores. En una arquitectura de microservicios, el papel de los procesos de integración y los procesos de entrega continua es excelente. Y es por eso que es bastante difícil manejar muchos procesos sin automatizar las pruebas y la implementación de servicios. Estos factores requieren la implementación de DevOps en la empresa y la estrecha colaboración de los desarrolladores con los ingenieros de sistemas, testers, soporte técnico, etc. La descentralización en la arquitectura de microservicios crea problemas con la coherencia de los microservicios. Por ejemplo, en una aplicación monolítica, se pueden realizar muchos cambios en una transacción, pero también es posible revertirlos si ocurre una falla, manteniendo la consistencia de los datos. Al usar microservicios, es posible la siguiente situación: en caso de mal funcionamiento de uno de los servicios, el otro microservicio deja de responder. En este caso, es una cuestión de prioridades del desarrollador: puede dar prioridad a la disponibilidad de los componentes (en caso de falla de un servicio, los demás seguirán funcionando). En general, los desarrolladores deben encontrar un equilibrio entre la consistencia de los servicios y su disponibilidad, y esto debe hacerse con mucho cuidado. Conclusiones Antes de elegir una arquitectura de microservicios para desarrollar aplicaciones web, los desarrolladores deben evaluar tanto sus ventajas como sus desventajas. Después de todo, la elección incorrecta de la arquitectura puede afectar el rendimiento y la funcionalidad del software en el futuro. Si la arquitectura de microservicios se usa incorrectamente, los desarrolladores pueden tener grandes problemas que anulan todas las ventajas de los microservicios. En la siguiente parte del artículo, consideraremos las herramientas técnicas que debe dominar un desarrollador que vaya a utilizar una arquitectura de microservicios en el desarrollo de software.
