Hola, habr. La inscripció per a un nou flux de cursos està oberta ara mateix a OTUS . A la vigília de l'inici del curs, vull compartir amb vosaltres el meu article original.
Introducció
L'elecció de l'estil arquitectònic és una de les decisions tècniques fonamentals a l'hora de construir un sistema d'informació. En aquesta sèrie d'articles, proposo analitzar els estils arquitectònics més populars per a les aplicacions de construcció i respondre a la pregunta de quan quin estil arquitectònic és més preferible. En el procés de presentació, intentaré dibuixar una cadena lògica que expliqui el desenvolupament dels estils arquitectònics des dels monòlits fins als microserveis.
Una mica d'història
Si intenteu preguntar als desenvolupadors: "Per què necessitem microserveis?", obtindreu diverses respostes. Sentiràs que els microserveis milloren l'escalabilitat, fan que el codi sigui més fàcil d'entendre, milloren la tolerància a errors i, de vegades, escoltaràs que et permeten "netejar el codi". Mirem la història per entendre el propòsit de l'aparició dels microserveis.
En resum, els microserveis en la nostra comprensió actual van sorgir de la següent manera: l'any 2011, James Lewis, analitzant el treball de diverses empreses, va cridar l'atenció sobre l'aparició d'un nou patró de "micro-aplicació", que optimitzava SOA en termes d'acceleració del desplegament de serveis. Una mica més tard, el 2012, en una cimera d'arquitectura, el patró va ser rebatejat com a microservei. Així, l'objectiu inicial d'introduir els microserveis era millorar el notori time to market.
Els microserveis van estar en una onada de bombo el 2015. Segons alguns estudis, no es va completar una sola conferència sense un informe sobre el tema dels microserveis. A més, algunes conferències estaven dedicades exclusivament als microserveis. Avui en dia, molts projectes comencen a utilitzar aquest estil arquitectònic, i si el projecte conté tones de codi heretat, probablement la migració a microserveis s'està realitzant activament.
Malgrat tot l'anterior, un nombre força reduït de desenvolupadors encara poden definir el concepte de "microservei". Però d'això en parlarem una mica més endavant...
Monòlit
L'estil arquitectònic que contrasta amb els microserveis és el monòlit (o tot en un). Probablement no tingui sentit dir què és un monòlit, així que de seguida enumeraré els inconvenients d'aquest estil arquitectònic, que va iniciar el desenvolupament posterior dels estils arquitectònics: mida, connectivitat, desplegament, escalabilitat, fiabilitat i rigidesa. A continuació proposo fer una ullada a cadascuna de les mancances per separat.
mida
El monòlit és molt gran. I normalment es comunica amb una base de dades molt gran. L'aplicació es fa massa gran perquè un desenvolupador ho entengui. Només els que han passat molt de temps treballant en aquest codi poden treballar bé amb el monòlit, mentre que els principiants passaran molt de temps intentant esbrinar el monòlit i no hi ha cap garantia que ho esbringuin. En general, quan es treballa amb un monòlit, sempre hi ha algun sènior "condicional" que coneix més o menys bé el monòlit i que supera les mans d'altres desenvolupadors nous en un any i mig. Naturalment, un sènior tan condicional és un únic punt de fracàs, i la seva sortida pot provocar la mort del monòlit.
Connexió
El monòlit és una “gran bola de fang”, canvis en els quals poden tenir conseqüències imprevisibles. Si feu canvis en un lloc, podeu danyar el monòlit en un altre (el mateix "te vas rascar l'orella, *@ va caure"). Això es deu al fet que els components del monòlit tenen relacions molt complexes i, sobretot, no òbvies.
Desplegament
El desplegament d'un monòlit, a causa de les complexes relacions entre els seus components, és un procés llarg amb un ritual propi. Aquest ritual normalment no està completament estandarditzat i es transmet "oralment".
Escalabilitat
Els mòduls monòlits poden tenir necessitats de recursos conflictives, que requereixen un compromís en termes de maquinari. Imagineu que teniu un monòlit format pels serveis A i B. El servei A exigeix la mida del disc dur i el servei B exigeix la memòria RAM. En aquest cas, o bé la màquina on s'instal·la el monòlit ha de suportar els requisits d'ambdós serveis, o bé hauràs de desactivar manualment un dels serveis de manera artificial.
Un altre exemple (més clàssic): el servei A és molt més popular que el servei B, de manera que voleu que hi hagi 100 serveis A i 10 serveis B. De nou, dues opcions: o despleguem 100 monòlits complets, o en alguns els serveis B s'hauran de desactivar manualment.
Fiabilitat
Com que tots els serveis es troben junts, si el monòlit cau, tots els serveis cauen alhora. De fet, pot ser que això no sigui tan dolent, almenys no hi haurà fallades parcials en un sistema distribuït, però d'altra banda, a causa d'un error en la funcionalitat que utilitza el 0.001% dels usuaris, podeu perdre tots els usuaris. del vostre sistema.
Inèrcia
A causa de la mida del monòlit, és difícil canviar a noves tecnologies. Com a resultat, retenir el mateix sènior és una tasca independent. La pila tecnològica escollida a l'inici d'un projecte pot esdevenir un bloc que dificulta el desenvolupament del producte.
Conclusió
La propera vegada parlarem de com la gent ha intentat resoldre aquests problemes passant als components i SOA.
Llegeix més:
Font: www.habr.com