MicroserviciosRabbitMQ

Por:Fran AguilarMariano G. Egui

Monolitos

Un sistema monolítico es el que se organiza en su totalidad de forma horizontal, allí la información tiene que atravesar el sistema de la misma forma horizontal para llegar a su destino, desde la base de datos, pasando por una o varias partes de todo el sistema, hasta llegar al usuario.

● La lógica para manejar una petición la gestiona un solo proceso● Se pueden correr los tests de la aplicación en la máquina de un desarrollador● Puedes escalar horizontalmente levantando más instancias detrás de un load-

balancer.● Escalar la aplicación requiere el escalado de la aplicación completa.

Microservicios

“El término arquitectura de microservicios ha surgido en los últimos años para describir una forma particular de diseñar aplicaciones de software como conjuntos de servicios con independencia de despliegue. Si bien no existe una definición precisa de este estilo arquitectónico, hay ciertas características comunes alrededor de organización en torno a la capacidad del negocio, el despliegue automatizado, la inteligencia en los endpoints y el control descentralizado de idiomas y datos.”

Martin Fowler

Escalando monolitos vs microservicios

Características:

● Composición vía servicios● Organización en torno al negocio● Productos, no proyectos● Endpoints inteligentes, pipes tontos● Gobierno descentralizado● Gestión de datos descentralizada● Automatización de la infraestructura● Diseñado contra errores● Diseño evolutivo

Composición:

● Componente: unidad de software que puede actualizarse y/o reemplazarse.

● Librería: componente enlazado a un programa que es invocado a través de funciones en memoria.

● Servicio: componente out-of-process que se comunica a través de un mecanismo como un web service o un RPC.

Ventajas

● Pueden desplegarse independientemente de otros.● Ofrecen una interfaz más explícita (facade).

Inconvenientes

● Las llamadas remotas son más caras, y por lo tanto las API remotas necesitan ser de grano más grueso, lo que puede convertirlas en más difíciles de usar.

● Es más complicado mover las responsabilidades entre los componentes.

Organización en torno al negocio

"Cualquier organización que diseña un sistema (definido en términos generales) producirá un diseño cuya estructura es una copia de la estructura de comunicación de la organización."

Melvyn Conway, 1967

Los equipos de desarrollo deberían ser responsables de construir y poner en funcionamiento cada producto, y cada producto ser dividido en un número de microservicios que se comuniquen a través de un bus de mensajes.

Los arquitectos de microservicios favorecen la idea de que un equipo debe ser plenamente responsable de un producto software durante toda su vida útil.

"You build, you run it"

La mentalidad de producto se enlaza con el negocio. En lugar de pensar el software como un conjunto de funcionalidades terminadas, hay una relación continua donde la pregunta es cómo el software ayuda a sus usuarios a mejorar el negocio.

Productos, no proyectos

Endpoints inteligentes, pipes tontos

Las aplicaciones construidas a partir microservicios pretenden estar tan desacopladas y cohesionadas como sea posible, que poseen su propia lógica de dominio y actúan más como filtros, de forma que se reciba una petición, se aplique la lógica correspondiente y se produzca una respuesta.

Se prefieren protocolos REST simples en lugar de otros más complejos

● Request - response con APIs de recursos● Bus de mensajes: RabbitMQ, ZeroMQ, etc.

Gobierno descentralizado

Gobierno centralizado

● Tendencia a estandarizar la tecnología● Puede no usarse la herramienta más correcta para cada trabajo

Gobierno descentralizado

● Al dividir los componentes del monolito en servicios tenemos la posibilidad de elegir la herramienta más adecuada para cada una de ellas.

OJO: sólo porque puedas hacer algo, no significa que debas hacerlo.

Gestión de datos descentralizadaEl modelo conceptual del mundo será diferente entre los sistemas.La vista de un cliente por parte del sistema de ventas difiere de la de soporte.

Este problema es común entre aplicaciones, pero también puede ocurrir dentro de las aplicaciones, en particular cuando la aplicación se divide en componentes separados.

Una manera útil de pensar en esto es la noción de bounded context de DDD.DDD divide un dominio complejo en múltiples contextos limitados, y trazando las relaciones entre ellos. Este proceso es útil para arquitecturas monolíticas y microservicios, pero hay una correlación natural entre los límites del servicio y de contexto.

Las aplicaciones monolíticas prefieren una base de datos lógica para persistir datos.Las empresas a menudo prefieren una sola base de datos a través de una gama de aplicaciones.

Gestión de datos descentralizada

La arquitectura de microservicios prefieren dejar que cada servicio de gestionar su propia base de datos:

● Persistencia políglota● Consistencia eventual (reglas de negocio, UI)

Las transacciones distribuidas son difíciles de implementar.Las arquitecturas de microservicios hacen hincapié en la coordinación no-transaccional entre los servicios.

Automatización de la infraestructuraQueremos tener tanta confianza como sea posible en que el software está funcionando, por lo que se corren tantos tests automatizados como sea posible.

Para promocionar el código en la cadena, deberemos automatizar el despliegue del código a cada nuevo entorno.

Automatización de la infraestructura

Diseñado contra errores

Las aplicaciones deben ser diseñadas para tolerar un error en un servicio.

Cualquier llamada de servicio podría fallar debido a la falta de disponibilidad del proveedor. El cliente debe responder a esto tan elegantemente como sea posible.

Es importante ser capaz de detectar los fallos de forma rápida y, si es posible, restaurar automáticamente el servicio.

Énfasis en la supervisión en tiempo real de la aplicación, comprobando:

● Los elementos arquitectónicos (peticiones por segundo)● Métricas de negocio relevantes (ventas por minuto)

El monitoreo semántico puede ofrecer un sistema de alerta temprana de que algo va mal, permitiendo a los desarrolladores realizar su seguimiento.

Diseño evolutivo

Siempre que pensemos cómo dividir un software en componentes nos enfrentamos a la decisión de cómo dividir las piezas.

¿Cuáles son los principios en los que decidimos el tramo hasta nuestra aplicación?

Las propiedades claves de un componente son el reemplazo independiente y actualización, lo que implica que buscamos puntos en los que podemos imaginar la reescritura de un componente sin afectar a sus colaboradores.

De hecho, muchos arquitectos llevan este concepto más lejos, esperando que los servicios sean desechados en lugar de evolucionarlos con el tiempo.

Conclusion...

“Muchos equipos de desarrollo han encontrado que los microservicios de estilo arquitectónico sea un enfoque superior a una arquitectura monolítica. Sin embargo, otros equipos han encontrado que son una carga para la productividad que agota. Al igual que cualquier estilo arquitectónico, los microservicios presentan costes y beneficios. Para hacer una elección sensata, hay que entender bien el concepto y aplicarlo en su contexto específico.”

Martin Fowler

http://martinfowler.com/articles/microservice-trade-offs.html

Beneficios

❏ Los microservicios refuerzan la estructura modular, lo que es particularmente importante para los equipos más grandes.

❏ Implementaciones independientes: un servicio sencillo es más fácil de implementar y, puesto que son autónomos, son menos propensos a causar fallos en el sistema cuando van mal.

❏ Diversidad tecnológica: con microservicios se pueden mezclar varios lenguajes, los marcos de desarrollo y tecnologías de almacenamiento de datos.

Costos

❖ Distribución: los sistemas distribuidos son más difíciles de programar, ya que las llamadas remotas son lentas y pueden fallar.

❖ Consistencia eventual: el mantenimiento de una fuerte consistencia es muy difícil en un sistema distribuido, lo que significa que cada servicio debe gestionar la consistencia del sistema.

❖ Complejidad operacional: se necesita un equipo de operaciones maduro para manejar una gran cantidad de servicios, que se despliegan regularmente.

Nuestra experiencia en su implementación

El proyecto implementó el concepto de microservicios originalmente desarrollando 3 servicios con sus respectivas SDK y un gateway.

En un principio API Gateway resolvería el negocio y derivaría los request a los respectivos servicios, además en sus primeras definiciones se encontraban pocas conexiones entre sí.

Luego al integrar ms-social notamos que la connexion entre servicios aumentó considerablemente.

Tuvimos que refactorizar el endpoint de usuarios para mejor sus tiempos de respuesta y no encarecer los tiempos de ms-social ya que este hacia múltiples consultas a ms-user, para esto incluimos Elasticsearch services de amazon.

La llegada de social

Problemas de rendimientoLa inclusión de espacios de ms-platform en ms-social y sus ACL (usuarios que pueden o no ver/escribir en un espacio) y la forma de informar estos ACL a la UI género un excesivo y recursivo tráfico interno, entre ms-social, ms-user y ms-platform, debido a que ms-platform contenía los espacios de una plataforma, las relaciones con usuarios/grupo. Entonces ms-social consulta ms-platform las relaciones y los ACL a ms-user que tenia que consultar a ms-platform para poder responder.

Mejorando tiempos

Con concurrencia AWS comenzó a responder de forma aleatoria en los tiempos de respuestas, afectando directamente en el funcionamiento de los servicios. Escritura/Lectura en DynamoDb, inconsistencias e indexado de Elasticsearch, tiempos de ejecuciones en Lambda.

Conclusion:Optamos por llevar a Lambda a nuestros servidores.

!Chau lambda!

Definiciones de productos más complejas

Al alterar las definiciones de producto en el requerimiento de los muros, DynamoDB dejó de brindar el soporte que necesitábamos para satisfacer estas definiciones. Y el tiempo de respuesta desde una Notificación desde ms-social a lambda escribiendo en DynamoDB y volviendo al Muro presentaba un retardo importante.

Conclusion:Optamos por deprecar esta solución y utilizar Mysql para satisfacer los requerimientos simples como: “ver en el muro mi post recien creado”.

Si suponemos que cada request tarda 100ms impactaría de esta forma

!Chau DynamoDB!

¿Y el problema de ACL ?

Lamentablemente AWS limita el servicio de Elasticsearch quitando las posibilidades de explotar esta herramienta al máximo y aumentar nuestro rendimiento.Las tareas lambda procesaban información sensible para los ACL y generaba severos retardos.El servicio de SNS comenzó a notificar eventos lanzados por ms-user mezclados provocando inconsistencias en el indexado de elasticsearch.

Conclusion:Optamos por tener Elasticsearch en nuestros servidores.Migrar de SNS a nuestro propio Message Broker “RabbitMQ”.Migrar de tareas Lambda a workers en el correspondiente microservicio.

!Hola RabbitMQ!

!Chau AWS Elastic!

A nivel negocio RabbitMQ nos sirvió para desacoplar nuestros servicios de AWS, flexibilizar el uso de mensajería y utilizarlo como middleware entre los servicios.

Permitirnos escalar a los workers, mantener sincronizados en orden de notificaciones para tener consistencia en los datos de elasticsearch y optimizar los tiempos.

RabbitMQ

¿Que es RabbitMQ?

“Dentro de la informática, RabbitMQ es un software de negociación de mensajes de código abierto, y entra dentro de la categoría de middleware de mensajería. Implementa

el estándar Advanced Message Queuing Protocol (AMQP).”Wikipedia.

Es un sistema de mensajería que permite a las aplicaciones conectarse y escalar. Estas pueden conectarse entre sí, como con componentes de una aplicación más grande, o a dispositivos de usuarios transmitiendo datos. La mensajería es asincrónica, desacoplada a las aplicaciones mediante la separación de envío y recepción de datos.

Sus principales característicasConfiable: ofrece características que le permiten operar fuera de rendimiento con la fiabilidad, incluyendo la persistencia, acuses de recibo de entrega, confirma editor, y alta disponibilidad.

Enrutamiento Flexible: los mensajes se enrutan a través de intercambios antes de llegar a las colas. RabbitMQ cuenta con varios tipos de cambio integradas para la lógica de enrutamiento típico. Para el enrutamiento más complejo puede enlazar los intercambios entre sí o incluso escribir su propio tipo de cambio como un plugin.

Clustering: Varios servidores RabbitMQ en una red local pueden ser agrupados juntos, formando un único agente lógico.

Mensajería estándar, alta disponibilidad, multiprotocolo, muchos clientes, la interfaz de usuario para su gestión, seguimiento, plugins ...

Hello World

La cosa más simple que hace algo

Colas de trabajo

Distribución de tareas entre los workers

Publicar /Subscribe

Envío de mensajes a muchos consumidores a la vez

Enrutamiento

Recepción de mensajes de forma selectiva

Topics

Recepción de mensajes basado en un patrón

¿Preguntas?