Transferencia de archivos / datos de gran tamaño en una arquitectura de microservicios

Actualmente, mi empresa está trabajando en la adopción de una arquitectura de microservicio, pero nos encontramos con algunos dolores de crecimiento (¡shock!) En el camino. Uno de los puntos clave de contención que enfrentamos es cómo comunicar grandes cantidades de datos entre nuestros diferentes servicios.

Como información básica, tenemos un almacén de documentos que sirve como depósito para cualquier documento que necesitemos manejar en toda la empresa. La interacción con dicha tienda se realiza a través de un servicio que proporciona al cliente una identificación única y una ubicación para transmitir el documento. Posteriormente se puede acceder a la ubicación del documento a través de una búsqueda con la ID proporcionada.

El problema es este: ¿tiene sentido que todos nuestros microservicios acepten esta identificación única como parte de su API con el fin de interactuar con documentos o no? Para mí, esto se siente inherentemente incorrecto: los servicios ya no son independientes y dependen del servicio de la tienda de documentos. Si bien reconozco que esto podría simplificar el diseño de la API e incluso tener algunas ganancias de rendimiento, el acoplamiento resultante más que contrarresta los beneficios.

¿Alguien sabe cómo los unicornios arcoíris (Netflix, Amazon, Google, etc.) manejan el intercambio de archivos / datos de gran tamaño entre sus servicios?

¿Alguien sabe cómo los unicornios arcoíris (Netflix, Amazon, Google, etc.) manejan el intercambio de archivos / datos de gran tamaño entre sus servicios?

Lamentablemente, no sé cómo manejan estos problemas.

El problema es este: ¿tiene sentido que todos nuestros microservicios acepten esta identificación única como parte de su API con el fin de interactuar con documentos o no?

Viola el Principio de responsabilidad única, que debería estar inherentemente en la arquitectura de su microservicio. Un microservicio, lógicamente uno, físicamente muchas instancias que representan uno, debería tratar un tema .

En el caso de su almacén de documentos, tiene un punto, donde van todas las consultas de documentos (por supuesto, podría dividir esta unidad lógica en múltiples almacenes de documentos para varios tipos de documentos).

• Si su "aplicación" necesita trabajar en un documento, le pregunta al microservicio respectivo y procesa sus resultados.

• Si otro servicio necesita un documento real o partes del mismo, debe solicitarlo.

Uno de los puntos clave de contención que enfrentamos es cómo comunicar grandes cantidades de datos entre nuestros diferentes servicios.

Este es un problema arquitectónico:

1. Disminuya la necesidad de transferir grandes cantidades de datos.

   Idealmente, cada servicio tiene todos sus datos y no necesita transferencia para simplemente atender solicitudes. Como una extensión de esta idea, si tiene la necesidad de transferir datos, piense en la redundancia (* de manera positiva_): ¿Tiene sentido tener los datos redundantes en muchos lugares (donde se necesitan)? Piense en cómo las posibles inconsistencias podrían dañar sus procesos. No hay transferencia más rápida que en realidad ninguna .

2. Disminuir el tamaño de los datos en sí.

   Piense en cómo podría comprimir sus datos: comenzando con algoritmos de compresión reales hasta estructuras de datos inteligentes . Cuanto menos pase por el cable, más rápido eres.

Si la ID devuelta por su almacén de documentos es la forma de hacer referencia a documentos en todo el sistema, entonces tiene sentido que todos los servicios acepten esa 'ID de documento' en su API cuando el servicio necesita saber con qué documento necesita trabajar.

Esto no necesariamente crea un acoplamiento más estricto entre los servicios de lo necesario. Los servicios que necesitan acceder a los documentos deben acceder al servicio de almacenamiento de documentos de todos modos y necesitan esa identificación para indicarle a la tienda a qué documento acceder.
Es posible que los servicios que no acceden a los documentos directamente necesiten pasar la ID del documento, pero para esos servicios sería solo una cadena arbitraria que no crea una dependencia.

Personalmente, prefiero no usar un servicio de almacenamiento de documentos y una identificación de documento separados, sino una URL para acceder a los documentos (con la autenticación de encabezado adecuada). Con este enfoque, no necesitará otros servicios para confiar en el servicio de documentos, sino que podría usar la URL completa para acceder al documento. Y también tiene sentido cuando se trata de escalar, puede usar múltiples almacenes de documentos y cuando el almacenamiento crece y proporciona la URL.

Sin embargo, es posible que necesite un servicio (s) para cargar un documento y obtener su URL.

¿Alguien sabe cómo los unicornios arcoíris (Netflix, Amazon, Google, etc.) manejan el intercambio de archivos / datos de gran tamaño entre sus servicios?

Verifique las especificaciones de la API REST de Amazon S3, aparentemente devuelven el objeto completo en bytes. Parece que no hay muchas opciones si está diseñando un microservicio. Enlace de formato de respuesta de Amazon S3