Arquitectura basada en microservicios Parte 1

  • Hace poco publiqué un post (Microservicios: Buenas prácticas y stacks tecnológicos) en el explicaba el nuevo estilo arquitectural basado en microservicios y también daba una serie de buenas prácticas a la hora de trabajar con él.
  • Ahora me he propuesto realizar una serie de post en los que se describa un modelo arquitectónico que nos permita adoptar y poner en práctica este estilo arquitectural en una organización.
  • En este primer post vamos a definir el modelo arquitectónico de referencia, después en un segundo post definiremos en modelo de implementación y en un tercero el modelo de despliegue.
  • Empezamos pues con la primera parte de esta serie…

1 MODELO ARQUITECTÓNICO

  • Asumimos que queremos usar microservicios como estilo arquitectural para descomponer las aplicaciones monolíticas que se tienen en la actualidad y así mejorar sus capacidades de despliegue y escalabilidad, con lo que conseguimos ser más eficientes sobre todo en tiempo ante a cambios de las mismas (evolutivos).
  • Cuando el número de microservicios se incrementa en el sistema, aparecen nuevos retos que no eran visibles cuando solamente se desplegaban unas pocas aplicaciones monolíticas en nuestro sistema.
  • Vamos a ver cómo afrontar estos nuevos retos y definir una arquitectura para nuestro sistema que siga este estilo arquitectural y que se capaz de desplegar un gran número de microservicios.

1.1 Pre – requisitos

  • ¿Qué requerimos para ejecutar un gran número de microservicios en nuestro sistema o paisaje de servicios que sustituirá al sistema basado en aplicaciones monolíticas?
  • Lo que queremos conseguir básicamente lo podemos ver representado en la siguiente figura:

  • Es muy importante darse cuenta de que antes de poder conseguir ejecutar un gran número de microservicios en nuestro nuevo sistema es necesario cumplir con varios requisitos.
  • Los requisitos a cumplir son los siguientes:
    • Una arquitectura objetivo
    • Una cadena de herramientas para entrega continua
    • Una organización apropiada
  • Vamos a detallar brevemente cada uno de estos requisitos.

1.1.1 Arquitectura Objetivo

  • Primero necesitamos una idea arquitectural de cómo podemos particionar o clasificar todos nuestros microservicios.
  • Podemos por ejemplo repartir los microservicios verticalmente en capas como:

Servicios Core (o de negocio)

Manejan persistencia de datos de negocio y aplican reglas de negocio y lógica de negocio.

Servicios Compuestos

Pueden orquestar un número de core services para llevar a cabo una tarea o agregar información de un conjunto de core services.

Servicios API

Exponen funcionalidad permitida al exterior, por ejemplo a consumidores o terceras partes para crear aplicaciones que usan la funcionalidad del sistema.

  • Pero además podemos dividirlos horizontalmente en base al dominio funcional al que pertenecen.
  • De esta forma puede resultar una arquitectura parecida a la siguiente:

  • Esto es un ejemplo de arquitectura objetivo y podría ser diferente.
  • La clave está en que necesitamos tener una arquitectura objetivo establecida antes de ponerse a crear y desplegar microservicios capaces de escalar.
  • De otra forma, se podría acabar en un sistema parecido a un enjambre de servicios llamándose unos a otros con incluso peores características que las aplicaciones monolíticas de las que se parte y se quiere sustituir.

1.1.2 Entrega continua

  • Necesitamos una cadena de herramientas de entrega continua que permitan desplegar nuevos microservicios con una eficiencia y calidad adecuadas y de forma repetible y controlada, por ejemplo:

1.1.3 Organización

  • Tenemos que considerar acometer en nuestra organización los cambios organizativos necesarios para evitar que en nuestra organización aplique la Ley de Conway.
  • Dicha ley dice lo siguiente:

“Una organización que diseña un sistema (en líneas generales) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización”

  • Los equipos que desarrollarán, desplegarán y mantendrán un microservicio han de ser multidisciplinares, es decir, contar con un integrante al menos de cada departamento.

