Più server per ogni modulo o un server per gestire le richieste da più client

Non so quanto è grande un progetto, ma a me sembra che non dovrebbe essere una questione di gusti. Ci sono fattori di progettazione da considerare. La tua squadra dovrebbe confrontare i fattori di progettazione e valutarli in base a rischio, costo e probabilità, quindi utilizzare una sorta di metodologia di punteggio oggettivo per classificare le opzioni, entrambe perfettamente valide per situazioni diverse.

Alcune domande per il tuo gruppo da considerare:

Quanto è il rischio che diversi protocolli in entrata entrino in conflitto l'uno con l'altro? Potrebbe essere necessario un maggiore isolamento del processo se, ad esempio, il driver RS232 perde. O forse è noto che la scatola si rompa occasionalmente, nel qual caso si vorrebbe che fosse eseguita interamente su una macchina separata. O forse sono tutti completamente stabili, ma vuoi che i loro thread vengano trattati in modo diverso, ad es. pool di dimensioni diverse, timeout più brevi o configurazione indipendente.

C'è stato? Qual è l'impatto del ripristino di uno qualsiasi dei servizi? Hai ridondanza?

Quanto velocemente crescerai? Se hai intenzione di crescere velocemente, forse dovresti provare il più possibile per far funzionare tutti i servizi su una singola scatola, così puoi ridimensionarli più facilmente.

Quanto è complicata la logica aziendale? Se i tuoi servizi sono solo una sorta di pass-through per i servizi back-end, l'opzione 2 non sembra così male. Se sono molto complicati, l'opzione 1 è migliore.

Quale sarà il ciclo di rilascio? Quando è necessario distribuire correzioni di bug, c'è qualche vantaggio nell'avere servizi separati? Avete in programma di sincronizzare le versioni delle funzionalità o alcuni canali riceveranno le pubblicazioni più spesso? Il codice verrà gestito da squadre diverse?

Inoltre, assicurati di coinvolgere il tuo team di ingegneri di rete, poiché sembra che questa soluzione richieda molto impianto idraulico e potrebbero esserci anche problemi di connettività.

Sempre server multipli , in quanto un server può essere occupato nella comunicazione seriale a meno che non scada e durante tale periodo non elaborerà altre comunicazioni.

Utilizza più entità comunicanti e crea una coda di elaborazione dei telegrammi con i buffer .

Soluzione uno in batteria, ma potresti dividerlo in 2 o 3 micro-server, che comunicano usando un protocollo di messaggistica (ce ne sono alcuni, come zeromq).

Anche una combinazione tra 1 e 2 è piacevole, dispone di un server che blocca tutti i client e ridistribuisce la comunicazione su ciascun dispositivo.

E in generale usi app real server, non implementare le tue in comunicazione con i client desktop.

Problemi con sol 2:

• complessità sul client
• difficile da cambiare interfaccia client
• cattiva separazione delle preoccupazioni

In primo luogo, il vantaggio della prima architettura è che i client sono un'unica interfaccia a cui si stanno connettendo e utilizzando. Il secondo vantaggio dell'architettura è che si adatta bene e le diverse connessioni sono utilizzate per risorse diverse, ma ora hai perso il primo vantaggio dell'architettura.

Suggerisco una combinazione di entrambi: Avere un'unica API nel server e utilizzare un parametro per decidere come gestire richieste diverse. Questo non era necessario nella seconda architettura poiché diversi client avevano un diverso punto di contatto all'interno del server, quindi questo aggiunge un po 'di complessità e cambiamenti.

Consentitemi di reiterare un punto importante: il server stesso potrebbe essere suddiviso in più di un servizio, ma ha un'unica API