Ola, habr. A inscrición para un novo curso está aberta agora mesmo en OTUS . Na véspera do comezo do curso, quero compartir con vós o meu artigo orixinal.
Introdución
A elección do estilo arquitectónico é unha das decisións técnicas fundamentais á hora de construír un sistema de información. Nesta serie de artigos propoño analizar os estilos arquitectónicos máis populares para aplicacións de construción e responder á pregunta de cando é o estilo arquitectónico máis preferible. No proceso de presentación, tentarei debuxar unha cadea lóxica que explique o desenvolvemento dos estilos arquitectónicos desde os monólitos ata os microservizos.
Un pouco de historia
Se intentas preguntarlles aos desenvolvedores: "Por que necesitamos microservizos?", obterás unha variedade de respostas. Escoitarás que os microservizos melloran a escalabilidade, facilitan a comprensión do código, melloran a tolerancia a fallos e, ás veces, escoitarás que che permiten "limpar o teu código". Vexamos a historia para comprender o propósito detrás da aparición dos microservizos.
En resumo, os microservizos na nosa comprensión actual xurdiron do seguinte xeito: en 2011, James Lewis, analizando o traballo de varias empresas, chamou a atención sobre a aparición dun novo patrón de "micro-aplicación", que optimizaba a SOA en termos de acelerar o despregamento de Servizos. Algo máis tarde, en 2012, nun cumio de arquitectura, o patrón foi renomeado como microservizo. Así, o obxectivo inicial de introducir microservizos era mellorar o notorio tempo de mercado.
En 2015, os microservizos estaban en plena ola. Segundo algúns estudos, nin unha soa conferencia estaba completa sen un informe sobre o tema dos microservizos. Ademais, algunhas conferencias dedicáronse exclusivamente aos microservizos. Hoxe en día, moitos proxectos comezan a usar este estilo arquitectónico e, se o proxecto contén toneladas de código legado, é probable que a migración a microservizos estea a realizarse activamente.
A pesar de todo o anterior, un número bastante pequeno de desenvolvedores aínda pode definir o concepto de "microservizo". Pero disto falaremos un pouco máis tarde...
Monolito
O estilo arquitectónico que contrasta os microservizos é o monolito (ou todo en un). Probablemente non teña sentido dicir o que é un monólito, así que enumerarei inmediatamente as desvantaxes deste estilo arquitectónico, que iniciou o desenvolvemento dos estilos arquitectónicos: tamaño, conectividade, despregamento, escalabilidade, fiabilidade e rixidez. A continuación propoño darlle unha ollada a cada unha das deficiencias por separado.
Tamaño
O monolito é moi grande. E adoita comunicarse cunha base de datos moi grande. A aplicación faise demasiado grande para que un desenvolvedor a entenda. Só aqueles que levan moito tempo traballando neste código poden traballar ben co monolito, mentres que os principiantes pasarán moito tempo intentando descubrir o monolito e non hai garantía de que o descubran. Normalmente, cando se traballa cun monólito, sempre hai algún senior "condicional" que coñeza máis ou menos ben o monólito e bate as mans doutros novos desenvolvedores nun ano e medio. Por suposto, un maior condicional é un único punto de fracaso e a súa saída pode levar á morte do monolito.
Conexión
O monólito é unha "gran bola de barro", cambios nos que pode levar a consecuencias imprevisibles. Ao facer cambios nun lugar, pode danar o monolito noutro (o mesmo "raiáchesche a orella, *@ caeu"). Isto débese ao feito de que os compoñentes do monólito teñen relacións moi complexas e, o máis importante, non obvias.
Despregamento
O despregue dun monólito, debido ás complexas relacións entre os seus compoñentes, é un proceso longo e cun ritual propio. Tal ritual non adoita estar completamente estandarizado e se transmite "oralmente".
Escalabilidade
Os módulos monolith poden ter necesidades de recursos en conflito, o que require un compromiso en termos de hardware. Imaxina que tes un monólito formado por servizos A e B. O servizo A esixe o tamaño do disco duro e o servizo B é esixente en RAM. Neste caso, ou ben a máquina na que está instalado o monólito debe soportar os requisitos de ambos os dous servizos, ou ben terás que desactivar manualmente un dos servizos.
Outro exemplo (máis clásico): o servizo A é moito máis popular que o servizo B, polo que quere que haxa 100 servizos A e 10 servizos B. De novo, dúas opcións: ou implementamos 100 monolitos completos ou nalgúns os servizos B terán que ser desactivados manualmente.
Confianza
Dado que todos os servizos están situados xuntos, se o monolito cae, todos os servizos caen á vez. De feito, isto pode non ser tan malo, polo menos non haberá fallos parciais nun sistema distribuído, pero, por outra banda, debido a un erro na funcionalidade que usa o 0.001% dos usuarios, podes perder todos os usuarios. do seu sistema.
Inercia
Debido ao tamaño do monolito, é difícil cambiar ás novas tecnoloxías. Como resultado, manter a mesma persoa maior é unha tarefa separada. A pila tecnolóxica escollida ao inicio dun proxecto pode converterse nun bloque que dificulta o desenvolvemento do produto.
Conclusión
A próxima vez falaremos de como a xente tentou resolver estes problemas pasando aos compoñentes e SOA.
Le máis:
Fonte: www.habr.com