1.2 Escalado

  • ¿Qué ocurre en un sistema cuando empezamos a dividir sus aplicaciones monolíticas y las reemplazamos por un gran número de microservios?

1.2.1 Gran número de unidades de despliegue

  • Muchos microservicios “pequeños” en lugar de unas pocas y grandes aplicaciones monolíticas resultarán en un incremento significativo del número de unidades de despliegue que hay que manejar y monitorizar.

1.2.2 Los microservicios cosumen otros microservicios

  • Esto lleva a un paisaje en el que la mayoría de los microservicios están interconectados entre ellos.

1.2.3 Algunos de los microservicios exponen un api externo

  • Estos microservicios son responsables de proteger o apantallar a otros que no pueden ser accedidos externamente.

1.2.4 Sistema más dinámico

  • Nuevos microservicios son desplegados, los antiguos son eliminados y sustituidos por otros, se levantan nuevas instancias de los microservicios cuando se necesita incrementar la carga con el tiempo.
  • Esto significa que los servicios vendrán y se irán con mucha más frecuencia que antes.

1.2.5 MTBF se decrementa

  • Con gran cantidad de pequeñas unidades de despliegue conviviendo en el sistema es muy posible que el número de fallos se incremente con respecto a un panorama en el que sólo hay unas pocas aplicaciones monolíticas desplegadas.
  • Al ser más pequeño el tiempo medio entre fallo, los fallos ocurrirán más frecuentemente

1.3 Cuestiones

  • Ante esta situación, nuestra arquitectura tiene que ser capaz de resolver las siguientes cuestiones

1.3.1 ¿Cómo se configuran correctamente todos nuestros microservicios?

  • Manejar la configuración no es problema para unas pocas de aplicaciones, por ejemplo cada aplicación maneja sus ficheros de configuración propios en disco o tablas en su base de datos.
  • Con múltiples instancias de un gran número de microservicios la cosa es un poco más difícil de manejar.
  • Implicaría manejar un montón de ficheros de configuración o tablas haciendo difícil su mantenimiento eficiente y con buena calidad.

1.3.2 ¿Qué microservicios son desplegados y donde?

  • Guardar que hosts y puertos de los servicios expuestos por un número pequeño de aplicaciones es simple, pero cuando tenemos un número grande de microservicios que son desplegados independientemente uno del otro, puede convertirse en una pesadilla de mantenimiento si se intenta hacer manualmente.

1.3.3 ¿Cómo se mantiene actualizada la información de enrutamiento?

  • Ser consumidor de servicios en un sistema dinámico puede convertirse también en un reto. Especialmente si las tablas de enrutamiento se tienen que actualizar manualmente.
  • No hay tiempo material para actualizar las rutas de forma manual en un paisaje que está en constante evolución con microservicios que levantan nuevas direcciones de hosts y puertos constantemente.
  • El tiempo de creación de nuevos microservicios y el riesgo de fallos aumenta si estas tareas se realizaran manualmente.

1.3.4 ¿Cómo prevenir cadenas de fallos?

  • Ya que los microservicios están interconectados unos con otros es necesario evitar que se produzcan fallos en cadena.
  • Por ejemplo, si un microservicio del cual dependen varios falla, los servicios dependientes fallarán también y de ahí en adelante.
  • Si no se maneja adecuadamente esta situación, se producirán fallos en cadena que acaban con todo el sistema volviéndolo muy frágil.

1.3.5 ¿Cómo verificar que todos los servicios están levantados y corriendo?

  • Trazar el estado de unas pocas aplicaciones es sencillo pero ¿cómo verificar que todos los microservicios están saludables y listos para recibir peticiones?

1.3.6 ¿Cómo monitorizar los mensajes que se mandan entre los servicios?

  • Si se produce un fallo, ¿somos capaces de detectarlo rápidamente?, ¿podemos saber cuál es la raíz del problema?

