Arquitectura de servicios distribuidos, trade-off, implementacion, experiencias y utilizacion de RabbitMQ como Message Broker entre servicios, beneficios de RabbitMQ. Experiencias con AWS Amazon Web Services.

1. Microservicios
RabbitMQ
Por:
Fran Aguilar
Mariano G. Egui

2. 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.

3. 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

4. Escalando monolitos vs microservicios

5. 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

6. 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.

7. 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.

8. 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.

9. 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

10. 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.

11. 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.

12. Gestión de datos descentralizada
El 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.

13. 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.

14. 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.

15. Automatización de la infraestructura
Queremos 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.

16. Automatización de la infraestructura

17. 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.

18. É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.

19. 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.

20. 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

21. 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.

22. 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í.

24. 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

27. Problemas de rendimiento
La 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.

28. 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.

29. !Chau lambda!

30. 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”.

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

32. !Chau DynamoDB!

33. ¿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.

34. !Hola RabbitMQ!

35. !Chau AWS Elastic!

36. 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.

37. RabbitMQ

38. ¿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.

39. Sus principales características
Confiable: 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 ...

40. Hello World
La cosa más simple que hace algo

41. Colas de trabajo
Distribución de tareas entre los workers

42. Publicar /Subscribe
Envío de mensajes a muchos consumidores a la vez

43. Enrutamiento
Recepción de mensajes de forma selectiva

44. Topics
Recepción de mensajes basado en un patrón

45. ¿Preguntas?