Sembla que el cim de l'exageració dels microserveis ha quedat enrere. Ja no llegim publicacions diverses vegades a la setmana "Com vaig traslladar el meu monòlit a 150 serveis". Ara sento més pensaments de sentit comú: "No odio el monòlit, només m'importa l'eficiència". Fins i tot vam observar diverses migracions . Quan passeu d'una aplicació gran a diversos serveis més petits, haureu de resoldre diversos problemes nous. Anem a enumerar-los el més breument possible.
Entorn: de la química bàsica a la mecànica quàntica
Configurar una base de dades i una aplicació bàsica amb un procés de fons va ser un procés bastant senzill. Publico el readme a Github, i sovint després d'una hora, un parell d'hores com a màxim, tot funciona i començo un nou projecte. Afegir i executar codi, almenys per a l'entorn inicial, es fa el primer dia. Però si ens aventurem en els microserveis, el temps de llançament inicial es dispara. Sí, ara tenim Docker amb orquestració i un clúster de màquines K8, però per a un programador novell tot això és molt més complicat. Per a molts joves, aquesta és una càrrega que és realment una complicació innecessària.
El sistema no és fàcil d'entendre
Centrem-nos un moment en el nostre júnior. Amb les aplicacions monolítices, si es produïa un error, era fàcil localitzar-lo i passar immediatament a la depuració. Ara tenim un servei que parla amb un altre servei que està posant a la cua alguna cosa en un bus de missatges que està processant un altre servei, i llavors es produeix un error. Hem d'ajuntar totes aquestes peces per esbrinar que el servei A està executant la versió 11 i el servei E ja està esperant la versió 12. Això és molt diferent del meu registre consolidat estàndard: haver d'utilitzar un terminal/depurador interactiu per caminar. a través del procés pas a pas. La depuració i la comprensió s'han tornat inherentment més difícils.
Si no es pot depurar, potser els provarem
La integració contínua i el desenvolupament continu s'estan convertint en un lloc habitual. La majoria de les aplicacions noves que veig creen i executen proves automàticament amb cada versió nova i requereixen que es facin i revisin proves abans del registre. Són grans processos que no s'han d'abandonar i que han suposat un gran canvi per a moltes empreses. Però ara, per provar realment el servei, he de treure una versió completa de la meva aplicació. Recordeu aquell nou enginyer amb el clúster K8 de 150 serveis? Bé, ara ensenyarem al nostre sistema CI com mostrar tots aquests sistemes per verificar que tot funciona realment. Probablement això sigui massa esforç, així que provarem cada part de manera aïllada: estic segur que les nostres especificacions són prou bones, les API estan netes i una fallada del servei està aïllada i no afectarà els altres.
Tots els compromisos tenen una bona raó. Dret?
Hi ha moltes raons per passar als microserveis. Ho he vist fer per a una major flexibilitat, per escalar els equips, per al rendiment, per oferir una millor sostenibilitat. Però, en realitat, hem invertit dècades en eines i pràctiques per desenvolupar monòlits que continuen evolucionant. Treballo amb professionals de diferents tecnologies. Normalment parlem d'escala perquè s'arriba als límits d'un sol node de base de dades Postgres. La majoria de les converses són sobre .
Però sempre m'interessa conèixer la seva arquitectura. En quina fase de la transició als microserveis es troben? És interessant veure que més enginyers diuen que estan contents amb la seva aplicació monolítica. Moltes persones es beneficiaran dels microserveis i els avantatges superaran els inconvenients del camí de migració. Però personalment, si us plau, doneu-me la meva aplicació monolítica, un lloc a la platja, i estic completament feliç.
Font: www.habr.com