1.3.7 ¿Cómo asegurar que sólo los servicios API son expuestos externamente?

  • Por ejemplo, ¿Cómo evitamos que accesos no autorizados desde fuera a nuestros microservicios internos?

1.3.8 ¿Cómo controlar el acceso a nuestros servicios API?

  • Es muy importante securizar los microservicios que se van a exponer al exterior.

1.4 Componentes necesarios

  • Para dar solución a las cuestiones antes planteadas se requieren nuevas funcionalidades de manejo y operaciones que antes no eran necesarias o al menos no lo eran en la misma extensión, cuando sólo se operaba con unas pocas aplicaciones.
  • La solución a las cuestiones anteriores requiere incluir un conjunto de componentes en nuestro sistema, que pasamos a detallar.

1.4.1 Servidor de configuración central

  • En lugar de configuración local por unidad de despliegue (microservicio) necesitamos un manejo centralizado de la configuración.
  • También necesitamos un API de configuración que los microservicios puedan usar para buscar la información de configuración.

1.4.2 Servicio de descubrimiento de servicios

  • En lugar de llevar la cuenta manualmente de qué servicios están desplegamos actualmente y qué hosts y puertos necesitamos para descubrir la funcionalidad que ofrecen, necesitamos que los microservicios se auto registren al levantarse a través de un API.

1.4.3 Enrutamiento dinámico y balanceador de carga

  • Componentes de enrutamiento usan el API de descubrimiento para localizar donde el microservicio que se ha solicitado está desplegado y los componentes de balanceo de carga deciden a que instancia del microservicio dirigir o enrutar la petición en base a la carga de las mismas.

1.4.4 Circuit Breaker

1.4.5 Monitorización

  • Una vez que se tienen los Circuits breakers funcionando, podemos empezar a monitorizar su estado y recoger las estadísticas de ejecución para conseguir una foto del estado de salud de sistema y de uso.
  • Esta información debe ser mostrada en consolas con posibilidades de establecimiento de alarmas automáticas con umbrales configurables.

1.4.6 Análisis centralizado de log

  • Para ser capaces de trazar mensajes entre microservicios y detectar que ha pasado necesitamos una función de análisis centralizado de logs que sea capaz de recopilar logs de los microservicios y coleccionarlos.
  • La función de análisis almacena esta información de log en una base de datos central (con capacidades Big data) y también proporciona capacidades de búsqueda y consolas de consulta.

1.4.7 Servidor Perimetral

  • Para exponer los servicios API externamente y prevenir accesos no autorizados a los microservicios internos necesitamos un servidor perimetral por el que pase todo el tráfico.
  • Este servidor debe usar el enrutamiento dinámico y las capacidades de balanceo basadas en el componente de descubrimiento descrito anteriormente.
  • El servidor perimetral actúa como proxy inverso activo y dinámico y no necesita ser actualizado manualmente si cambia el paisaje de servicios interno.

1.4.8 APIs de protección basadas en estándar OAuth

  • Para proteger los servicios API expuestos es recomendable usar el estándar OAuth.
  • Esta solución implica el uso de:
    • Un nuevo componente que puede actuar como Servidor de Autorización OAuth
    • Los Microservicios API actúan como Servidor de recursos OAuth
    • Los consumidores externos de los microservicios API actúan como clientes OAuth
  • El servidor perimetral actúa como transmisor del token OAuth en el sentido de que:
    • Actuará como Servidor de Recursos OAuth
    • Dejará pasar los token OAuth que vienen de las peticiones externas a los microservicios API

1.5 Modelo arquitectónico de referencia

  • Los microservicios necesitan de una infraestructura formada por los componentes descritos antes y con los que interactúan a través de sus APIs.
  • Esto se puede visualizar en la siguiente figura:

Una respuesta to “Arquitectura basada en microservicios Parte 1”

  1. Arquitectura basada en microservicios Parte 2 | Un poco de Java Says:

    […] el post Arquitectura de Microservicios Parte 1 estuvimos viendo un modelo arquitectónico de referencia para una un sistema que siga el nuevo […]


Deja un comentario

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: