SOA multiplataforma con rabbitmq y websockets

2,157 views

Published on

Cómo montar una arquitectura SOA con mensajería y dirigida por eventos con RabbitMQ, y cómo llevar esas notificaciones al navegador con websockets y signalR

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,157
On SlideShare
0
From Embeds
0
Number of Embeds
446
Actions
Shares
0
Downloads
23
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

SOA multiplataforma con rabbitmq y websockets

  1. 1. SOA multiplataformaAplicaciones distribuidas con RabbitMQ y WebSocketsBraulio Megias@bmegiashttp://bmegias.wordpress.com
  2. 2. Índice Sistemas y aplicaciones distribuidas  Falacias de la computación distribuida  Acoplamiento Patrones de Integración. Mensajería AMQP y RabbitMQ En el navegador: WebSockets/SignalR
  3. 3. Sistemas Aplicación  Único ejecutable en única máquina  Usualmente con una única fuente de información  Conectiviqué? Sistema  Múltiples ejecutables en múltiples máquinas  Habitualmente con varias fuentes de información  La conectividad es una parte fundamental Un ejecutable de un sistema != aplicación
  4. 4. Servicios Servicio  Datos + Funcionalidad Sólo funcionalidad  Es una función, no un servicio  Ej: Una validación Sólo datos  Es una base de datos  Ej: Operaciones CRUD
  5. 5. Falacias computación distribuida La red es fiable La latencia es cero El ancho de banda no es un problema La red es segura La topología no va a cambiar El administrador sabe qué hacer Los costes de transporte no importan La red es homogénea
  6. 6. Más falacias El sistema es atómico / monolítico El sistema está acabado La lógica de negocio puede y debe estar centralizada
  7. 7. El sistema es atómico Problema  Si consideramos todo el sistema una unidad indivisible, el mantenimiento es una pesadilla  Si el sistema no fue diseñado para ser escalable a N máquinas, hacerlo puede en realidad ser contraproducente Soluciones  Internamente desacoplado. Modularización  Diseñar para escalar horizontalmente  Diseñar pensando en interacciones con otros
  8. 8. El sistema está acabado Problema  Los costes de mantenimiento son mayores a los de desarrollo  Cómo actualizaremos el sistema? Y si sólo se ha de actualizar una parte? Soluciones  Diseñar para mantenimiento  Diseñar para actualizaciones. Versionado
  9. 9. La lógica debe estar centralizada Problema  “El nombre de usuario tiene menos de 40 caracteres”  Comprobar en UI? Capa de lógica de negocio? BBDD?  Cuando esta regla cambie, dónde hay que tocar? Soluciones  La lógica estará distribuida. Diseñemos en consecuencia
  10. 10. Acoplamiento Plataforma Temporal Espacial
  11. 11. Plataforma Problemas  Interoperabilidad  Ojo con utilizar protocolos/formatos propietarios Soluciones  Usar protocolos estándar como http  Serializar a XML, o JSON
  12. 12. Temporal (I) Service A Service B MakeCustomerPreferred(id) Customer GetCustomerInfo(id) Calling thread is waiting for the result Save customer as preferred
  13. 13. Temporal (y II) Service A Service B Store data Publish updated customer info MakeCustomerPreferred(id) Save customer as preferred
  14. 14. Espacial Problema  Código de aplicación ha de saber dónde están los servicios colaboradores en la red Solución  Delegar a “alguien” que se encargue de hacer llegar la petición a quien corresponda  Envío de mensajes?
  15. 15. Patrones de integración Base de datos compartida Ficheros RPC Mensajería
  16. 16. Base de datos compartida Es EL MAL Acoplamiento absoluto  Esquema unificado  Aplicaciones externas? Cuello de botella Quién toca mis datos?
  17. 17. Ficheros Ventaja  Se explicita un contrato/formato Problemas  Cuando producir/consumir datos  Staleness/obsolescencia  Si queremos evitarla, es muy costoso de gestionar!  Acoplamiento espacial
  18. 18. Invocación remota de métodos Ventajas  Inmediatez  Encapsulamiento Problemas  Acoplamiento  de plataforma -> subsanable  Temporal  Espacial  Inmediatez - WTF?
  19. 19. Mensajería Completamente desacoplado: espacial, temporal, plataforma
  20. 20. Tipos de mensajes Comando  Enviado por N clientes a un servidor lógico  Servidor puede escalar horizontalmente  Ej: AgregarUsuario Evento  Enviado por un servidor lógico a N suscriptores  Ej: UsuarioCreado Tipado de mensajes simplifica enrutado
  21. 21. Ejemplo (I)Shop Order Billing Shipping PlaceOrder BillOrder OrderBilled ShipOrder OrderShipped
  22. 22. Ejemplo (y II)Shop Order Billing Shipping PlaceOrder OrderPlaced OrderBilled OrderShipped
  23. 23. A considerar Duplicar información Orden de los mensajes Mensajes repetidos
  24. 24. RabbitMQ http://www.rabbitmq.com/ AMQP Mensajes  Cuerpo + Routing Key Exchanges / Queues / Bindings  Direct  Fanout  Topic
  25. 25. AMQP (I) Advanced Message Queueing Protocol  http://www.amqp.org Abierto, platform-agnostic, interoperable Define cómo clientes y brokers interactúan  Los detalles quedan ocultos en las librerías cliente AMQP Model  Define enrutado y almacenamiento de mensajes
  26. 26. AMQP (y II)http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Grid_Installation_Guide/index.html
  27. 27. Exchanges: Fanouthttp://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Grid_Installation_Guide/index.html
  28. 28. Exchanges: Directhttp://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Grid_Installation_Guide/index.html
  29. 29. Exchanges: Topichttp://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_MRG/1.3/html/Grid_Installation_Guide/index.html
  30. 30. Exchange/Queue Cada mensaje recibido se envía a todas las colas que correspondan Un mensaje enrutado a una cola no se envía más de una vez, salvo reenvío tras fallo o rechazo
  31. 31. Enrutado simple Direct exchange Exchange  Unico por sistema Routing key  Tipo del mensaje Queue  Nombre del servicio consumidor
  32. 32. Cliente Comandos  Llamadas AJAX Eventos  Polling  Long-Polling / COMET WebSockets
  33. 33. Pollinghttp://marakana.com/bookshelf/html5_tutorial/web_sockets.html
  34. 34. Long Pollinghttp://marakana.com/bookshelf/html5_tutorial/web_sockets.html
  35. 35. WebSockets (I) Full-duplex Comunicación full-duplex utilizando un socket TCP Inicio: GETGET /chat HTTP/1.1Connection: UpgradeHost: example.comOrigin: http://example.comSec-WebSocket-Key1: 284 ^rI 2 447 8 Me1*V 8Sec-WebSocket-Key2: 30]8N763$84 12>Upgrade: WebSocket64:6E:AC:0C:FD:90:8A:51
  36. 36. WebSockets (II) RespuestaHTTP/1.1 101 WebSocket Protocol HandshakeUpgrade: WebSocketConnection: UpgradeSec-WebSocket-Origin: http://example.comSec-WebSocket-Location: ws://example.com/chat79:C5:C1:29:4A:60:8B:34:66:D5:61:10:C2:0C:4F:AA
  37. 37. WebSockets (y III)http://marakana.com/bookshelf/html5_tutorial/web_sockets.html
  38. 38. Implementaciones Emulación con Flash para navegadores antiguos Servidor  Superwebsocket  También cliente .net  http://superwebsocket.codeplex.com/  ASP.NET 4.5 + IIS 8  Requiere Windows 8 + VS11  Nuget Microsoft.websockets
  39. 39. SignalR https://github.com/SignalR/SignalR http://jabbr.net/ Notificaciones para aplicaciones web  Selección automática del método de conexión  Super-simple
  40. 40. Gracias por vuestra atenciónBraulio Megías@bmegiashttp://bmegias.wordpress.com

×