Microservicios REST o AMQP, en cuyo caso

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

He leído que el acoplamiento flexible entre servicios es algo bueno 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 REST es 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?

Al descartar REST, pierde mucho más que HATEOAS. Si sus microservicios son públicos (y es una buena idea que sean públicos o al menos tienden a ser públicos algún día¹), usar cualquier 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 analizarlos. No estoy seguro de qué herramientas debo usar para depurar los intercambios de AMQP.

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

El aspecto asincrónico 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 deberían ser: si necesito recuperar una copia de seguridad de archivos 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 operaciones primarias:

• Conseguir un producto,

• Almacenar una factura,

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

• Procesar todas las facturas a partir de septiembre y notificar a la aplicación cuando el informe esté listo para mostrarse (dado que la operación suele durar entre dos y diez minutos),

  ^{El beneficio de AMQP aquí es su aspecto asincrónico. Una solicitud HTTP pendiente durante diez minutos tiene una buena probabilidad de causar un tiempo de espera y otros problemas.}

• Enviar la información de que las copias de seguridad estaban dañadas 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 otros, la capacidad de agregar suscriptores sin cambiar la aplicación que rastrea las copias de seguridad y activa la alerta cuando encuentra una corrupta.}

^{¹ Un servicio web público no es necesariamente utilizado por usuarios externos a una empresa. En empresas grandes o medianas, su servicio a menudo es utilizado por otras divisiones de la misma empresa y tiene los mismos requisitos que el que utilizaría cualquier tercero: debe desconfiar de cualquier llamada (el hecho de que alguien nunca saber que quién llama a su servicio trabaja 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 necesariamente saber inglés), etc.}

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 duración, eventos y orquestación de microservicios.

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

AMPQ puede funcionar bien expuesto sobre Websockets, que puede parecerse a un punto final REST si lo mira de reojo.

REST es una tecnología estándar que es especialmente adecuada para la interoperabilidad entre componentes: esta es la parte clave, es excelente para crear un servicio web que otra persona pueda consumir. Sin embargo, sufre 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, puede usar el protocolo que desee: ya no está limitado por el uso de uno que sea tan interoperable. Puede usar un MQ o algo más estrechamente acoplado y con mejor 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.

AMQP también admite la comunicación punto a punto (por ejemplo, consulte el python-qpid-protontutorial). Puede implementar una interfaz RESTful usando eso, desde REST !=HTTP.

AMQP también funciona mucho mejor que HTTP.