Più piccoli programmi collegati tramite socket vs un programma di grandi dimensioni

I intuitively don't like this idea.

Beh, intuitivamente, mi piace l'idea di dividere i programmi in parti più piccole. Ma se i diversi processi girano sempre tutti sulla stessa macchina, la comunicazione di rete non è probabilmente la forma ottimale di IPC. Per comunicazioni ad alta velocità tra processi, la memoria condivisa potrebbe essere l'opzione migliore. Ma qualunque sia l'approccio che scegli, devi misurare o almeno stimare la performance prima di effettuare qualsiasi chiamata di giudizio.

The colleague in question worked on another project which used that approach and had no end of problems that were hard to track down and debug.

Devi controllare che tipo di problemi e dove sono state le cause alla radice. Se hanno problemi a causa della concorrenza, incontrerai gli stessi problemi (se non di più) quando provi una soluzione multi-thread.

provide updates to another system at nearly 1000Hz

Se si tratta di "alta velocità", dipende dalla velocità delle macchine di produzione e dalla dimensione delle operazioni coinvolte in ciascun aggiornamento. Quando si tratta di prestazioni, i sentimenti viscerali sono estremamente inaffidabili, tu devi misurare le cose . Se il tuo collega crede che il suo approccio sarà abbastanza veloce, e tu credi che non lo farà, almeno uno di voi dovrà provare o falsificare la sua opinione. Ad esempio, uno di voi potrebbe implementare un piccolo prototipo per simulare la comunicazione tra processi e misurare la velocità. Tutto il resto sta guardando in una ciotola di vetro.

Potrebbero o non potrebbero essere rilevanti per la tua applicazione, ma alcuni benefici per la soluzione multi-processo che non sembravi considerare sono:

• Controllo dei permessi a grana più fine. Puoi avere permessi separati per la webcam e gli altri sensori.
• Più facile per testare i sensori in isolamento.
• È più facile prendere in giro un sensore in fase di runtime.
• Più facile ottenere terze parti per scrivere codice per i loro sensori senza dover aprire il tuo codice.
• Uso di strumenti come wireshark per la risoluzione dei problemi, sia durante lo sviluppo che sul campo.
• L'unico contesto di cui sono a conoscenza dove "stateful" è visto come un attributo positivo è quando le parti stateful di un sistema sono limitate a un piccolo ambito come un actor , che sembra supportare il design del tuo collega più del tuo.
• Più facile rilasciare un blocco e riavviare il processo di un solo sensore senza dover riavviare l'intero sistema.
• Può scalare semplicemente aggiungendo hardware.
• La comunicazione socket con source e dest sulla stessa macchina è relativamente efficiente.

Ulteriori svantaggi per la soluzione multi-processo:

• Trattare con backpressure è più complesso.
• Se stai essenzialmente passando i dati grezzi da ciascun sensore senza alcun filtraggio o elaborazione, hai appena cambiato l'applicazione del controller leggendo da un driver USB alla lettura da un driver di rete, senza alcun reale guadagno nell'astrazione .

L'approccio che il tuo collega sta sostenendo è spesso definito come architettura dei microservizi ed è abbastanza in voga in questi giorni. Ha un numero di vantaggi potenziali :

• Scalabilità: può renderlo relativamente facile da scalare semplicemente aggiungendo macchine aggiuntive / istanze VM.
• Robustezza: con un design appropriato può essere resa tollerante ai singoli processi dei microservizi che si bloccano, perdendo la connettività o altrimenti non disponibili.
• Estensibilità: l'utilizzo di tecnologie Web standard per l'interfaccia tra microservizi (in genere richieste HTTP REST con risposte JSON o XML) può rendere relativamente facile per terze parti o clienti l'interfaccia con il sistema ed estenderlo per le proprie esigenze.

Ha anche una serie di svantaggi:

• Prestazioni: generalmente pagherete un costo di prestazione per la comunicazione tra processi. Questo può essere molto significativo se si creano API di stile REST http.
• Complessità: in genere è necessario un bel po 'di codice in più per eseguire il marshalling dei dati tra i processi e passare semplicemente i dati tra i thread in un singolo processo. Introdurrai anche dipendenze sulle librerie per le comunicazioni di rete, il supporto http, ecc.
• Debugabilità: in genere è più complesso eseguire il debug di un'applicazione composta da più processi di comunicazione indipendenti rispetto all'utilizzo di un debugger integrato di IDE su un singolo processo.

Non sono sicuro di cosa intendi quando dici che il design "non sembra un progetto molto accurato". Generalmente "state-ful" è considerato una cattiva caratteristica di un design e microservizi "apolide" sono considerati di buon design.

Considerate le informazioni sui requisiti che fornite nel post, tuttavia, ritengo che un progetto basato sui microservizi sarebbe eccessivo per il vostro caso d'uso e i vantaggi non giustificherebbero la complessità aggiuntiva. I vantaggi delle architetture dei microservizi tendono a entrare davvero in gioco solo quando si creano servizi Web su vasta scala che pongono un vantaggio su scalabilità, robustezza ed estensibilità.

I potenziali benefici dell'architettura di un microservizio sono realizzati solo con un design ben congegnato. A mio avviso, tale architettura richiede un design più all'avanguardia (in particolare quando si tratta del protocollo per la comunicazione tra microservizi) rispetto a un singolo processo di progettazione se si vuole avere successo nel risolvere il problema in questione.