quali sono i limiti dell'architettura del server client [chiuso]

I limiti delle implementazioni Client / Server sono ben noti. Passare da un'applicazione stand-alone a un approccio client / server introduce alcuni nuovi problemi da gestire.

• Il server avrà più connessioni contemporaneamente. Gestire questo in modo sufficientemente efficiente senza che i diversi client causino conflitti sul database dovrebbe essere semplice da risolvere con solo 10 client che parlano al server.
• L'aggiunta di una rete e un server aggiunge latenza. poiché si trova sulla stessa LAN, questo non sarà enorme per richiesta, ma tieni d'occhio quanto deve essere loquace il tuo client con il server.
• Devi decidere il protocollo utilizzato dal client e dal server per comunicare e capirsi a vicenda. Un servizio web RESTful può essere un approccio adatto alle tue esigenze
• Gestione dei cambiamenti. Quando il suo unico blocco di hardware, gli aggiornamenti si verificano in isolamento di altri sistemi. Ora, quando è necessario implementare un aggiornamento, ci sono più client che parlano con un server, gli aggiornamenti devono essere un po 'più pensati.

Dato che sei interessato al tipo di prestazioni che puoi aspettarti su una LAN, ecco la mia opinione ...

La rete tipica di un ufficio è 1GBit Ethernet, che è in grado di trasferire al server un massimo di circa 50 MByte di dati reali al secondo. Se raggiungi questo limite, hai un problema di progettazione serio nel protocollo del tuo server client.

Se hai problemi di prestazioni, la soluzione sarà rendere il protocollo client / server più efficiente, e questo potrebbe significare più cambiamenti nel modo in cui il lato client funziona di quanto non ti aspetti attualmente.

Questo tipo di progetto è un lavoro interessante, e potrebbe richiedere del tempo per farlo correttamente. Assicurati di avere il tempo libero (e il budget) per affrontare il nuovo apprendimento che farai.

Rispondere a questa domanda con numeri complessi richiederebbe conoscere il numero di clienti, la qualità delle loro connessioni di rete, le distanze tra loro, l'un l'altro e il server, quanto velocemente il server risponde a ogni possibile richiesta (nei momenti di punta!) e tutti i tipi di altri dettagli. Direi che la qualità delle loro connessioni è probabilmente il limite superiore difficile.

L'unico modo affidabile per scoprire i limiti concreti di un'architettura è costruire un prototipo e testarlo . Questo è il motivo per cui le metodologie "agili" sono di gran moda in questi giorni. Dato che stai parlando di una LAN, dovrebbe essere abbastanza semplice afferrare una dozzina di macchine, collegarle in un modo simile ai tuoi clienti, e mettere su di esse dei programmi semplici che si bombardano a vicenda con informazioni false sulle scorte.

P.S. Per rispondere alla domanda più generale che il tuo titolo sembra chiedere, i limiti architetturali del client-server sono tutti relativi a ciò che i server possono fare. Quando aggiungi molti più client, alla fine dovrai aggiungere più server (e bilanciare il carico), indipendentemente dall'app; alcune app possono scalare meglio con il peer-to-peer. E, naturalmente, tutte le architetture di rete sono limitate dalla velocità e dalla larghezza di banda della connessione di rete.

La prima cosa che vorrete fare è capire i requisiti. Se il cliente dice che attualmente hanno bisogno di 10 clienti, quanti clienti avranno bisogno in 5 anni quando si trasferiscono in un locale più grande? Vorrà dover riprogettare completamente il loro sistema POS se / quando ciò accadrà? Vogliono aggiungere altre funzionalità in seguito (come la gestione delle scorte o la generazione di rapporti)?

La seconda cosa che vorrete fare è capire come affrontate la tolleranza d'errore. Se il server si arresta per qualsiasi motivo, vuoi 10+ clienti che sono inutilizzabili e 10 operatori di checkout vengono abusati da acquirenti impazienti? È possibile memorizzare le informazioni sul client finché il server non ritorna online? Hai bisogno di cadere? Come farai i backup (dovrai portare il server offline per fare il backup)?

La terza cosa che vorrete fare è decidere il protocollo che i client useranno per comunicare con il server. Può essere SQL raw (con nient'altro che un database in esecuzione sul server)? Hai bisogno di livelli aggiuntivi nel server?

La quarta cosa che vorrete fare è creare una simulazione / modello di essa. L'idea qui è di determinare se il piano è fattibile (dove sono i colli di bottiglia, la connessione LAN del server deve essere più veloce di quella del client per tenere il passo, quanti client potrebbe gestire, ecc.). Non si vuole avere un team di sviluppatori che lavora per 6 mesi a costruire il software client, e un altro team di sviluppatori che lavora per 6 mesi a costruire il software server; e poi scopri che non può gestire il carico dopo che è troppo tardi.