Ola, Habr. Hoxe sigo cunha serie de publicacións que escribín expresamente para o inicio dunha nova corrente do curso. .
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.
В tratamos o monolito e chegamos á conclusión de que o monolito ten unha serie de problemas: tamaño, conectividade, despregamento, escalabilidade, fiabilidade e rixidez.
Nesta ocasión propoño falar das posibilidades de organizar un sistema como un conxunto de módulos/bibliotecas (arquitectura orientada a compoñentes) ou servizos (arquitectura orientada a servizos).
Arquitectura orientada a compoñentes
A arquitectura orientada a compoñentes implica a execución dun sistema como un conxunto de compoñentes que se poden utilizar tanto en proxectos actuais como futuros. Ao descompoñer un sistema en compoñentes téñense en conta: a súa reutilización, a súa substituibilidade, a independencia do contexto, a extensibilidade, o encapsulamento e a independencia.
Co uso axeitado dos compoñentes, o problema da "gran bola de sucidade" (grande tamaño + alto acoplamento) resólvese e os propios compoñentes poden ser tanto unidades de montaxe (módulos, bibliotecas) como unidades de despregamento (servizos). As unidades de implantación non sempre se asignan ao proceso en execución: por exemplo, unha aplicación web e unha base de datos despréganse xuntas.
Na maioría das veces, os monólitos desenvólvense como un conxunto de módulos. Este enfoque leva a un desenvolvemento independente, pero os problemas de escalado e despregamento independentes, tolerancia a fallos e independencia da pila tecnolóxica global permanecen. Por iso o módulo é un compoñente parcialmente independente.
O maior problema con tal monólito é que a división en módulos é puramente lóxica e pode ser violada facilmente polos desenvolvedores. Pode aparecer un módulo central, que pouco a pouco se converte nun vertedoiro, pode medrar a gráfica de dependencias entre módulos, etc. Para evitar tales problemas, o desenvolvemento debe ser realizado por un equipo moi maduro ou baixo a orientación dun "arquitecto" que se dedica á revisión de código a tempo completo e bate as mans dos desenvolvedores que violan a estrutura lóxica.
O monólito "ideal" é un conxunto de módulos loxicamente separados, cada un dos cales busca a súa propia base de datos.
Arquitectura orientada a servizos
Se se supón que o sistema está organizado en forma de conxunto de servizos, entón estamos a falar dunha arquitectura orientada a servizos. Os seus principios son a interoperabilidade das aplicacións centradas no usuario, a reutilización dos servizos empresariais, a independencia da pila tecnolóxica e a autonomía (evolución, escalabilidade e despregamento independentes).
A arquitectura orientada a servizos (SOA = service oriented architecture) resolve todos os problemas identificados dun monólito: cando se produce un cambio, só se ve afectado un servizo e unha API ben definida admite unha boa encapsulación de compoñentes.
Pero non todo é tan suave: SOA crea novos problemas. As chamadas remotas son máis caras que as locais e a redistribución de responsabilidades entre compoñentes encareceuse moito.
Por certo, a posibilidade de implantación independente é unha característica moi importante do servizo. Se os servizos deben implantarse xuntos ou, ademais, nunha determinada secuencia, entón o sistema non pode considerarse orientado a servizos. Neste caso, falan dun monólito distribuído (considerado un antipatrón non só desde o punto de vista de SOA, senón tamén desde o punto de vista da arquitectura de microservizos).
A arquitectura orientada a servizos está ben apoiada pola comunidade arquitectónica e os provedores. Isto implica a presenza de moitos cursos e certificacións, patróns ben desenvolvidos. Este último inclúe, por exemplo, o coñecido bus de servizo empresarial (ESB = bus de servizo empresarial). Ao mesmo tempo, ESB é unha equipaxe dos provedores; non necesariamente se ten que usar en SOA.
A popularidade da arquitectura orientada a servizos alcanzou o seu máximo ao redor de 2008, despois de que comezou a diminuír, o que se fixo significativamente máis dramático tras a aparición dos microservizos (~2015).
Conclusión
Despois de discutir as posibilidades de organizar os sistemas de información en forma de servizos e módulos, propoño pasar finalmente aos principios da arquitectura de microservizos e prestar especial atención á diferenza entre a arquitectura de microservizos e a arquitectura orientada a servizos na seguinte parte.
Fonte: www.habr.com