Hola, Habr. Avui segueixo una sèrie de publicacions que he escrit expressament per a l'inici d'una nova línia del curs. .
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.
В vam tractar amb el monòlit i vam arribar a la conclusió que el monòlit té una sèrie de problemes: mida, connectivitat, desplegament, escalabilitat, fiabilitat i rigidesa.
En aquesta ocasió us proposo parlar de les possibilitats d'organitzar un sistema com un conjunt de mòduls/biblioteca (arquitectura orientada a components) o serveis (arquitectura orientada a serveis).
Arquitectura orientada a components
L'arquitectura orientada a components implica executar un sistema com un conjunt de components que es poden utilitzar tant en projectes actuals com futurs. A l'hora de descompondre un sistema en components, es tenen en compte: la seva reutilització, la seva substituibilitat, independència del context, extensibilitat, encapsulació i independència.
Amb un ús adequat dels components, es resol el problema de la "gran bola de brutícia" (gran mida + acoblament alt) i els components en si poden ser tant unitats de muntatge (mòduls, biblioteques) com unitats de desplegament (serveis). Les unitats de desplegament no sempre s'assignen al procés en execució: per exemple, una aplicació web i una base de dades es despleguen conjuntament.
Molt sovint, els monòlits es desenvolupen com un conjunt de mòduls. Aquest enfocament condueix a un desenvolupament independent, però els problemes d'escala i desplegament independents, la tolerància a errors i la independència de la pila tecnològica general es mantenen. És per això que el mòdul és un component parcialment independent.
El problema més gran d'aquest monòlit és que la divisió en mòduls és purament lògica i els desenvolupadors poden violar fàcilment. Pot aparèixer un mòdul central, que a poc a poc es converteix en un abocador d'escombraries, pot créixer el gràfic de dependències entre mòduls, etc. Per evitar aquests problemes, el desenvolupament l'hauria de dur a terme un equip molt madur o sota la direcció d'un "arquitecte" que es dedica a la revisió del codi a temps complet i que supera les mans dels desenvolupadors que violen l'estructura lògica.
El monòlit "ideal" és un conjunt de mòduls separats lògicament, cadascun dels quals mira a la seva pròpia base de dades.
Arquitectura orientada a serveis
Si se suposa que el sistema s'organitza en forma d'un conjunt de serveis, estem parlant d'una arquitectura orientada a serveis. Els seus principis són la interoperabilitat d'aplicacions centrada en l'usuari, la reutilització de serveis empresarials, la independència de la pila de tecnologia i l'autonomia (evolució, escalabilitat i desplegament independents).
L'arquitectura orientada a serveis (SOA = service oriented architecture) resol tots els problemes identificats d'un monòlit: només un servei es veu afectat quan es produeix un canvi i una API ben definida admet una bona encapsulació dels components.
Però no tot és tan fluid: SOA crea nous problemes. Les trucades remotes són més cares que les locals i la redistribució de responsabilitats entre components s'ha tornat molt més car.
Per cert, la possibilitat de desplegament independent és una característica molt important del servei. Si els serveis s'han de desplegar conjuntament o, a més, en una seqüència determinada, aleshores el sistema no es pot considerar orientat al servei. En aquest cas, parlen d'un monòlit distribuït (considerat un antipatró no només des del punt de vista de SOA, sinó també des del punt de vista de l'arquitectura de microserveis).
L'arquitectura orientada a serveis té un bon suport per la comunitat arquitectònica i els venedors. Això implica la presència de molts cursos i certificacions, patrons ben desenvolupats. Aquest últim inclou, per exemple, el conegut bus de servei empresarial (ESB = bus de servei empresarial). Al mateix temps, ESB és un equipatge dels venedors; no necessàriament s'ha d'utilitzar a SOA.
La popularitat de l'arquitectura orientada a serveis va assolir el seu màxim al voltant de l'any 2008, després del qual va començar a disminuir, cosa que es va fer significativament més dramàtica després de l'arribada dels microserveis (~2015).
Conclusió
Després d'haver comentat les possibilitats d'organitzar sistemes d'informació en forma de serveis i mòduls, proposo passar finalment als principis de l'arquitectura de microserveis i prestar especial atenció a la diferència entre l'arquitectura de microservei i l'arquitectura orientada a serveis a la part següent.
Font: www.habr.com