Parece que o pico de publicidade dos microservizos está atrás. Xa non lemos publicacións varias veces á semana "Como movín o meu monolito a 150 servizos". Agora escoito máis pensamentos de sentido común: "Non odio o monolito, só me importa a eficiencia". Mesmo observamos varias migracións . Ao pasar dunha aplicación grande a varios servizos máis pequenos, terás que resolver varios problemas novos. Enumerémolos o máis brevemente posible.
Ambiente: da química básica á mecánica cuántica
Configurar unha base de datos e unha aplicación básica cun proceso en segundo plano foi un proceso bastante sinxelo. Publico o readme en Github, e moitas veces dentro dunha hora, un par de horas como máximo, todo funciona e comezo un novo proxecto. Engadir e executar código, polo menos para o ambiente inicial, realízase o primeiro día. Pero se nos aventuramos nos microservizos, o tempo de lanzamento inicial dispárase. Si, agora temos Docker con orquestración e un clúster de máquinas K8, pero para un programador novato todo isto é moito máis complicado. Para moitos mozos, esta é unha carga que é realmente unha complicación innecesaria.
O sistema non é doado de entender
Centrémonos un momento no noso júnior. Con aplicacións monolíticas, se se producía un erro, era doado localizalo e pasar inmediatamente á depuración. Agora temos un servizo que está a falar con outro servizo que está en cola nun bus de mensaxes que está a procesar outro servizo, e despois hai un erro. Temos que xuntar todas estas pezas para finalmente descubrir que o servizo A está a executar a versión 11, e o servizo E xa está esperando a versión 12. Isto é moi diferente do meu rexistro consolidado estándar: ter que usar un terminal/depurador interactivo para andar. a través do proceso paso a paso. A depuración e a comprensión fixéronse inherentemente máis difíciles.
Se non se pode depurar, quizais os probemos
A integración e o desenvolvemento continuos están a ser habituais. A maioría das aplicacións novas que vexo crean e executan probas automaticamente con cada nova versión e requiren que se realicen e revisen probas antes do rexistro. Son grandes procesos que non deben abandonarse e que supuxeron un gran cambio para moitas empresas. Pero agora, para probar realmente o servizo, teño que sacar unha versión completa da miña aplicación. Lembras daquel novo enxeñeiro co cluster K8 de 150 servizos? Ben, agora ensinarémoslle ao noso sistema CI como mostrar todos estes sistemas para verificar que todo funciona realmente. Probablemente sexa demasiado esforzo, polo que só probaremos cada parte de xeito illado: confío en que as nosas especificacións son suficientemente boas, as API están limpas e un fallo de servizo está illado e non afectará a outros.
Todos os compromisos teñen unha boa razón. Non?
Hai moitas razóns para pasar aos microservizos. Vin isto feito por unha maior flexibilidade, para escalar os equipos, para o rendemento, para ofrecer unha mellor sustentabilidade. Pero en realidade, investimos décadas en ferramentas e prácticas para desenvolver monólitos que seguen evolucionando. Traballo con profesionais en diferentes tecnoloxías. Normalmente falamos de escalado porque chegan aos límites dun único nodo de base de datos Postgres. A maioría das conversas son sobre .
Pero sempre estou interesado en coñecer a súa arquitectura. En que fase da transición aos microservizos se atopan? É interesante ver máis enxeñeiros dicindo que están satisfeitos coa súa aplicación monolítica. Moitas persoas beneficiaranse dos microservizos e os beneficios superarán os obstáculos na ruta de migración. Pero persoalmente, dáme a miña aplicación monolítica, un lugar na praia, e estou completamente feliz.
Fonte: www.habr.com