El 19 de septiembre, se
celebró en Moscú
el primer metap temático HUG (Highload ++ User Group), dedicado a microservicios. Se entregó el informe "Operación de microservicios: el tamaño importa incluso si tiene Kubernetes" en el que compartimos la vasta experiencia de Flant en proyectos operativos con arquitectura de microservicios. En primer lugar, será útil para todos los desarrolladores que estén pensando en aplicar este enfoque en su proyecto actual o futuro.
Presentamos el
video con el informe (50 minutos, mucho más informativo que el artículo), así como el extracto principal del mismo en forma de texto.
NB: El video y la presentación también están disponibles al final de esta publicación. Introduccion
Por lo general, una buena historia tiene una trama, una trama principal y un desenlace. Este informe es más como una trama, y trágico. También es importante tener en cuenta que proporciona un vistazo al
funcionamiento de los microservicios.
Comenzaré con ese horario, cuyo autor (en 2015)
fue Martin Fowler:
Muestra cómo, en el caso de una aplicación monolítica que ha alcanzado un cierto valor, la productividad del trabajo comienza a disminuir. Los microservicios difieren en que la productividad inicial con ellos es menor, sin embargo, a medida que crece la complejidad, la degradación de la eficiencia para ellos no es tan notable.
Complementaré este gráfico para el caso de usar Kubernetes:
¿Por qué mejoró la aplicación de microservicios? Debido a que dicha arquitectura presenta requisitos de arquitectura serios, que a su vez están perfectamente cubiertos por las capacidades de Kubernetes. Por otro lado, parte de esta funcionalidad también será útil para el monolito, especialmente porque el monolito típico de hoy no es exactamente un monolito (los detalles se detallarán más adelante en el informe).
Como puede ver, la programación final (cuando las aplicaciones monolíticas y de microservicio en la infraestructura con Kubernetes) no es muy diferente de la original. A continuación, hablaremos sobre las aplicaciones que se ejecutan con Kubernetes.
Microservicio útil y nocivo
Y aquí la idea principal:
¿Qué es una arquitectura de microservicio
normal ? Debería brindarle beneficios reales, aumentando la eficiencia del trabajo. Si vuelve a la tabla, aquí está:
Si lo llama
útil , en el otro lado del gráfico habrá un microservicio
dañino (interfiere con el trabajo):
Volviendo a la "idea principal": ¿vale la pena confiar en mi experiencia? Desde principios de este año, he analizado
85 proyectos . No todos ellos eran microservicios (aproximadamente un tercio a la mitad de ellos poseían dicha arquitectura), pero esto sigue siendo un gran número. Nosotros (las compañías de Flant) como subcontratistas logramos ver una amplia variedad de aplicaciones desarrolladas tanto en pequeñas empresas (con 5 desarrolladores) como en grandes (~ 500 desarrolladores). Una ventaja adicional es que vemos cómo estas aplicaciones viven y se desarrollan a lo largo de los años.
¿Por qué microservicios?
A la pregunta sobre los beneficios de los microservicios, el ya mencionado Martin Fowler tiene una
respuesta muy específica :
- límites claros de modularidad;
- despliegue independiente;
- libertad de elección de tecnología.
Hablé mucho con arquitectos y desarrolladores de software y les pregunté por qué necesitaban microservicios. Y compiló su lista de sus expectativas. Esto es lo que sucedió:
Si describe "en sensaciones" algunos de los puntos, entonces:
- límites claros de los módulos: aquí tenemos un monolito terrible, y ahora todo estará ordenado en repositorios Git, en el que todo está "en los estantes", no mezclado con cálido y suave;
- Independencia de implementación: podremos implementar servicios de forma independiente, de modo que el desarrollo sea más rápido (publique nuevas funciones en paralelo);
- independencia de desarrollo: podemos dar este microservicio a ese equipo / desarrollador, y al otro, para que podamos desarrollarnos más rápido;
- mayor confiabilidad: si ocurre una degradación parcial (un microservicio de 20 caídas), entonces solo un botón dejará de funcionar y el sistema en su conjunto continuará funcionando.
Arquitectura de microservicio típica (dañina)
Para explicar por qué en realidad no todo es lo que esperamos, presentaré una imagen
colectiva de la arquitectura de microservicios basada en la experiencia de muchos proyectos diferentes.
Un ejemplo sería una tienda en línea abstracta a punto de competir con Amazon o al menos OZON. Su arquitectura de microservicio se ve así:
Por una combinación de razones, estos microservicios están escritos en diferentes plataformas:
Como cada microservicio debería 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
tiene un artículo sobre este tema, sobre la "recuperación" por el uso de microservicios:
Y veremos si se cumplen nuestras expectativas.
Límites claros de los módulos ...
Pero,
¿cuántos microservicios necesitamos realmente arreglar para implementar el cambio? ¿Podemos incluso 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 de "
gran trozo de lodo ", pero aquí tenemos un trozo de lodo distribuido. En apoyo de esto, aquí hay una ilustración de ejemplo de cómo van las consultas:
Despliegue Independencia ...
Técnicamente, se ha logrado: podemos rodar cada microservicio por separado. Pero en la práctica, debe tener en cuenta que
muchos microservicios siempre se implementan, y debemos tener en cuenta el
orden de su implementación . En el buen sentido, generalmente necesitamos probar en un circuito separado si estamos implementando la versión en el orden correcto.
Libertad para elegir la tecnología ...
Ella esta ahi. Solo vale la pena recordar que a menudo la libertad raya en la ilegalidad. Aquí es muy importante no elegir tecnologías solo para "jugar" con ellas.
Independencia del desarrollo ...
¿Cómo hacer un circuito de prueba para toda la aplicación (de tantos componentes)? Pero aún necesita mantenerlo actualizado. Todo esto lleva al hecho de que el
número real de bucles de prueba , que, en principio, podemos contener,
es mínimo .
¿Pero desplegar todo esto localmente? ... Resulta que a menudo el desarrollador hace su trabajo de forma independiente, pero al azar, porque tiene que esperar hasta que se libere el circuito de prueba.
Escalado por separado ...
Sí, pero está limitado en el área de DBMS utilizado. En el ejemplo de arquitectura dado, Cassandra no tendrá problemas, pero MySQL y PostgreSQL lo tendrán.
Más confiabilidad ...
No solo eso, de hecho, la falla de un microservicio a menudo rompe el funcionamiento correcto de todo el sistema, también hay un nuevo problema:
es muy difícil hacer que cada microservicio sea tolerante a fallas . Debido a que los microservicios usan diferentes tecnologías (memcache, Redis, etc.), todos necesitan pensar e implementar todo lo que, por supuesto, es posible, pero requiere enormes recursos.
Medibilidad de carga ...
Todo está muy bien con esto.
Ligereza de microservicios ...
No solo obtuvimos enormes
gastos generales de red (consultas DNS, etc.), sino que también debido a las muchas subconsultas, comenzamos a
replicar los datos (almacenar cachés), lo que condujo a una cantidad significativa de almacenamiento.
Y aquí está el resultado de cumplir con 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? La única opción real es desactivar el tráfico para esto. ¿Pero cómo hacerlo en producción?
- Si hablamos de apoyar a varias regiones, organizar la sostenibilidad en cada una de ellas es una tarea que requiere mucho tiempo.
- Existe el problema de realizar cambios centralizados. Por ejemplo, si necesitamos actualizar la versión de PHP, entonces debemos comprometernos con cada repositorio (y hay docenas de ellos).
- El aumento de la complejidad operativa de manera espontánea es exponencial.
¿Qué hacer con todo esto?
Comience con una aplicación monolítica . La experiencia de Fowler
sugiere que casi todas las aplicaciones exitosas de microservicios comenzaron con un monolito, que se hizo demasiado grande, después de lo cual se rompió. Al mismo tiempo, casi todos los sistemas construidos como microservicios desde el principio experimentaron serios problemas tarde o temprano.
Otro pensamiento valioso es que para que un proyecto con una arquitectura de microservicio tenga éxito, debe conocer muy bien
tanto el área temática como la forma de hacer microservicios . Y la mejor manera de conocer el tema es hacer un monolito.
Pero, ¿y si ya estamos en esta situación?
El primer paso para resolver cualquier problema es estar de acuerdo con él y comprender que es un problema, que ya no queremos sufrir.
Si en el caso de un monolito descuidado (cuando nos hemos quedado sin oportunidades de comprar recursos para él), lo cortamos, entonces en este caso obtenemos la historia opuesta: cuando el microservicio excesivo ya no ayuda, pero interfiere, ¡
corta el exceso y amplía !
Por ejemplo, para la imagen colectiva discutida anteriormente ...
Deshágase de los microservicios más dudosos:
Combine todos los microservicios responsables de generar la interfaz:
... 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:
... en general, se puede transferir mucho más allí, habiendo obtenido 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
Mira la imagen más amplia. Muy a menudo, todos estos problemas con microservicios surgen debido al hecho de que alguien asumió su tarea, pero quería "jugar microservicios".
En la palabra "microservicios" la parte "micro" es superflua . Son "micro" solo porque son más pequeños que un gran monolito. Pero no pienses en ellos como algo pequeño.
Y para el pensamiento final, volvamos al calendario original:
La nota escrita a él
(arriba a la derecha) se reduce al hecho de que las
habilidades del equipo que realiza su proyecto son siempre primarias : 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 hacer microservicios, la historia definitivamente será fatal.
Videos y diapositivas
Video del discurso (~ 50 minutos; desafortunadamente, no transmite las numerosas emociones de los visitantes, lo que determinó en gran medida el estado de ánimo del informe, pero tal como está):
Presentación del informe:
PS
Otros informes en nuestro blog:
También te pueden interesar las siguientes publicaciones: