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

La mia azienda sta attualmente lavorando all'adozione di un'architettura a microservizi, ma stiamo incontrando alcuni dolori crescenti (shock!) Lungo la strada. Uno dei principali punti di contesa che stiamo affrontando è come comunicare grandi quantità di dati tra i nostri diversi servizi.

Come sfondo abbiamo un archivio documenti che funge da archivio per qualsiasi documento che potremmo dover gestire in tutta l'azienda. L'interazione con detto negozio avviene tramite un servizio che fornisce a un cliente un ID univoco e una posizione per lo streaming del documento. È possibile accedere successivamente alla posizione del documento tramite una ricerca con l'ID fornito.

Il problema è questo: ha senso che tutti i nostri microservizi accettino questo ID univoco come parte della loro API allo scopo di interagire con i documenti o no? Per me questo sembra intrinsecamente sbagliato: i servizi non sono più indipendenti e si basano sul servizio dell'archivio documenti. Anche se riconosco che ciò potrebbe semplificare la progettazione dell'API e forse avere anche alcuni vantaggi in termini di prestazioni, l'accoppiamento risultante più che controbilanciare i vantaggi.

Qualcuno sa come gli unicorni arcobaleno (Netflix, Amazon, Google, ecc.) Gestiscono lo scambio di file / dati di grandi dimensioni tra i loro servizi?

Qualcuno sa come gli unicorni arcobaleno (Netflix, Amazon, Google, ecc.) Gestiscono lo scambio di file / dati di grandi dimensioni tra i loro servizi?

Purtroppo non so come gestiscono tali problemi.

Il problema è questo: ha senso che tutti i nostri microservizi accettino questo ID univoco come parte della loro API allo scopo di interagire con i documenti o no?

Infrange il principio di responsabilità singola, che dovrebbe essere intrinsecamente nell'architettura del microservizio. Un microservizio - logicamente uno, fisicamente molte istanze che rappresentano uno - dovrebbe occuparsi di un argomento .

Nel caso del tuo archivio documenti, hai un punto in cui vanno tutte le richieste di documenti (ovviamente puoi dividere questa unità logica in più archivi di documenti per diversi tipi di documenti).

• Se la tua "applicazione" deve funzionare su un documento, richiede il rispettivo microservizio ed elabora i suoi risultati.

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

Uno dei principali punti di contesa che stiamo affrontando è come comunicare grandi quantità di dati tra i nostri diversi servizi.

Questo è un problema architettonico:

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

   Idealmente, ogni servizio ha tutti i suoi dati e non ha bisogno di trasferimenti per soddisfare 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 luoghi (dove sono necessari)? Pensa a come possibili incoerenze potrebbero danneggiare i tuoi processi. Non c'è trasferimento più veloce come in realtà nessuno .

2. Ridurre la dimensione dei dati stessi

   Pensa a come puoi comprimere i tuoi dati: a partire da algoritmi di compressione effettivi fino a strutture di dati intelligenti . Meno passa il filo, più veloce sei.

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

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

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

Tuttavia, potresti aver bisogno di uno o più servizi per caricare un documento e ottenere l'URL.

Qualcuno sa come gli unicorni arcobaleno (Netflix, Amazon, Google, ecc.) Gestiscono lo scambio di file / dati di grandi dimensioni tra i loro servizi?

Verifica le specifiche dell'API REST di Amazon S3, apparentemente restituiscono l'oggetto completo in byte. Sembra che non ci siano molte opzioni se stai progettando un microservizio. Link al formato di risposta Amazon S3