Arquitectura web 2.0 con microservizos

Tradicionalmente o deseño de software realizouse utilizando unha arquitectura monolítica: todos os aspectos funcionais quedan acoplados e suxeitos nun mesmo programa. Este modelo de desenvolvemento é moi pouco escalable. Ademais canto máis grande é a aplicación, máis difícil son de solucionar os problemas que se presentan e máis complicado é engadir novas funcionalidades rapidamente.

En cambio, a arquitectura de microservizos é un modelo de desenvolvemento de software que consiste en construír unha aplicación como un conxunto de pequenos servizos. Esta nace na necesidade de realizar cambios e implantalos nas aplicacións de rápido e doado. Isto ademais axuda a evitar a sobrecarga e caída da aplicación en produción.

O auxe desta arquitectura débese ademais a aparición de contedores como Docker e orquestadores como Kubernetes que permiten o despregamento en produción de xeito sinxelo e automatizado.

Unha arquitectura de microservizos terá máis sentido canta máis diversa e grande sexa a audiencia da aplicación, e canto maior sexa a organización, equipo de desenvolvemento e servizos ofrecidos. A maioría das grandes compañías tecnolóxicas actuais utilizan esta arquitectura para as súas aplicacións: Google, Netflix, Amazon, etc.

Características

Algunha das características desta arquitectura son as seguintes:

• Organizada en función das funcionalidades da lóxica de negocio. O sistema divídese en pequenos servizos (aplicacións) que se ocupan dunha parte da lóxica de negocio.
• Múltiples tecnoloxías. Permite utilizar tecnoloxías diferentes para cada microservizo que se adaptan mellor a cada funcionalidade.
• Xestión de datos descentralizada. Cada microservizo pode xestionar a súa propia base de datos, sexan estas diferentes estancias da mesma tecnoloxía de base de datos ou sistemas de base de datos completamente diferentes. A utilización de varias tecnoloxías diferentes para almacenamento non é obrigatorio, só é unha opción que se proporciona.
• Automatización da infraestrutura: a maioría de produtos desenvolvidos con este enfoque utilizan CI/CD (integración e entrega continua). Para isto é necesario que:
  • Automatizar todo o proceso. Dende as probas de código ao despregamento en produción.
  • Control de versións e xestión da configuración. Todo o software debe de estar versionado e débese poder xestionar as diferentes configuracións para conseguir a entrega continua.
  • Arquitectura adecuada. A arquitectura debe permitir realizar cambios nun microservizo sen que afecten ao resto do sistema.
• Despregue de servizos de xeito independente. Cando se divide o sistema en servizos, hai que ter en conta que cada un ten que poder ser substituído ou actualizado de xeito independente. Polo tanto permite realizar unha evolución de xeito sinxelo.
• Compartir servizos: permite compartir procesos similares entre varias aplicacións dun mesmo sistema.
• Stateless aplicattion: polo xeral deben ser aplicacións sen estado

Funcionamento

O funcionamento é similar a arquitectura desacoplada. O único que cambia, e que o frontend en lugar de realizar chamadas HTTP a unha única aplicación backend, faraa a múltiples aplicacións backend.

Comunicación entre microservizos

Tamén é bastante común que os propios microservizos se comuniquen entre si para realizar as tarefas solicitadas polo usuario en conxunto.

Polo tanto, un dos aspectos máis importantes no desenvolvemento dunha aplicación baseada en microservizos é a comunicación entre eles. Este é un proceso que pode resultar bastante complexo.

Por exemplo, nunha arquitectura monolítica, os diferentes compoñentes comunícanse mediante chamadas a nivel de linguaxe. O que é bastante doado.

En cambio nunha arquitectura de microservizos, o sistema execútase en diferentes procesos e incluso en diferentes servidores. Polo tanto estes comunícanse a través de protocolos de comunicación como HTTP, AMQP ou un protocolo binario TCP. Existen diferentes solucións e é importante elixir a máis adecuada debido a que algúns procesos de comunicación resultan ineficaces. Ademais, para poder establecer estas comunicacións, é necesario que exista unha interface de programación de aplicacións (API).

