Trasferimento di file / dati di grandi dimensioni in un'architettura di Microservice

Does anyone know how the rainbow unicorns (Netflix, Amazon, Google, etc.) handle large files / data exchange between their services?

Purtroppo non so come affrontano questi problemi.

The problem is this - Does it make sense for all our microservices to be accepting this unique ID as part of their API for the purposes of interacting with documents or not?

Violi il Principio di Responsabilità Unica, che dovrebbe essere inerentemente nell'architettura del tuo microservizio. Un microservizio - logicamente uno, fisicamente molte istanze che rappresentano uno - dovrebbe occuparsi di un argomento .

Nel caso del tuo negozio di documenti, hai un punto, dove vanno tutte le query per i documenti (ovviamente puoi suddividere questa unità logica in più archivi di documenti per diversi tipi di documenti).

• Se la tua "applicazione" deve lavorare su un documento, chiede al rispettivo microservice ed elabora i suoi risultati.

• Se un altro servizio richiede un documento effettivo o parti di esso, deve chiedere al servizio documenti.

One of the key contention points we are facing is how to communicate large quantities of data between our different services.

Questo è un problema architettonico:

1. Riduci la necessità di trasferire grandi quantità di dati

   Idealmente, ogni servizio ha tutti i suoi dati e non ha bisogno di trasferimenti per servire semplicemente le richieste. Come estensione di questa idea - se hai la necessità di trasferire dati, pensa alla ridondanza (* in modo positivo_): Ha senso avere i dati ridondanti in molti posti (dove sono necessari)? Pensa a quanto le incongruenze potrebbero danneggiare i tuoi processi. Non c'è nessun trasferimento più veloce come in realtà nessuno .

2. Diminuisci le dimensioni dei dati stessi

   Pensa a come potresti comprimere i tuoi dati: a partire da algortihms di compressione effettivi fino a strutture dati intelligenti . Meno va oltre il filo, più veloce sei.

Se l'ID restituito dall'archivio documenti è il modo di fare riferimento ai documenti in tutto il sistema, allora ha senso che tutti i servizi accettino tale "ID documento" sulla loro API quando il servizio deve sapere con quale documento ha bisogno di lavorare.

Questo non crea necessariamente un accoppiamento più stretto tra i servizi di quanto necessario. I servizi che devono accedere ai documenti devono comunque accedere al servizio di archivio documenti e hanno bisogno di tale ID per comunicare al negozio il documento a cui accedere.
I servizi che non accedono direttamente ai documenti potrebbero dover passare l'ID del documento, ma a quei servizi sarebbe solo una stringa arbitraria che non crea una dipendenza.

Personalmente, preferirei non utilizzare un servizio di archivio documenti e un ID documento separati, ma un URL per accedere ai documenti (con autenticazione di intestazione corretta). Con questo approccio non avrai bisogno di altri servizi per fare affidamento sul servizio di documentazione, ma potrebbe semplicemente utilizzare l'URL completo per accedere al documento. Inoltre, ha senso anche quando si parla di ridimensionamento, è possibile utilizzare più archivi di documenti come e quando lo spazio di archiviazione cresce e fornisce l'URL.

Tuttavia potresti aver bisogno di un / i servizio / i per caricare un documento e ottenere il suo URL.

Does anyone know how the rainbow unicorns (Netflix, Amazon, Google, etc.) handle large files / data exchange between their services?

Verifica le specifiche API REST di Amazon S3, apparentemente restituiscono l'intero oggetto in byte. Sembra non molte opzioni se stai progettando un microservizio. link del formato di risposta Amazon S3