Qual è l'opzione migliore per scambiare grandi quantità di dati in un'architettura di micro-servizi?

4

L'applicazione su cui sto lavorando richiede che il contenuto del testo venga estratto da vari formati di documenti proprietari come i documenti Microsoft Word (doc, ppt, xls), pdf ed ecc.

Sto pianificando di implementare un micro-servizio che prende il documento in formato proprietario come input e restituisce il testo estratto come output.

Questa soluzione richiede che il micro-servizio possa scambiare grandi quantità di dati per richiesta (dell'ordine da 1 MB a 100 MB). L'aspettativa è che il microserive dovrebbe essere in grado di scalare fino a 1000 richieste al secondo.

W.r.t a questa soluzione vuole capire

  • È corretto trasferire dati con questa frequenza rispetto all'architettura dei micro-servizi?
  • Pianificazione dell'uso delle API di riposo per il trasferimento dei dati. È una buona opzione?
posta user2586432 26.12.2017 - 12:47
fonte

2 risposte

5

Ci sono alcuni aspetti importanti da considerare prima.

Streaming

Immaginiamo che il file da 100 MB sia ricevuto dal servizio A che lo trasferisce al servizio B, che, a sua volta, usa il servizio C per eseguire l'analisi del formato proprietario.

L'approccio sbagliato sarebbe che i servizi A e B iniziassero a inviare il file al servizio sottostante solo dopo hanno ricevuto il file completamente dal client:

Invece,quandoinizianoricevonoilfile,devonoinviarloalserviziosottostante.

Questo significa che non stai aspettando il tempo necessario per trasferire 100 MB tre volte, ma solo una volta, più la latenza ...

Latenza

La latenza, d'altra parte, non può essere evitata. Prima di iniziare a trasferire il file, ogni servizio di intermediazione dovrebbe ancora aprire la connessione HTTP / HTTPS al servizio sottostante.

Se i tuoi micro-servizi si trovano nello stesso data center, è probabile che la latenza sia questione di pochi millisecondi. Se i servizi sono ospitati in diversi data center, la latenza potrebbe aumentare. Con un numero elevato di intermediari, questo può diventare un problema e interesserà anche richieste di piccole dimensioni.

Possibile DOS

Quando usi la tecnica di streaming, dovresti controllare di non aprirti a un possibile attacco DOS. Il rischio è che gli intermediari manterranno la connessione HTTP a condizione che il client invii il file. L'attacco DOS consisterebbe quindi nell'invio di molti file a una velocità molto bassa al fine di esaurire le connessioni che i servizi sono in grado di elaborare.

    
risposta data 26.12.2017 - 13:24
fonte
1

Il mio suggerimento è di partire da qualcosa di molto semplice ed evolvere. Prova AWS Lambda + API Gateway per l'avvio. Avvio molto semplice, ridimensionamento automatico fino a 1000 esecuzioni simultanee per regione. Se ti occorrono più esecuzioni concorrenti, puoi pensare al bilanciamento del carico su più aree. Oppure cerca di ingrandire la quota aprendo la richiesta. La domanda è il prezzo. può essere costoso Prendi in considerazione i risultati di memorizzazione nella cache se si utilizzano gli stessi documenti.

Arch più complesso:

  1. Carica documento su s3. (Solo dopo aver completato il caricamento, chiama Lambda con il nome del doc)
  2. Chiama Lambda per analizzare il documento in s3. (Dopo, elimina Doc, memorizzando l'hash del documento con il risultato nella cache)
  3. Restituisce il risultato.

Questa è un'architettura più saggia da diverse prospettive.

  • Le bilance si adattano molto bene a più client per il caricamento di s3.
  • Latenza Lambda < - > S3 molto meglio
  • Semplice da sviluppare
  • pricing
risposta data 10.12.2018 - 16:18
fonte

Leggi altre domande sui tag