Soluzione di marshalling dati per applicazione multilivello

7

Sto sviluppando una soluzione software multilivello in cui ho 1 server, n thin client engine (TCE) e m thin client al livello più elementare. Ho in programma di avere molti altri componenti per la scalabilità, dove componenti aggiuntivi possono essere aggiunti per la congestione ecc. Ma questi sono i componenti di base.

Quando ho progettato la soluzione originariamente ho creato il mio protocollo di comando per la comunicazione tra il server e TCE così come il TCE ei thin client che usano JSON. Sono arrivato allo sviluppo di set di dati e trasferimento di dati anziché solo messaggi. L'applicazione può contenere facilmente 100 GB di dati e poiché si tratta di una soluzione in memoria (solo database per la persistenza), devo effettuare il marshalling dei dati tra diversi livelli e gestire i trasferimenti delta (tutti sulla stessa rete ma su hardware diverso). Ho subito capito che tutta la logica di sincronizzazione che ho bisogno di scrivere sarà immensa, quindi ho deciso di fare un passo indietro e riflettere su questo prima di andare troppo avanti e impegnarmi.

Dato che sono l'unico sviluppatore, sono sempre alla ricerca di modi per ridurre al minimo lo sforzo, così posso ottenere di più. Ho deciso di passare alla serializzazione integrata Java poiché i miei componenti che ospitano le versioni del set di dati sono al 100% Java. Dopo aver fatto questo e test, ovviamente ho incontrato molti errori su ciò che può essere serializzato. Come puoi sapere, qualsiasi istanza di una classe che vuoi inserire nello stream dell'oggetto deve implementare l'interfaccia Serializable. Mi sono reso conto che il grafico è molto grande quando sto provando a trasferire un oggetto. Ciò significa che ho bisogno di modificare tutte le mie classi che vengono utilizzate tra i livelli per essere serializzabili e contrassegnare solo i campi server come transitori. Anche questo è molto lavoro.

Quindi volevo chiedere alla comunità ciò in cui credono che il miglior design dovrebbe essere qui. La mia intenzione di utilizzare la serializzazione Java era che potevo assegnare un oggetto radice da trasferire e tutto ciò che è collegato a downstream viene inviato, il che rende le cose molto facili per me. Anche per l'elaborazione delta questo potrebbe rendere le cose molto più semplici per me come sviluppatore dal momento che non dovrei scrivere quasi la stessa logica di sincronizzazione dei dati.

Gli obiettivi che sto cercando di raggiungere sono una soluzione che richiede modifiche minime a tutte le classi utilizzate tra i livelli e una soluzione scalabile.

Ho esaminato i buffer del protocollo di google, ma questo è qualcosa che rende meglio le mie comunicazioni con thin client poiché avrò un client Thin Client, client Web e client Java.

    
posta Mark 21.02.2017 - 01:37
fonte

2 risposte

1

Raccomando di utilizzare qualcosa come ProtocolBuffers o Apache Avro, in questo modo è possibile definire i dati in modo semplice e i dati non sono legati all'implementazione di una lingua. È un grande sistema, potresti voler implementare qualche parte separatamente in seguito, oppure potresti voler fare delle modifiche architettoniche. Usando una libreria di serializzazione dati portatile, puoi isolare la tua memoria di dati più facilmente.

    
risposta data 01.01.2019 - 07:30
fonte
0

Oltre 100 GiB, non ci hai fornito alcuna specifica. In particolare, ti interessa principalmente la latenza o il throughput?

Ecco la cosa più semplice che potrebbe funzionare per specifiche così vaghe: persistere ogni cosa, trattarla come la Sorgente della Verità. Quindi passa le maniglie in giro, quindi i tuoi oggetti (piccoli, serializzabili) sono essenzialmente indicatori delle strutture di dati persistenti. Hai citato dei delta informatici. Potresti trovare conveniente pensare di "elaborare" un oggetto grande come "calcolare un delta" da applicare sopra quell'oggetto. Non è necessario "sincronizzare" quando si sta scrivendo in un archivio di oggetti di sola aggiunta e si accumulano descrittori di delta che modificano l'interpretazione di un oggetto in evoluzione.

BTW, il supporto per la serializzazione di java può essere conveniente per alcuni progetti, ma l'introspezione rallenta. Avro e altri mostrano la strada per approcci più rapidi e più compatti.

    
risposta data 23.11.2017 - 18:02
fonte

Leggi altre domande sui tag