Podemos clasificar os sistemas de comunicación existentes pola clase de protocolo:

• Síncrono: O emisor unicamente pode continuar a súa tarefa no momento que recibe unha resposta do receptor. O protocolo HTTP/HTTPS é un exemplo deste tipo.

  

• Asíncrono: O emisor unicamente pode continuar a súa tarefa sen necesidade de recibir resposta do receptor. Un exemplo é o protocolo AMQP (Advanced Message Queuing Protocol). Simplemente se envía unha mensaxe a unha cola que será lida no seu momento polo receptor. O funcionamento deste protocolo é o seguinte:

  1. Un broker crea varias colas de mensaxes.
  2. Cada microservizo subscríbese as colas das que desexa recibir mensaxes.
  3. Un microservicio publica unha mensaxe nun determinada cola.
  4. O broker envía cada mensaxe da cola aos microservicios subscritos.

  

  Un exemplo de software que implemente unha lista de colas é RabbittMQ:

  Este sistema é moi útil cando se necesitan facer tarefas que necesitan un procesamento moi longo. Por exemplo no procesamento de vídeo. Vexamos un exemplo de como funcionaría:

  1. O usuario fai unha acción (ex. sobe un vídeo).

  2. Un dos microservizos do backend acepta a solicitude e envía unha mensaxe a unha cola (ex. procesar_video) a través do broker. Este microservizo xa realiza a resposta HTTP ao cliente.

  3. Outro microservizo consume esa mensaxe en segundo plano e fai o traballo pesado (como procesar o vídeo).

  4. Cando remata, pode enviar outra mensaxe, ou actualizar unha base de datos. Deste xeito o cliente poderá saber se finalizou o súa petición.

Unha vez elixido o tipo de comunicación entre microservizos, existe unha ampla variedade de opcións e protocolos, o que se coñece como estilos de comunicación entre procesos. Xeralmente utilízanse varios estilos de comunicación nun mesmo sistema, aínda que o protocolo asíncrono HTTP/HTTPS é dos máis utilizados.

API Gateway

Nesta arquitectura, as aplicacións de frontend necesitan xeralmente consumir funcionalidades de máis dun microservizo. Se ese consumo se realiza directamente, o cliente debe controlar varias chamadas aos microservizos. Se a aplicación ten moitos microservizos, controlar as peticións por parte das aplicación cliente pode ser complicado. Ademais a evolución dos microservizos nun futo pode provocar un alto impacto nas aplicacións de clientes.

Polo tanto, dispor dun nivel intermedio, API Gateway pode ser práctico nesta arquitectura.

Posible exemplo de arquitectura de microservizos

Vamos realizar unha lista de servizos dunha arquitectura de microservizos inspirada nunha aplicación de vídeo baixo demanda.

Microservizo	Función principal
Servizo de usuario	Rexistro, login, xestión de perfil, contrasinais, idioma, dispositivos autorizados
Servizo de recomendacións	Analiza o historial e gustos do usuario para suxerir contido personalizado
Servizo de catálogo	Xestiona metadatos das series/películas (título, sinopse, xénero, dispoñibilidade)
Servizo de reprodución	Controla as sesións de vídeo, calidade de streaming, subtítulos, CDN, etc.
Servizo de facturación	Xestiona pagos, subscricións, renovacións, tarxetas bancarias
Servizo de busca	Permite buscar contido con filtros e suxestións mentres escribes
Servizo de notificacións	Envía correos ou mensaxes push ao usuario
Servizo de análise de uso	Rexistra comportamento: que se ve, cando, canto tempo, para estatísticas e IA

Todos estes microservizos comunícanse entre si por API REST ou mensaxería asincrónica. Por exemplo:

• O servizo de recomendacións consulta o historial no servizo de reprodución.
• O servizo de busca consulta o servizo de catálogo.
• O frontend (React, por exemplo) fala con varios servizos á vez: usuario, catálogo e recomendacións.