19 de setembre a Moscou la primera trobada temàtica HUG (Highload++ User Group), que es va dedicar als microserveis. Hi va haver una presentació "Microserveis operatius: la mida és important, fins i tot si teniu Kubernetes", en què vam compartir l'àmplia experiència de Flant en projectes operatius amb arquitectura de microserveis. En primer lloc, serà útil per a tots els desenvolupadors que estiguin pensant en utilitzar aquest enfocament en el seu projecte actual o futur.
Presentació (50 minuts, molt més informatiu que l'article), així com l'extracte principal en forma de text.
NB: El vídeo i la presentació també estan disponibles al final d'aquesta publicació.
Introducció
Normalment, una bona història té un principi, una trama principal i una resolució. Aquest informe és més com un preludi, i més aviat tràgic. També és important tenir en compte que proporciona una visió externa dels microserveis. explotació.
Començaré amb aquest gràfic, l'autor del qual (el 2015) Martin Fowler:
Mostra com, en el cas d'una aplicació monolítica que arriba a un valor determinat, la productivitat comença a disminuir. Els microserveis es diferencien perquè la productivitat inicial amb ells és menor, però a mesura que augmenta la complexitat, la degradació de l'eficiència no és tan notable per a ells.
Afegiré a aquest gràfic per al cas de l'ús de Kubernetes:
Per què és millor una aplicació amb microserveis? Perquè aquesta arquitectura planteja requisits seriosos per a l'arquitectura, que al seu torn estan perfectament coberts per les capacitats de Kubernetes. D'altra banda, part d'aquesta funcionalitat serà útil per a un monòlit, sobretot perquè el monòlit típic d'avui no és exactament un monòlit (els detalls es trobaran més endavant a l'informe).
Com podeu veure, el gràfic final (quan tant les aplicacions monolítices com les de microservei es troben a la infraestructura amb Kubernetes) no és gaire diferent de l'original. A continuació parlarem de les aplicacions operades amb Kubernetes.
Microserveis útils i nocius
I aquí teniu la idea principal:
el que és normal arquitectura de microservei? Hauria d'aportar-vos beneficis reals, augmentant l'eficiència del vostre treball. Si tornem al gràfic, aquí el teniu:
Si la crides útil, llavors a l'altre costat del gràfic hi haurà nocius microserveis (interfereix amb el treball):
Tornant a la "idea principal": he de confiar en la meva experiència? Des de principis d'aquest any he mirat 85 projectes. No tots eren microserveis (al voltant d'un terç a la meitat d'ells tenien aquesta arquitectura), però encara és un gran nombre. Nosaltres (empresa Flant) com a subcontractistes aconseguim veure una gran varietat d'aplicacions desenvolupades tant en petites empreses (amb 5 desenvolupadors) com en grans (~500 desenvolupadors). Un avantatge afegit és que veiem aquestes aplicacions en viu i evolucionant al llarg dels anys.
Per què microserveis?
A la pregunta sobre els beneficis dels microserveis hi ha del ja esmentat Martin Fowler:
- límits clars de la modularitat;
- desplegament independent;
- llibertat per triar tecnologies.
He parlat molt amb arquitectes i desenvolupadors de programari i he preguntat per què necessiten microserveis. I vaig fer la meva llista de les seves expectatives. Això és el que va passar:
Si descrivim alguns dels punts "en sensacions", aleshores:
- límits clars dels mòduls: aquí tenim un monòlit terrible, i ara tot estarà ordenat en repositoris Git, en què tot està "a les prestatgeries", no es barregen el càlid i el suau;
- independència de desplegament: podrem desplegar serveis de manera independent perquè el desenvolupament vagi més ràpid (publicar noves funcionalitats en paral·lel);
- independència de desenvolupament: podem donar aquest microservei a un equip/desenvolupador, i aquest a un altre, gràcies al qual podem desenvolupar-nos més ràpidament;
- боmés fiabilitat: si es produeix una degradació parcial (cau un microservei de cada 20), només un botó deixarà de funcionar i el sistema en conjunt continuarà funcionant.
Arquitectura típica de microserveis (perjudicial).
Per explicar per què la realitat no és la que esperem, presentaré col·lectiu una imatge d'una arquitectura de microservei basada en l'experiència de molts projectes diferents.
Un exemple seria una botiga en línia abstracta que competirà amb Amazon o almenys amb OZON. La seva arquitectura de microservei té aquest aspecte:
Per una combinació de motius, aquests microserveis estan escrits en diferents plataformes:
Com que cada microservei ha de tenir autonomia, molts d'ells necessiten la seva pròpia base de dades i memòria cau. L'arquitectura final és la següent:
Quines són les seves conseqüències?
Fowler també té això — sobre el "pagament" per utilitzar microserveis:
I veurem si s'han complert les nostres expectatives.
Neteja els límits dels mòduls...
Sinó quants microserveis necessitem arreglar?per desplegar el canvi? Fins i tot podem esbrinar com funciona tot sense un traçador distribuït (després de tot, qualsevol sol·licitud la processa la meitat dels microserveis)?
Hi ha un patró"", i aquí va resultar ser un terròs de brutícia distribuït. Per confirmar-ho, aquí teniu una il·lustració aproximada de com van les sol·licituds:
Independència de desplegament...
Tècnicament, s'ha aconseguit: podem desplegar cada microservei per separat. Però a la pràctica cal tenir en compte que sempre es desplega molts microserveis, i hem de tenir en compte l'ordre del seu desplegament. En bona manera, generalment hem de provar en un circuit separat si estem llançant la versió en l'ordre correcte.
Llibertat per triar tecnologia...
Ella és. Només recordeu que la llibertat sovint limita amb la il·legalitat. Aquí és molt important no triar tecnologies només per "jugar" amb elles.
Independència del desenvolupament...
Com fer un bucle de prova per a tota l'aplicació (amb tants components)? Però encara cal mantenir-lo actualitzat. Tot això porta al fet que nombre real de circuits de prova, que en principi podem contenir, resulta ser mínim.
Què tal de desplegar tot això localment?... Resulta que sovint el desenvolupador fa la seva feina de manera independent, però "a l'atzar", perquè es veu obligat a esperar fins que el circuit estigui lliure per a la prova.
Escalat independent...
Sí, però està limitat a l'àrea del SGBD utilitzat. En l'exemple d'arquitectura donat, Cassandra no tindrà problemes, però MySQL i PostgreSQL sí.
Боmés fiabilitat...
No només la fallada d'un microservei en realitat sovint trenca el correcte funcionament de tot el sistema, sinó que també hi ha un nou problema: fer que cada microservei sigui tolerant a errors és molt difícil. Com que els microserveis utilitzen diferents tecnologies (memcache, Redis, etc.), per a cadascun cal pensar-ho tot i implementar-ho, cosa que, és clar, és possible, però requereix uns recursos enormes.
Mesurabilitat de càrrega...
Això és realment bo.
La "lleugeresa" dels microserveis...
No només tenim grans sobrecàrrega de la xarxa (les sol·licituds de DNS es multipliquen, etc.), però també a causa de les moltes subconsultes que hem iniciat replicar dades (emmagatzema memòria cau), que va provocar una quantitat important d'emmagatzematge.
I aquest és el resultat de complir les nostres expectatives:
Però això no és tot!
Perquè:
- El més probable és que necessitem un bus de missatges.
- Com fer una còpia de seguretat coherent en el moment adequat? L'únic real L'opció és desactivar el trànsit per això. Però, com fer-ho en producció?
- Si estem parlant de donar suport a diverses regions, aleshores organitzar la sostenibilitat en cadascuna d'elles és una tasca molt intensiva en mà d'obra.
- Es planteja el problema de fer canvis centralitzats. Per exemple, si necessitem actualitzar la versió de PHP, haurem de comprometre's amb cada repositori (i n'hi ha desenes).
- El creixement de la complexitat operativa és, evidentment, exponencial.
Què fer amb tot això?
Comenceu amb una aplicació monolítica. L'experiència de Fowler que gairebé totes les aplicacions de microservei reeixides van començar com un monòlit que es va fer massa gran i després es va trencar. Al mateix temps, gairebé tots els sistemes construïts com a microserveis des del principi, tard o d'hora, van experimentar problemes greus.
Un altre pensament valuós és que perquè un projecte amb una arquitectura de microservei tingui èxit, cal saber-ho molt bé i àrea temàtica, i com fer microserveis. I la millor manera d'aprendre una matèria és fer un monòlit.
Però, i si ja estem en aquesta situació?
El primer pas per resoldre qualsevol problema és estar d'acord amb ell i entendre que és un problema, que no volem patir més.
Si, en el cas d'un monòlit cobert (quan ens hem quedat sense l'oportunitat de comprar-hi recursos addicionals), el tallem, en aquest cas resulta la història contrària: quan els microserveis excessius ja no ajuden, sinó que dificulten: tallar l'excés i augmentar!
Per exemple, per a la imatge col·lectiva comentada anteriorment...
Desfer-se dels microserveis més qüestionables:
Combina tots els microserveis responsables de la generació de frontend:
... en un microservei, escrit en un llenguatge/marc (modern i normal, com tu mateix penses):
Tindrà un ORM (un DBMS) i primer un parell d'aplicacions:
... però en general pots transferir-hi molt més, obtenint el següent resultat:
A més, a Kubernetes executem tot això en instàncies separades, el que significa que encara podem mesurar la càrrega i escalar-les per separat.
Resumint
Mireu la imatge més gran. Molt sovint, tots aquests problemes amb els microserveis sorgeixen perquè algú va assumir la seva tasca, però volia "jugar amb els microserveis".
A la paraula "microserveis" la part "micro" és redundant.. Són "micro" només perquè són més petits que un monòlit enorme. Però no els penseu com una cosa petita.
I per a una reflexió final, tornem al gràfic original:
Hi ha escrit una nota (dalt a la dreta) es redueix al fet que les habilitats de l'equip que fa el teu projecte sempre són primordials — tindran un paper clau en la vostra elecció entre microserveis i un monòlit. Si l'equip no té prou habilitats, però comença a fer microserveis, la història definitivament serà fatal.
Vídeos i diapositives
Vídeo del discurs (~50 minuts; malauradament, no transmet les nombroses emocions dels visitants, que van determinar en gran mesura l'estat d'ànim del reportatge, però així és):
Presentació de l'informe:
PS
Altres reportatges al nostre blog:
- «» (Dmitry Stolyarov; 28 de maig de 2018 a RootConf);
- «» (Dmitry Stolyarov; 7 de novembre de 2017 a HighLoad++);
- «» (Dmitry Stolyarov; 6 de juny de 2017 a RootConf);
- «» (Dmitry Stolyarov; 8 de novembre de 2016 a HighLoad++);
- «» (Dmitry Stolyarov; 31 de maig de 2016 a RootConf).
També us poden interessar les següents publicacions:
- «»;
- «»;
- «».
Font: www.habr.com