19 de septiembre en Moscú la primera reunión temática HUG (Highload++ User Group), que estuvo dedicada a los microservicios. Hubo una presentación “Operación de microservicios: el tamaño importa, incluso si tienes Kubernetes”, en la que compartimos la amplia experiencia de Flant en la operación de proyectos con arquitectura de microservicios. En primer lugar, será útil para todos los desarrolladores que estén pensando en utilizar este enfoque en su proyecto actual o futuro.
Presentando (50 minutos, mucho más informativo que el artículo), así como el extracto principal en forma de texto.
NB: El vídeo y la presentación también están disponibles al final de esta publicación.
introducción
Normalmente una buena historia tiene un comienzo, una trama principal y una resolución. Este informe es más bien un preludio, y además trágico. También es importante señalar que proporciona una visión externa de los microservicios. Operativo.
Empezaré con este gráfico, cuyo autor (en 2015) Martín Fowler:
Muestra cómo, en el caso de una aplicación monolítica que alcanza un determinado valor, la productividad comienza a disminuir. Los microservicios se diferencian en que la productividad inicial con ellos es menor, pero a medida que aumenta la complejidad, la degradación de la eficiencia no es tan notoria para ellos.
Agregaré a este gráfico para el caso de usar Kubernetes:
¿Por qué es mejor una aplicación con microservicios? Porque una arquitectura de este tipo plantea requisitos serios para la arquitectura, que a su vez están perfectamente cubiertos por las capacidades de Kubernetes. Por otro lado, parte de esta funcionalidad será útil para un monolito, especialmente porque el monolito típico hoy en día no es exactamente un monolito (los detalles se encontrarán más adelante en el informe).
Como puede ver, el gráfico final (cuando tanto las aplicaciones monolíticas como las de microservicios están en la infraestructura con Kubernetes) no es muy diferente del original. A continuación hablaremos de las aplicaciones operadas mediante Kubernetes.
Microservicios útiles y dañinos
Y aquí está la idea principal:
lo que es normal ¿Arquitectura de microservicios? Debería brindarle beneficios reales, aumentando la eficiencia de su trabajo. Si volvemos al gráfico, aquí está:
si la llamas útil, entonces en el otro lado del gráfico habrá perjudicial microservicios (interfiere con el trabajo):
Volviendo a la “idea principal”: ¿debería confiar en mi experiencia? Desde principios de este año he buscado 85 proyectos. No todos eran microservicios (entre un tercio y la mitad de ellos tenían dicha arquitectura), pero sigue siendo un número grande. Nosotros (la empresa Flant), como subcontratistas, logramos ver una amplia variedad de aplicaciones desarrolladas tanto en pequeñas empresas (con 5 desarrolladores) como en grandes (~500 desarrolladores). Un beneficio adicional es que vemos estas aplicaciones vivas y evolucionando a lo largo de los años.
¿Por qué microservicios?
A la pregunta sobre los beneficios de los microservicios hay del ya mencionado Martin Fowler:
- límites claros de modularidad;
- despliegue independiente;
- Libertad para elegir tecnologías.
Hablé mucho con arquitectos y desarrolladores de software y les pregunté por qué necesitan microservicios. Y hice mi lista de sus expectativas. Esto es lo que pasó:
Si describimos algunos de los puntos "en sensaciones", entonces:
- límites claros de los módulos: aquí tenemos un monolito terrible, y ahora todo estará cuidadosamente ordenado en los repositorios de Git, en los que todo está "en los estantes", lo cálido y lo suave no se mezclan;
- independencia de implementación: podremos implementar servicios de forma independiente para que el desarrollo sea más rápido (publicar nuevas funciones en paralelo);
- independencia de desarrollo: podemos dar este microservicio a un equipo/desarrollador, y ese a otro, gracias a lo cual podemos desarrollarnos más rápido;
- боmayor confiabilidad: si se produce una degradación parcial (un microservicio de cada 20 cae), solo un botón dejará de funcionar y el sistema en su conjunto seguirá funcionando.
Arquitectura de microservicio típica (dañina)
Para explicar por qué la realidad no es lo que esperamos, presentaré colectivo una imagen de una arquitectura de microservicio basada en la experiencia de muchos proyectos diferentes.
Un ejemplo sería una tienda online abstracta que va a competir con Amazon o al menos con OZON. Su arquitectura de microservicio se ve así:
Por una combinación de razones, estos microservicios están escritos en diferentes plataformas:
Dado que cada microservicio debe tener autonomía, muchos de ellos necesitan su propia base de datos y caché. La arquitectura final es la siguiente:
¿Cuáles son sus consecuencias?
Fowler también tiene esto — sobre el “pago” por el uso de microservicios:
Y veremos si se cumplieron nuestras expectativas.
Límites claros de los módulos...
Sino ¿Cuántos microservicios necesitamos arreglar realmente?implementar el cambio? ¿Podemos siquiera descubrir cómo funciona todo sin un rastreador distribuido (después de todo, cualquier solicitud es procesada por la mitad de los microservicios)?
Hay un patrón "“, y aquí resultó ser un terrón de tierra distribuido. Para confirmar esto, aquí hay una ilustración aproximada de cómo van las solicitudes:
Independencia de implementación...
Técnicamente, se ha logrado: podemos implementar cada microservicio por separado. Pero en la práctica hay que tener en cuenta que siempre se despliega. muchos microservicios, y debemos tener en cuenta el orden de su lanzamiento. En el buen sentido, generalmente necesitamos probar en un circuito separado si estamos implementando el lanzamiento en el orden correcto.
Libertad para elegir la tecnología...
Ella es. Sólo recuerde que la libertad a menudo linda con la anarquía. Es muy importante aquí no elegir tecnologías simplemente para “jugar” con ellas.
Independencia del desarrollo...
¿Cómo hacer un bucle de prueba para toda la aplicación (con tantos componentes)? Pero aún necesitas mantenerlo actualizado. Todo esto lleva al hecho de que número real de circuitos de prueba, que en principio podemos contener, resulta ser mínimo.
¿Qué tal implementar todo esto localmente? Resulta que a menudo el desarrollador hace su trabajo de forma independiente, pero “al azar”, porque se ve obligado a esperar hasta que el circuito esté libre para realizar pruebas.
Escala separada...
Sí, pero está limitado en el área del DBMS utilizado. En el ejemplo de arquitectura dado, Cassandra no tendrá problemas, pero MySQL y PostgreSQL sí.
Боmayor confiabilidad...
En realidad, el fallo de un microservicio no sólo a menudo interrumpe el correcto funcionamiento de todo el sistema, sino que también surge un nuevo problema: hacer que cada microservicio sea tolerante a fallas es muy difícil. Debido a que los microservicios utilizan diferentes tecnologías (Memcache, Redis, etc.), para cada uno es necesario pensar en todo e implementarlo, lo que, por supuesto, es posible, pero requiere enormes recursos.
Medición de la carga...
Esto es realmente bueno.
La "ligereza" de los microservicios...
No sólo tenemos enormes sobrecarga de red (las solicitudes de DNS se están multiplicando, etc.), pero también debido a las muchas subconsultas que iniciamos replicar datos (almacenar cachés), lo que generó una cantidad significativa de almacenamiento.
Y aquí está el resultado de cumplir nuestras expectativas:
¡Pero eso no es todo!
Porque:
- Lo más probable es que necesitemos un bus de mensajes.
- ¿Cómo hacer una copia de seguridad consistente en el momento adecuado? El único real La opción es cortar el tráfico para esto. ¿Pero cómo hacer esto en producción?
- Si hablamos de apoyar a varias regiones, entonces organizar la sostenibilidad en cada una de ellas es una tarea que requiere mucha mano de obra.
- Surge el problema de realizar cambios centralizados. Por ejemplo, si necesitamos actualizar la versión de PHP, necesitaremos comprometernos con cada repositorio (y hay docenas de ellos).
- El crecimiento de la complejidad operativa es, sin más, exponencial.
¿Qué hacer con todo esto?
Comience con una aplicación monolítica. La experiencia de Fowler que casi todas las aplicaciones de microservicios exitosas comenzaron como un monolito que se volvió demasiado grande y luego se rompió. Al mismo tiempo, casi todos los sistemas construidos como microservicios desde el principio tarde o temprano experimentaron problemas graves.
Otro pensamiento valioso es que para que un proyecto con arquitectura de microservicio tenga éxito, debes conocer muy bien y área temática, y cómo hacer microservicios.. Y la mejor manera de aprender un área temática es hacer un monolito.
Pero ¿y si ya estamos en esta situación?
El primer paso para solucionar cualquier problema es estar de acuerdo con él y entender que es un problema, que no queremos sufrir más.
Si, en el caso de un monolito demasiado grande (cuando se nos acabó la oportunidad de comprarle recursos adicionales), lo cortamos, entonces en este caso resulta la historia opuesta: cuando los microservicios excesivos ya no ayudan, sino que obstaculizan. cortar el exceso y ampliar!
Por ejemplo, para la imagen colectiva discutida anteriormente...
Deshazte de los microservicios más cuestionables:
Combine todos los microservicios responsables de la generación del frontend:
... en un microservicio, escrito en un lenguaje/marco (moderno y normal, como usted mismo piensa):
Tendrá un ORM (un DBMS) y primero un par de aplicaciones:
... pero en general puedes transferir mucho más allí, obteniendo el siguiente resultado:
Además, en Kubernetes ejecutamos todo esto en instancias separadas, lo que significa que aún podemos medir la carga y escalarlas por separado.
Resumiendo
Mirar el cuadro más grande. Muy a menudo, todos estos problemas con los microservicios surgen porque alguien asumió su tarea, pero quería "jugar con los microservicios".
En la palabra "microservicios", la parte "micro" es redundante.. Son "micro" sólo porque son más pequeños que un enorme monolito. Pero no los consideres algo pequeño.
Y para una reflexión final, volvamos al gráfico original:
Una nota escrita en él (parte superior derecha) se reduce al hecho de que las habilidades del equipo que hace tu proyecto son siempre primordiales — desempeñarán un papel clave en su elección entre microservicios y un monolito. Si el equipo no tiene suficientes habilidades, pero comienza a crear microservicios, la historia definitivamente será fatal.
Vídeos y diapositivas
Vídeo del discurso (~50 minutos; lamentablemente no transmite las numerosas emociones de los visitantes, que determinaron en gran medida el estado de ánimo del informe, pero así es):
Presentación del informe:
PS
Otros reportajes en nuestro blog:
- «» (Dmitry Stolyarov; 28 de mayo de 2018 en RootConf);
- «» (Dmitry Stolyarov; 7 de noviembre de 2017 en HighLoad++);
- «» (Dmitry Stolyarov; 6 de junio de 2017 en RootConf);
- «» (Dmitry Stolyarov; 8 de noviembre de 2016 en HighLoad++);
- «» (Dmitry Stolyarov; 31 de mayo de 2016 en RootConf).
También te pueden interesar las siguientes publicaciones:
- «";
- «";
- «".
Fuente: habr.com