19 de setembro en Moscova o primeiro encontro temático HUG (Highload++ User Group), que estivo adicado aos microservizos. Houbo unha presentación "Operating Microservices: Size Matters, Even If You Have Kubernetes", na que compartimos a ampla experiencia de Flant na operación de proxectos con arquitectura de microservizos. En primeiro lugar, será útil para todos os desenvolvedores que estean pensando en utilizar este enfoque no seu proxecto actual ou futuro.
Presentando (50 minutos, moito máis informativo que o artigo), así como o extracto principal deste en forma de texto.
NB: O vídeo e a presentación tamén están dispoñibles ao final desta publicación.
Introdución
Normalmente unha boa historia ten un comezo, unha trama principal e unha resolución. Este informe é máis ben un preludio e, por diante, tráxico. Tamén é importante ter en conta que ofrece unha visión externa dos microservizos. explotación.
Comezarei con este gráfico, cuxo autor (en 2015) Martin Fowler:
Mostra como, no caso dunha aplicación monolítica que alcanza un valor determinado, a produtividade comeza a diminuír. Os microservizos son diferentes en que a produtividade inicial con eles é menor, pero a medida que aumenta a complexidade, a degradación da eficiencia non é tan notable para eles.
Engaderei a este gráfico para o caso de usar Kubernetes:
Por que é mellor unha aplicación con microservizos? Porque tal arquitectura presenta requisitos serios para a arquitectura, que á súa vez están perfectamente cubertos polas capacidades de Kubernetes. Por outra banda, algunhas destas funcionalidades serán útiles para un monólito, sobre todo porque o monolito típico hoxe en día non é exactamente un monólito (os detalles serán máis adiante no informe).
Como podes ver, o gráfico final (cando tanto as aplicacións monolíticas como as de microservizos están na infraestrutura con Kubernetes) non é moi diferente da orixinal. A continuación falaremos das aplicacións operadas mediante Kubernetes.
Microservizos útiles e prexudiciais
E aquí está a idea principal:
Que é normal arquitectura de microservizos? Deberíache traer beneficios reais, aumentando a túa eficiencia laboral. Se volvemos ao gráfico, aquí está:
Se a chamas útil, entón no outro lado da gráfica haberá prexudicial microservizos (interfire co traballo):
Volvendo á "idea principal": debería confiar na miña experiencia? Dende principios deste ano mirei 85 proxectos. Non todos eran microservizos (aproximadamente entre un terzo e a metade deles tiñan unha arquitectura deste tipo), pero este aínda é un gran número. Nós (empresa Flant) como subcontratistas logramos ver unha gran variedade de aplicacións desenvolvidas tanto en pequenas empresas (con 5 desenvolvedores) como en grandes (~500 desenvolvedores). Unha vantaxe adicional é que vemos que estas aplicacións viven e evolucionan ao longo dos anos.
Por que microservizos?
Á pregunta sobre as vantaxes dos microservizos hai do xa mencionado Martin Fowler:
- límites claros da modularidade;
- despregamento independente;
- liberdade para escoller tecnoloxías.
Falei moito con arquitectos e desenvolvedores de software e preguntei por que necesitan microservizos. E fixen a miña lista das súas expectativas. Aquí está o que pasou:
Se describimos algúns dos puntos "en sensacións", entón:
- límites claros dos módulos: aquí temos un monólito terrible, e agora todo estará ben disposto nos repositorios de Git, nos que todo está "nos andeis", o quente e o suave non se mesturan;
- independencia de implantación: poderemos lanzar servizos de forma independente para que o desenvolvemento vaia máis rápido (publicar novas funcións en paralelo);
- independencia de desenvolvemento: podemos dar este microservizo a un equipo/desenvolvedor, e aquel a outro, grazas ao cal podemos desenvolvernos máis rápido;
- боmaior fiabilidade: se se produce unha degradación parcial (un microservizo de cada 20 cae), só un botón deixará de funcionar e o sistema no seu conxunto seguirá funcionando.
Arquitectura típica de microservizos (perxudicial).
Para explicar por que a realidade non é o que esperamos, presentarei colectivo unha imaxe dunha arquitectura de microservizos baseada na experiencia de moitos proxectos diferentes.
Un exemplo sería unha tenda en liña abstracta que vai competir con Amazon ou polo menos con OZON. A súa arquitectura de microservizos ten o seguinte aspecto:
Por unha combinación de razóns, estes microservizos están escritos en diferentes plataformas:
Dado que cada microservizo debe ter autonomía, moitos deles precisan a súa propia base de datos e caché. A arquitectura final é a seguinte:
Cales son as súas consecuencias?
Fowler tamén ten isto — sobre o "pago" por usar microservizos:
E veremos se as nosas expectativas se cumpriron.
Limpar os límites dos módulos...
Pero cantos microservizos realmente necesitamos arranxar?para lanzar o cambio? Podemos incluso descubrir como funciona todo sen un rastreador distribuído (despois de todo, calquera solicitude é procesada pola metade dos microservizos)?
Hai un patrón"“, e aquí resultou ser un terrón de sucidade repartido. Para confirmalo, aquí tes unha ilustración aproximada de como van as solicitudes:
Independencia de implantación...
Tecnicamente, conseguiuse: podemos lanzar cada microservizo por separado. Pero na práctica hai que ter en conta que sempre se desenvolve moitos microservizos, e hai que ter en conta a orde do seu lanzamento. En boa forma, xeralmente necesitamos probar nun circuíto separado se estamos a lanzar a versión na orde correcta.
Liberdade para escoller tecnoloxía...
Ela é. Só lembra que a liberdade adoita rozar a ilegalidade. Aquí é moi importante non escoller tecnoloxías só para "xogar" con elas.
Independencia de desenvolvemento...
Como facer un bucle de proba para toda a aplicación (con tantos compoñentes)? Pero aínda debes mantelo actualizado. Todo isto leva a que número real de circuítos de proba, que en principio podemos conter, resulta ser mínimo.
Que tal implementar todo isto localmente?... Resulta que moitas veces o desenvolvedor fai o seu traballo de forma independente, pero "ao chou", porque se ve obrigado a esperar ata que o circuíto estea libre para probar.
Escalado separado...
Si, pero está limitado no ámbito do DBMS utilizado. No exemplo de arquitectura dado, Cassandra non terá problemas, pero si MySQL e PostgreSQL.
Боmaior fiabilidade...
Non só a falla dun microservizo en realidade adoita romper o correcto funcionamento de todo o sistema, senón que tamén hai un novo problema: facer que todos os microservizos sexan tolerantes a fallos é moi difícil. Debido a que os microservizos empregan tecnoloxías diferentes (memcache, Redis, etc.), para cada un hai que pensar en todo e implementalo, o que, por suposto, é posible, pero require de enormes recursos.
Medición de carga...
Isto é moi bo.
A "lixeireza" dos microservizos...
Non só temos enormes sobrecarga da rede (as solicitudes de DNS están a multiplicarse, etc.), pero tamén polas moitas subconsultas que iniciamos replicar datos (almacenar cachés), o que levou a unha cantidade significativa de almacenamento.
E aquí está o resultado de cumprir as nosas expectativas:
Pero iso non é todo!
Porque:
- O máis probable é que necesitemos un bus de mensaxes.
- Como facer unha copia de seguridade consistente no momento axeitado? O único real opción é desactivar o tráfico para iso. Pero como facelo na produción?
- Se falamos de apoiar varias rexións, entón organizar a sustentabilidade en cada unha delas é unha tarefa moi intensiva en man de obra.
- Xorde o problema de facer cambios centralizados. Por exemplo, se necesitamos actualizar a versión de PHP, teremos que comprometernos con cada repositorio (e hai ducias deles).
- O crecemento da complexidade operativa é, sen dúbida, exponencial.
Que facer con todo isto?
Comeza cunha aplicación monolítica. A experiencia de Fowler que case todas as aplicacións exitosas de microservizos comezaron como un monólito que se fixo demasiado grande e despois rompeuse. Ao mesmo tempo, case todos os sistemas construídos como microservizos desde o principio, tarde ou cedo experimentaron serios problemas.
Outro pensamento valioso é que para que un proxecto cunha arquitectura de microservizos teña éxito, debes saber moi ben e área temática, e como facer microservizos. E a mellor forma de aprender unha materia é facer un monólito.
Pero e se xa estamos nesta situación?
O primeiro paso para solucionar calquera problema é estar de acordo con el e entender que é un problema, que non queremos sufrir máis.
Se, no caso dun monólito superado (cando esgotamos a oportunidade de mercar recursos adicionais para el), o cortamos, entón neste caso sucede a historia oposta: cando os microservizos excesivos xa non axudan, pero dificultan - cortar o exceso e aumentar!
Por exemplo, para a imaxe colectiva comentada anteriormente...
Deshacerse dos microservizos máis cuestionables:
Combina todos os microservizos responsables da xeración de frontend:
... nun só microservizo, escrito nunha linguaxe/marco (moderno e normal, como vostede mesmo pensa):
Terá un ORM (un DBMS) e primeiro un par de aplicacións:
... pero en xeral podes transferir moito máis alí, obtendo o seguinte resultado:
Ademais, en Kubernetes executamos todo isto en instancias separadas, o que significa que aínda podemos medir a carga e escalalas por separado.
Para resumir
Mira a imaxe máis grande. Moitas veces, todos estes problemas cos microservizos xorden porque alguén asumiu a súa tarefa, pero quería "xogar cos microservizos".
Na palabra "microservizos" a parte "micro" é redundante.. Son "micro" só porque son máis pequenos que un enorme monolito. Pero non penses neles como algo pequeno.
E para unha reflexión final, volvamos ao gráfico orixinal:
Unha nota escrita nel (arriba dereita) redúcese ao feito de que as habilidades do equipo que fai o teu proxecto son sempre primordiales — desempeñarán un papel fundamental na súa elección entre microservizos e un monólito. Se o equipo non ten habilidades suficientes, pero comeza a facer microservizos, a historia definitivamente será fatal.
Vídeos e diapositivas
Vídeo do discurso (~ 50 minutos; por desgraza, non transmite as numerosas emocións dos visitantes, que determinaron en gran medida o estado de ánimo da reportaxe, pero así é):
Presentación do informe:
PS
Outras reportaxes no noso blog:
- «» (Dmitry Stolyarov; 28 de maio de 2018 en RootConf);
- «» (Dmitry Stolyarov; 7 de novembro de 2017 en HighLoad++);
- «» (Dmitry Stolyarov; 6 de xuño de 2017 en RootConf);
- «» (Dmitry Stolyarov; 8 de novembro de 2016 en HighLoad++);
- «» (Dmitry Stolyarov; 31 de maio de 2016 en RootConf).
Tamén pode estar interesado nas seguintes publicacións:
- «»;
- «»;
- «».
Fonte: www.habr.com