¿Qué atrae tanto a los desarrolladores a los microservicios? No existe una tecnología revolucionaria detrás de ellos; las ventajas sobre el monolito son bastante controvertidas. Solo la facilidad con la que las herramientas modernas de desarrollo e implementación le permiten crear sistemas para ejecutar en miles de servidores. Proponemos rastrear el camino hasta el momento presente, cuando el desarrollo y la implementación de un sistema distribuido de este tipo es posible por un desarrollador. Sobre cómo los contenedores de Linux, Docker y Kubernetes han evolucionado, el papel que los contenedores de Linux, Docker y Kubernetes han jugado, dice Alexander Trekhlebov holonavt , el arquitecto corporativo de Promsvyazbank, ha estado desarrollando software durante más de 15 años. Comenzó con C ++, luego cambió a Java. Recientemente, desarrolló un backend bancario en la plataforma Spring Cloud.
Si recordamos las primeras implementaciones de ejecución de scripts (Java Script, VB Script) como parte de la visualización de páginas en un navegador, entonces estas fueron secuencias de instrucciones de un solo subproceso. El mismo JavaScript: es una tarea única. Si JS se ejecuta en el marco de una página web, y una de las instrucciones ejecutables falla o se retrasa, entonces todo lo que sucede en la página, todo el código se congela. Y no puede hacer nada, solo cierre o vuelva a cargar la página y, a veces, el navegador o todo el sistema operativo.
Claramente, no fue muy conveniente. Especialmente cuando considera el hecho de que la multitarea / subprocesamiento múltiple ya estaba en todas partes: procesadores, sistemas operativos, aplicaciones (a menos que el primer sistema operativo para dispositivos móviles fuera de una sola tarea), y JS todavía tenía un solo subproceso. Que paso entonces? Varios marcos comenzaron a aparecer uno tras otro, de una forma u otra para resolver este problema. Facebook hizo reaccionar, Google lanzó Angular.
Interfaz de tormenta multitarea y backend
¿Cómo se realiza la multitarea desde un sistema de una sola tarea? Tome instrucciones y se dispersen por diferentes transmisiones, además, por supuesto, monitoree estas transmisiones. Seguramente todavía recuerdas cómo en una de las versiones de FB apareció de repente la capacidad de escribir simultáneamente un mensaje y monitorear los cambios en la cinta. Y si de repente la cinta se caía, entonces los mensajes continuaban funcionando. Fue entonces cuando apareció la primera interfaz de usuario en la interfaz modular React. Con la ayuda del marco, la multitarea comenzó a funcionar de forma inmediata.
¿Qué tiene que ver todo esto con los microservicios? Cuando la interfaz de usuario de los bancos de Internet comenzó a proporcionar una funcionalidad bastante amplia, la congelación, y aún más la caída de la aplicación, se convirtió en un evento impactante para los usuarios. Después de todo, una cosa es que Facebook se empantanó, y otra cosa: cuando acabas de hacer un pago hipotecario y los fondos de tu cuenta no aparecían, porque había una falla en la forma de los saldos de las cuentas.
Surgió una idea simple: elementos de interfaz de usuario independientes que permiten que Angular y React se unan a elementos de fondo igualmente independientes. Cada elemento de fondo independiente es un microservicio que puede escalar, aumentar después de una falla, etc.
Es importante construir correctamente la interfaz de usuario para que se modifique en función de los componentes de back-end disponibles. Si algo no funciona para usted en el back-end, entonces no muestra la funcionalidad correspondiente en la interfaz de usuario, o lo muestra de alguna manera predeterminada: puede cambiar el color de la fuente a gris o mostrar una placa vacía con la inscripción "La información del saldo de la cuenta no está disponible. Llama mañana ". En realidad, tal combinación de elementos de la interfaz de usuario con microservicios ayuda a aumentar la confiabilidad general y la escalabilidad de una aplicación bancaria.
De Titanic a Docker
En mi opinión, la razón principal por la que los microservicios se han vuelto tan populares, a pesar del importante consumo de memoria y la sobrecarga en la potencia informática, es la descomposición. El resto, en general, los microservicios no tienen grandes ventajas sobre un monolito. La descomposición, en mi opinión, es cuando lo funcional se divide en ciertos bloques independientes para el lanzamiento y la implementación. Esto significa que mientras el resto de los bloques funcionan, uno puede actualizarse, a menudo sin detener su trabajo (azul, verde - despliegue), y generar una instancia adicional.
Todos estos tecnólogos aparecieron ayer y no anteayer. Las soluciones informáticas distribuidas se desarrollaron en los días de los mainframes porque la falta de recursos informáticos surgió casi de inmediato tan pronto como aparecieron estos recursos.
Comenzaron a descubrir cómo distribuir racionalmente todo esto, por ejemplo, cálculos gráficos en las estaciones de Silicon Graphix. Todo era costoso, y tales soluciones solo estaban disponibles para grandes organizaciones, sin mencionar a los desarrolladores individuales. Las estaciones mismas y el software del servidor para ellas eran muy caras, por lo que las capacidades correspondientes se desarrollaron para el kernel de Linux. Por ejemplo, la computación de gráficos por computadora para las escenas de la película "Titanic", que se lanzó en 1997, se realizó en servidores con procesadores Alpha que ejecutan Linux. La mayoría de las soluciones necesarias para la operación de sistemas distribuidos ya estaban desarrolladas y probadas en ese momento. Pero todavía era difícil para un especialista usar todas estas tecnologías, el ensamblaje, la entrega y el soporte de dicho sistema requerían serios costos laborales.
Al principio, solo había servidores físicos que debían enrutarse de alguna manera, luego comenzó la era de la virtualización, aparecieron las máquinas virtuales, el trabajo se volvió más divertido, pero aún así iniciar y detener la máquina virtual siguió siendo una acción que requería muchos recursos. Y quería que sucediera tan rápido como iniciar un proceso dentro del sistema operativo. Un gran paso hacia el lanzamiento de la tecnología "en las personas" se asoció con la llegada de los contenedores de Linux.
Un contenedor de Linux es casi un proceso de sistema, pero tiene su propia interfaz de red y mucho más que lo hizo casi como una máquina virtual. ¿Por qué casi? Porque la máquina virtual se eleva en un entorno bastante aislado. El contenedor de Linux utiliza el sistema operativo principal, cada contenedor tiene su propia versión del sistema operativo Linux, pero las llamadas al sistema se transmiten al núcleo del sistema operativo principal.
Esto tiene sus ventajas: al crear un contenedor LXC, no es necesario volver a subir el kernel. Sin embargo, trabajar con contenedores LXC en su forma original fue muy lento e inconveniente. En realidad, en algún momento apareció Docker. Esta decisión tomó todas las precauciones de implementar y administrar contenedores Linux, exponiendo una interfaz más conveniente.
El advenimiento de Docker fue el impulso para la difusión generalizada de la arquitectura de microservicios. Sí, las tecnologías se inventaron durante mucho tiempo, pero la posibilidad de su uso conveniente apareció solo en este momento. Ahora, usando Docker, un desarrollador puede literalmente emparejar varias máquinas virtuales y organizar un sistema informático distribuido, y luego actualizarlo y escalarlo dinámicamente usando un par de comandos.
Por lo tanto, las capacidades de descomposición permitieron que un amplio círculo de desarrolladores convirtiera un monolito en un conjunto de microservicios dentro de contenedores. Sin embargo, surgieron nuevas dificultades aquí. Cuando hay varias docenas de contenedores y están dispersos en varios servidores, debe administrarlos de alguna manera, acompañarlos y realizar su orquestación. Soluciones como Docker Swarm y Kubernetes ya han aparecido aquí. El desarrollador individual recibió una nueva herramienta poderosa.
Microservicios en bancos
¿Cuál es la situación con los microservicios en la industria bancaria? ¿Cuántos, por ejemplo, se requieren para respaldar la banca en línea? Hay un buen ejemplo: en el Reino Unido hay un banco totalmente digital: Monzo, no tiene back-office, sucursales, ni sitio web, es esencialmente todo en una aplicación móvil. Todo comenzó con 40 microservicios, luego su número aumentó a 300, ahora más.
Si observa la implementación en Promsvyazbank, entonces tenemos sistemas con hasta 40 microservicios implementados.
Paralelamente, se están desarrollando sistemas de desarrollo que permiten utilizar las pocas líneas de código para desarrollar los componentes principales del sistema de microservicios, que se pueden escalar y actualizar de manera sencilla. Todas estas características son muy populares en la construcción de sistemas de aprendizaje automático, el análisis de grandes cantidades de datos en tiempo real (Cloud Streaming, etc.).
Alexander Trekhlebov contará sobre su experiencia de desarrollo basada en la arquitectura de microservicios en el informe "Microservicios: tolerancia a fallas basada en la modularidad de extremo a extremo" en el 404 Internet Workers Festival , que se realizará del 6 al 7 de octubre de 2018 en Samara.