Microservices REST o AMQP, en qué caso

13

He leído muchos artículos sobre la arquitectura de microservicios y me preguntaba cuándo usar AMQP o REST.

He leído que el acoplamiento suelto entre servicios es una buena cosa y AMQP parece ser una buena opción en ese caso. Pero si usamos AMQP, esto significa que ya no necesitamos puntos finales REST (pero significa que perdemos el concepto HATEOAS).

¿Pero es REST realmente una buena manera de construir mis servicios? Porque no usaré ningún punto final ... ¿En qué caso uno es mejor que el otro?

¿Cuándo debo usar uno u otro?

    
pregunta Thomas thomas 12.10.2015 - 12:08

4 respuestas

6

Al descartar REST, pierde mucho más que solo HATEOAS. Si sus microservicios son públicos (y es una buena idea que sean públicos o que al menos tiendan a ser públicos algún día), usar cualquier otra cosa que no sea REST y SOAP sería problemático:

  • Algunos desarrolladores nunca usaron AMQP,

  • Algunos han usado AMQP, pero a menudo están mucho más familiarizados con REST y SOAP,

  • Las bibliotecas AMQP para algunos idiomas no son particularmente sencillas,

  • La experimentación manual con el servicio es muy limitada: puedo usar CURL para hacer cualquier solicitud a Amazon S3; ¿qué debo instalar en mi máquina si quiero jugar con una variante AMQP de S3?

  • La depuración de REST y SOAP es fácil. Acabo de rastrear los intercambios HTTP y los analizo. No estoy seguro de qué herramientas debo usar para ver los cambios de AMQP.

AMQP es excelente, pero se realiza con un propósito muy específico de intercambios basados en eventos. Si bien es técnicamente posible realizar RPC con AMQP, no es su propósito principal.

El aspecto asíncrono también es importante. A veces es un beneficio: no quiero bloquear la interfaz de usuario de una aplicación mientras hago solicitudes a los servidores. A veces, solo hace las cosas más difíciles de lo que necesitan: si necesito recuperar una copia de seguridad de un archivo de Amazon S3 porque la local estaba dañada, y luego restaurar la copia de seguridad, mi archivo por lotes necesariamente necesita CURL para finalizar su trabajo antes de continuar, y una operación sincrónica (con un tiempo de espera específico) tiene mucho sentido.

Mantenga REST para las operaciones primarias:

  • Obtención de un producto,

  • Almacenar una factura,

y use AMQP para las tareas en las que la mensajería realmente tiene sentido:

  • Procesando todas las facturas de septiembre y notificando a la aplicación cuando el informe esté listo para ser mostrado (dado que la operación toma generalmente de dos a diez minutos),

    El beneficio de AMQP aquí es su aspecto asíncrono. Una solicitud HTTP pendiente durante diez minutos tiene una buena posibilidad de causar un tiempo de espera y otros problemas.

  • Enviando la información de que las copias de seguridad se corrompieron a todos los interesados, como las personas de soporte, los administradores de la base de datos, el equipo de monitoreo, los desarrolladores de la aplicación que utiliza esta base de datos, etc.

    El beneficio de AMQP aquí es, entre otras cosas, la posibilidad de agregar los suscriptores sin cambiar la aplicación que rastrea las copias de seguridad y activa la alerta cuando encuentra una dañada.

¹ Un servicio web público no es necesariamente utilizado por usuarios fuera de la empresa. En compañías grandes o medianas, su servicio es a menudo utilizado por otras divisiones de la misma compañía y tiene los mismos requisitos que el que usaría un tercero: debe desconfiar de cualquier llamada (el hecho de que algún indio que usted quiera nunca se enteró de quién llama su servicio en la misma compañía que usted no significa que no explotará sus problemas de seguridad), debe documentarse correctamente (porque el mismo indio no necesariamente conoce su número de teléfono y no lo hace). necesariamente saber inglés), etc.

    
respondido por el Arseni Mourzenko 10.01.2016 - 15:08
4

Usa ambos.

Los servicios web JSON de estilo REST son excelentes para la interoperabilidad con javascript, ios, etc.

AMQP es ideal para procesos de larga ejecución, eventos y orquestación de microservicios.

Pero ambos son solo envoltorios de comunicación para el servicio real, puede exponer el mismo servicio de varias maneras y probablemente debería hacerlo.

AMPQ puede funcionar bien expuesto a través de Websockets, que puede parecerse bastante a un punto final REST si lo miras con los ojos entrecerrados.

    
respondido por el Ewan 12.10.2015 - 13:00
0

REST es una tecnología estándar que es particularmente adecuada para la interoperabilidad entre componentes: esta es la parte clave, es excelente para hacer un servicio web que otra persona pueda consumir. Sin embargo, tiene los problemas habituales de dicha interoperabilidad, ya que es menos eficiente que un protocolo personalizado.

Si está escribiendo una arquitectura de back-end donde los servicios solo los consume usted mismo, entonces puede usar el protocolo que desee, ya no estará limitado por el uso de uno que sea tan interoperable. Puede utilizar un MQ o algo más estrechamente acoplado y de mayor rendimiento. El que use depende de su caso de uso, un bus de mensajes es muy bueno para un conjunto distribuido de servicios que procesan datos donde al cliente no le importa quién recibe los mensajes que envía.

    
respondido por el gbjbaanb 12.10.2015 - 12:29
0

AMQP también admite la comunicación punto a punto (por ejemplo, consulte el tutorial python-qpid-proton ). Podría implementar una interfaz RESTful utilizando eso, ya que REST != HTTP.

AMQP también se desempeña mucho mejor que HTTP.

    
respondido por el Cochise Ruhulessin 09.10.2016 - 03:15

Lea otras preguntas en las etiquetas