Dividir un programa en cientos de partes.
Todos nuestros proyectos en Código se organizan de manera sencilla:
- Todo el desarrollo es llevado a cabo por los mismos programadores.
- Cada uno comprende lo que hace cada línea de código.
- Si algo no está claro, puede aclararse y comprenderse en 5 minutos en un chat.
- Y lo más importante, cada proyecto es un gran script o página que es completamente responsable de toda la lógica de trabajo.
Este enfoque funciona en equipos pequeños. Pero, ¿qué sucede si el proyecto es mucho más complejo? Vamos a analizarlo.
Problemas del Desarrollo Monolítico
Nuestro enfoque se conoce como desarrollo monolítico. Esto significa que todos los componentes del programa se conectan en un solo punto. Por ejemplo, si creamos un servicio en línea para gestionar una lista de tareas, nuestro código puede tener funciones como:
- Registro en el servicio
- Recordatorio de contraseña
- Creación de una nueva lista de tareas
- Gestión de listas
- Creación de una nueva tarea
- Edición de tarea
- Eliminación de tarea
Para que el trabajo sea más rápido, contratamos a otros dos programadores. Cada uno hace su propio conjunto de funciones, las integra en un solo código y, como resultado, se obtiene un gran script.
El problema es que cuantos más elementos haya en el código, más difícil será mantener todo el sistema en su conjunto. Ya no será posible simplemente cambiar una línea en la función de registro, porque podría afectar al funcionamiento de las demás funciones. Por ejemplo, eliminamos el registro obligatorio por correo electrónico, pero entonces la función de recordatorio de contraseña se romperá, ya que está escrito que la contraseña debe enviarse al correo electrónico.
Además, es difícil optimizar tales proyectos si encontramos una implementación más rápida de una función. Si reemplazamos la función de edición de tareas por una más rápida, necesitaremos volver a verificar todo el resto del código y asegurarnos de que nada se haya roto. Esto requiere mucho trabajo.
Microservicios: Dividir el Programa en Partes Autónomas
La arquitectura de microservicios (MSA) es una forma de construir aplicaciones que consisten en módulos pequeños e independientes entre sí. Estas aplicaciones se denominan microservicios (MS).
Cuando un proyecto crece, una de las soluciones es dividirlo en partes separadas y luego vincularlas entre sí. Sigan estos pasos:
- Cada parte significativa del programa se traslada a un código separado que hace una sola cosa: obtener datos del servidor, enviar el nombre de usuario y la contraseña para su verificación, dar permiso al usuario para iniciar sesión, etc.
- Cada uno de estos programas puede recibir y enviar datos en un formato determinado. Gracias a esto, los programas pueden intercambiar datos y controlarse entre sí.
- Estos miniprogramas se denominan microservicios.
Cada uno de estos microservicios funciona de forma autónoma de los demás, y su única tarea es reaccionar a tiempo y correctamente a los datos recibidos y enviar una respuesta a la dirección correcta.
Ejemplo de Microservicios
Dividamos nuestro programa del principio del artículo en microservicios:
Tengan en cuenta que ahora tenemos elementos funcionales que no estaban en la imagen original: por ejemplo, representación de interfaz, solicitud de datos del usuario, envío de datos al servidor, solicitud a la base de datos.
El problema es que el programa en sí era ese complemento con funciones adicionales que hacía todo el resto del trabajo. Tan pronto como eliminamos el «panel de control» central, tuvimos que agregar algunos microservicios que asumieron este trabajo.
Ventajas y Desventajas de los Microservicios
La arquitectura de microservicios resuelve la tarea principal de los programadores en proyectos a gran escala: convierte un programa complejo y voluminoso en un conjunto de partes simples que funcionan juntas. Otras ventajas incluyen:
- Cada microservicio puede reemplazarse o reescribirse por completo sin pérdida de calidad para el proyecto, si tiene el mismo formato de comunicación con otros microservicios.
- Si es necesario, es posible ejecutar simultáneamente varios microservicios idénticos en diferentes computadoras para mejorar la estabilidad y la velocidad de la aplicación.
- Si algún microservicio falla, lo más habitual es que esto no provoque la caída de todo el servicio o programa. También es posible configurar el reinicio automático del microservicio después de una finalización anormal.
- No importa en qué idioma esté escrito el microservicio, si hace lo que se necesita y puede comunicarse con otros. Por ejemplo, para partes de alto rendimiento se puede utilizar C++, y para el resto, Java o Kotlin.
- Es posible aumentar gradualmente las capacidades de la aplicación simplemente conectando nuevos microservicios al sistema.
Pero este enfoque también tiene desventajas:
- En proyectos simples, los microservicios requerirán más tiempo, esfuerzo y atención.
- No existe un estándar único de comunicación entre microservicios. Cada empresa define el formato de los mensajes y el método de transmisión de datos.
- Si el trabajo de algunos microservicios depende del tiempo de respuesta de otros, y estos, a su vez, dependen de terceros, el tiempo de procesamiento de todas estas solicitudes puede convertirse en un problema.
- Cuantos más microservicios se ejecutan en el programa, más difícil es administrarlos para que todo funcione sin problemas. A menudo se utiliza un software especial para estos fines, como Kubernetes, pero dominarlo requiere habilidades específicas.
Ejemplo: Funcionamiento del Sistema Bajo Carga
Supongamos que tenemos dos versiones del mismo servicio: una está hecha con un código único y la otra con microservicios.
Mientras la carga esté dentro de lo normal, ambos servicios funcionan aproximadamente igual:
Pero si de repente hay más visitantes (por ejemplo, una campaña publicitaria funcionó muy bien), el servicio monolítico puede fallar bajo carga. Resulta que la base de datos no estaba optimizada para tal cantidad de solicitudes. Y si tenemos todo en microservicios, entonces un programa separado que los monitorea verá que hay demasiadas solicitudes e iniciará algunos microservicios más con procesamiento de solicitudes a la base de datos:
Miles de usuarios en línea: cómo trabajar cuando tienes un proyecto de alta carga
¿Significa esto que Ahora Cada Programa debe Escribirse en Microservicios?
No, no es necesario. Los microservicios solo son buenos para proyectos complejos o servicios con alta carga.
Pero si el equipo sabe exactamente qué fragmento de código es responsable de qué y cómo está todo relacionado en un solo todo, entonces no se necesitan microservicios, esto será una complicación innecesaria. Es como comprar una pistola de pintura profesional para pintar dos tablas en el campo, parece genial, pero los costos no valen la pena.
Entonces, existen categorías de programas para los que los microservicios son más adecuados que otros:
- nativo de la nube: la arquitectura de las aplicaciones en la nube a menudo se basa en microservicios. La nube es ideal para un sistema de pequeñas partes débilmente interconectadas;
- superaplicaciones y programas multifuncionales: cuantos más componentes y módulos, mayor será la necesidad de MSA. Especialmente si estos módulos idealmente deben implementarse utilizando diferentes tecnologías;
- aplicaciones con código voluminoso: es difícil reescribirlo por completo para cada actualización;
- programas cuyos componentes se cargan de manera diferente o la carga «fluctúa» según factores externos. Por ejemplo, tiendas en línea con demanda estacional;
- aplicaciones para las que las actualizaciones rápidas y la entrega continua son críticas, por ejemplo, relacionadas con tendencias cambiantes;
- aplicaciones con grandes equipos de desarrolladores: esta no es una característica del programa en sí, pero también es un argumento a favor de los microservicios. Cuantas más personas haya en el equipo, más difícil será mantener un monolito: cada uno tiene que tener en cuenta el trabajo de todos los demás.
Y tú, ¿ya conocías este tipo de arquitectura software? Únete a los comentarios.
