Soluzione server centralizzata rispetto a una soluzione centralizzata

2

Al lavoro, stiamo discutendo di due modelli di sistema:

Il primo con un server centralizzato:

Secondounosenzaunservercentralizzato:

L'obiettivo del sistema è di consentire ai client di accedere alle informazioni, tramite browser, servite da alcuni Raspberry-pis remoti che saranno connessi con diversi tipi di sensori.

Come mostrano le immagini, nel primo caso ci sarà un server che lavora come middleware (Node + Express, ad esempio) per gestire le richieste dei clienti e ottenere / settare correttamente le informazioni dai sensori (comunicazione socket) che desiderano ispezionare . Nel secondo caso, anche i raspberry-pis funzioneranno come server Web, consentendo ai client di connettersi direttamente ai sensori che desiderano.

Quindi ecco quello che penso : il primo caso è il modo predefinito di come i sistemi web sono generalmente costruiti. Il secondo caso, dal mio punto di vista, è un modo strano per rendere questo processo di comunicazione molto problematico.

Ciò che voglio con questa domanda è di sollevare alcuni aspetti positivi e negativi da ciascun caso.

Ecco cosa ho già sollevato, per favore correggimi se ho detto qualcosa di sbagliato.

  • Deploy . Nel primo caso è facile dare manutenzione / implementazione al codice del server centrale, poiché c'è solo un posto per farlo, nel secondo caso, dovrei cambiare ogni raspberry-pi nella rete. Per evitare questo difficile compito, potrei creare una distribuzione automatica che farebbe questo per me per ogni raspberry-pi. Al di là del duro lavoro, ci sarebbero ulteriori problemi nel fare questo?
  • Monitoraggio . Nel primo caso, tenere traccia di raspberry-pis è facile dato che, per quanto si collegano, riempirebbero un elenco di dispositivi connessi, allora i clienti sarebbero in grado di vedere quale sensore si desidera ispezionare in questa lista. Nel secondo caso, sarebbe più complesso da trovare tutti i lamponi perché non c'è un posto dove archiviare un elenco di quelli connessi. Tutti i lamponi dovranno avere una lista di tutti dispositivi collegati (molte informazioni ripetute) e questo elenco sempre necessario essere coerenti in tutti i dispositivi. I clienti devono essere in grado per connettersi ad altri Raspberry-pis semplicemente collegandoti ad uno solo. Per evitare CORS in questo caso, i lamponi devono intercomunicarsi. io Non so se questa intercomunicazione è bella, ma forse questo può essere più veloce del caso del server centralizzato, poiché le informazioni possono accedere direttamente: raspbarry-pi a raspberry-pi.
  • Velocità . In teoria, la comunicazione diretta a lampone-pis nel secondo caso è più veloce del primo caso. Ma a causa dell'hardware limitazioni, penso che il secondo caso possa facilmente sovraccaricare qualsiasi raspberry-pi. L'applicazione potrebbe richiedere lo streaming di dati o un più veloce processo di invio del pacchetto.
  • Autenticazione e sicurezza . Nel secondo caso, sarebbe un inferno. Diffondi i token, ad esempio, lungo tutta la necessità dei client di lampone-pis accedere sarebbe molto difficile da implementare.

(Per favore dimmi se non ero chiaro su nulla)

    
posta João Paulo 20.08.2017 - 01:07
fonte

1 risposta

2

Primi pensieri

Configurazione e monitoraggio della rete:

Nell'approccio decentralizzato, è necessario un protocollo di individuazione per garantire che i dispositivi si conoscano e organizzino la comunicazione (ad esempio il routing di comandi e query attraverso la mesh, l'archiviazione di informazioni replicate, ecc ...).

Ciò include la scoperta di nuovi dispositivi, ma anche la gestione dei dispositivi che scompaiono (errore o rimozione) e il lease DHCP scaduto (ovvero i dispositivi che ottengono un nuovo indirizzo IP). E include la gestione dei confini della rete: cercherai i dispositivi vicini attraverso la rete mondiale dell'azienda? o solo nella sottorete locale?

Distribuisci:

Nell'approccio decentralizzato è necessario propagare gli aggiornamenti da dispositivo a dispositivo. Il problema principale qui è la sicurezza: un dispositivo rogue potrebbe compromettere la tua piena rete di sensori. In genere ciò richiederebbe la firma di aggiornamenti e la gestione di certificati accettabili. Sono richieste competenze avanzate in comunicazione sicura.

Performance:

L'approccio decentralizzato presuppone un'attenta ingegnerizzazione del livello di comunicazione sopra menzionato. Se per ogni query utente su qualsiasi dispositivo, ogni sensore inizia a interrogare tutti gli altri, sarà un disastro e un rischio di congestione della rete se si dispone di molti dispositivi.

Sicurezza e autenticazione:

Sì, nell'approccio decentralizzato questo sarà un argomento difficile: ogni utente autorizzato può accedere a qualsiasi dispositivo? O i diritti di accesso sono diversi per sottogruppi di dispositivi diversi?

Un approccio potrebbe essere quello di replicare le modifiche alle autorizzazioni degli utenti attraverso tutti i nodi rilevanti. Un altro approccio potrebbe utilizzare token JWT gestiti da un'autorità attendibile (ad esempio, il controllo dell'accesso potrebbe essere decentrato su ciascun dispositivo, ma l'accesso dell'utente è gestito da un servizio centralizzato che non è necessariamente correlato ai dispositivi).

Altri pensieri

Complessità

L'approccio decentralizzato è di elevata complessità.

E limiterà l'evoluzione futura. Se domani scoprirai che i tuoi sensori devono comunicare con un nuovo tipo di dispositivi, avresti bisogno di organizzare anche scambi decentralizzati con questi dispositivi. N tipo di dispositivi potrebbe significare fino a N! estensioni ai tuoi protocolli e alle tue applicazioni.

La mia impressione personale è che è molta complessità che mette in pericolo la futura sostenibilità della tua architettura.

Gestione eventi complessa

La soluzione decentrata ha anche i suoi limiti. In un ambiente aziendale, potresti essere in grado di monitorare automaticamente i dati del sensore (big data?) E organizzare alcuni elaborazione di eventi complessi oltre l'ambito del sensore (ad esempio se la temperatura del sensore aumenta oltre il normale, e diversi sensori vicini mostrano la stessa tendenza, potrebbe essere l'inizio di un incendio e una notifica ai guardiani deve essere inviata).

Approccio stratificato

La centralizzazione può anche essere prevista a strati. Un approccio potrebbe essere quello di avere un gateway centralizzato per il sensore (diversi gateway se ci sono molti sensori): questo potrebbe semplificare notevolmente il livello di comunicazione e l'amministrazione. Consiglierei questa pratica.

A livello di applicazione, avresti comunque la libertà di decidere se centralizzare i dati o se preferisci inoltrare le query a un sensore specifico. Non conoscendo il tuo dominio di applicazione, è difficile indovinare cosa potrebbe essere il migliore.

Un approccio collaudato e scalabile consiste nell'organizzare un'architettura di editore / sottoscrittore, ad esempio con Kafka . L'approccio è di inoltrare le informazioni del dispositivo a un broker, che lo invia a tutti i sistemi o applicazioni che sono interessati. E questo eviterebbe di perdere informazioni storiche se pertinenti.

    
risposta data 20.08.2017 - 19:32
fonte

Leggi altre domande sui tag