Architettura micro vs server monolitico

Attualmente stiamo lavorando al nostro nuovo prodotto / progetto, è un'applicazione client-server diretta verso determinate imprese industriali / di servizi specifici. Stiamo costruendo un server (solo linguaggio C e Linux) che esegue un protocollo personalizzato su TCP con un front-end Java. Siamo impegnati nel lavoro di codifica per circa il 20% e ci troviamo di fronte a una situazione che deve scegliere tra Micro o Monolitico Kernel Architecture.

Sono consapevole che Micro vs. Monolitico di solito è in relazione con l'architettura del kernel, ma stiamo parlando in particolare di server.

Perché un server personalizzato e non qualcosa esistente?

• Le esigenze dell'interfaccia utente sono significative e molto dinamiche, pertanto le soluzioni basate su browser Web / Web non erano appropriate.
• L'elaborazione statistica è significativa sul lato client e quindi, ancora una volta, i browser sono stati di scarso aiuto. (Ovviamente, potremmo eseguire l'elaborazione a livello del server e trasmettere i dati elaborati al client, ma ciò implicherebbe molto carico sul server e spreco di risorse del client).
• Inoltre, con almeno tre tecnologie (JS / HTML / CSS) per gestire anche un singolo evento rende l'intera esperienza come spazzare la casa nel mezzo di una tempesta nel deserto - la spazzate n-volte, la polvere si accumula n + 1 volte.

Che dire del server micro e monolitico? Di cosa stai parlando?

Considera la seguente (ipotetica) richiesta del cliente:

request-id: 123
request-service: HistoricDataSets
request-message: Fetch all records upto the year 2010

Quando si riceve tale richiesta, in genere un server (ignoriamo le tecniche di concorrenza come thread e forchette per semplicità):

• Analizzare la stringa di richiesta
• Identifica l'azione (Recupera HistoricDataSets LIMIT Year (2010)nel nostro caso)
• Interagisci con il livello di persistenza (Oracle, diciamo, nel nostro esempio) e recupera i dati.

• Formattare i dati secondo il protocollo. Ex:

  id risposta: 123
  esito positivo:
  testo risposta vero : DataSet

• Rispondere al client con i dati così formattati.

Questo è ciò che chiamiamo un server monolitico (simile a un kernel monolitico in cui tutte le operazioni del sistema operativo vengono eseguite nello spazio del kernel).

Considera di nuovo la stessa richiesta, al ricevimento, questa volta il server (abbiamo assunto solo memoria condivisa come IPC, sempre per semplicità):

• Mette la richiesta nella memoria condivisa per il Parserprocesso
• Il Parseranalizza la stringa, identifica il compito e dirige il Executionerprocesso di eseguire i compiti.
• L' Executionerpoi passa i dati al Fomatterprocesso che, dopo la formattazione dei dati in una stringa di protocollo, torna al server.
• Il server lo invia al client (risposta).

Naturalmente, invece di Parser, Executionere Formatteravrebbe potuto essere un processo unico ma separato. Questo è ciò che chiamiamo Micro Server (simile a un micro kernel che fa appena il minimo necessario). Il server effettivamente ascolta e risponde solo mentre tutti i passaggi sono gestiti da diversi processi.

Quale scegliere? Siamo confusi! Mentre i server monolitici sono provati e testati (la maggior parte dei server Web HTTP?) E più facili da programmare e in grado di gestire la concorrenza abbastanza bene. I micro server, prima facie, sembrano rapidi e in linea con il principio UNIX di un programma per svolgere un compito, ma sono anche complicati da sviluppare, esp. tenendo presente la concorrenza.

Domande
: quali sono (forse potrebbero essere) i pro ei contro di ogni approccio?
- Quando usare quale? (Potrebbe anche essere interpretato come una domanda generale: quando usare IPC?)
- Se viene scelto Micro kernel, quali funzioni devono essere parte del core-server e cosa no?

Domande simili / correlate

• Pericoli di enorme applicazione monolitica
• Browser incorporato Vs esterno (tangenziale)
• Consigli per convertire l'app monolitica in multithread (tangenziale)

• I nostri potenziali clienti possono essere suddivisi in due categorie:
  • Grande: circa 1.700 - 2.000 richieste al minuto
  • Piccolo: circa 650 - 700 richieste al minuto
• Si può presumere che il volume di dati per ciclo di richiesta (richiesta e la risposta successiva) sia normalmente distribuito con una media di ~ 1,20 MB e nel caso peggiore circa 250-300 MB.
• Il concetto di prodotto è relativamente nuovo ma ha la capacità di influire sulle operazioni principali, quindi prevediamo che i budget dei clienti siano flessibili solo dopo un certo ritardo (9-12 mesi) dopo l'implementazione, questo limita la quantità di hardware che il cliente sarà disposto impegnare esp. quelli piccoli.
• Ogni cliente avrà il proprio stack client-server. Il server verrà eseguito sull'hardware del cliente gestito dal team del cliente, mentre i client verranno distribuiti sulle macchine degli impiegati funzionali
• Gli aggiornamenti remoti sia per l'applicazione client che per quella server sono indispensabili
• I PUSHservizi in tempo reale da parte del server possono essere "altamente" desiderati se il prodotto fa clic!

L'economia a volte regola una risposta molto più critica della teoria di base dietro le scelte. La cosa più importante è che se stai osservando qualcosa di "vasto" nel tuo caso, in cui l'applicazione ha bisogno di una distribuzione davvero dura - minore è il numero di ruote che ti inventi, migliore è. Se funziona, non mi importa se è monolitico o micro; in caso contrario, non me ne importerebbe neanche io!

Può essere vero che le app basate su pagine Web molto convenzionali potrebbero non fare per te, ma devi dare un'occhiata un po 'più ampia e vedere che puoi usare le cose pronte per andare e in seguito evolvere la tua via d'uscita per vedere se puoi sostituire quell'elemento con qualcosa meglio. In questo modo, non solo risparmierai tempo per la prima cosa, ma migliorerai anche la tua comprensione di ciò che conta davvero nella vita reale. Ecco alcuni suggerimenti che potresti prendere in considerazione.

1. Se hai davvero bisogno di una scalabilità molto elevata, considera come i tuoi server divideranno l'attività piuttosto che sfornare i numeri il più velocemente possibile. Alla fine, avrai un carico che un server non può davvero sopportare anche se Intel rende il processore più veloce del mondo e il cliente è pronto a pagare! Pertanto, il routing delle richieste e il bilanciamento del carico sono più importanti dell'efficienza del protocollo stesso.

2. HTTP è ancora il migliore, se è necessario ridimensionare. (Puoi anche acquistare facilmente i bilanciatori di carico se lo usi). Il protocollo personalizzato richiede accordi personalizzati.

3. HTTP non significa che devi girare HTML, java script. Non significa nemmeno che devi avere un server apache e un browser web regolari. È possibile utilizzare HTTP tra due client personalizzati ed elementi come server AOL o lighthttpd che possono essere utilizzati come libreria se la comunicazione non è un trasferimento di dati enorme. Puoi anche usare SOAP su entrambi i lati con kit di strumenti come gSOAP .

4. Anche se HTTP sicuramente non si adatta al conto, prendi in considerazione qualcosa come BEEP , che ti aiuta a rendere le cose più efficienti. In alternativa, esistono molti meccanismi RPC e RMI comprovati.

5. Prova a vedere che puoi fare il massimo lavoro di più eseguendo l'elaborazione parallela nel back-end e i server vengono interrogati solo quando il lavoro è finito. Se funziona, ci sono framework come MPI o ci sono molti altri kit di strumenti di calcolo distribuiti che possono essere di aiuto.

6. Infine, mentre potrei non essere in grado di conoscere le esigenze esatte, ma potresti aver bisogno di distribuire molti dati o fare molti calcoli, se hai bisogno di entrambi - ci sono ancora alcune inefficienze architettoniche fondamentali.

Per me, la creazione di un nuovo protocollo e la creazione di un nuovo framework di server è un doppio esperimento che non si dovrebbe fare insieme. Se la tua posta in gioco è così alta, prima dovresti effettivamente provare a sperimentare gli strumenti esistenti per vedere i limiti di ciò che è stato fatto finora - solo allora conoscerai le vere sfide.

Nella ricerca di sistemi distribuiti è stato realizzato molto di più delle semplici app Web. Quindi dovresti ricercarlo.

Dipan.

Questo mi sembra molto accademico. E francamente, trovo che il secondo approccio sia altrettanto monolitico. Questo è quanto dovresti andare:

1. Analizza la richiesta
2. Gestisci la richiesta

Il gestore della richiesta scelto in base ai parametri della richiesta dovrebbe incapsulare tutti gli aspetti della gestione della richiesta. Il fatto che il gestore esegua effettivamente query sull'archivio dati e che utilizzi o meno la formattazione standard per restituire i dati è irrilevante dal livello precedente. È un dato di fatto, probabilmente farà proprio questo, ma non ha alcun valore nel fare ipotesi al riguardo.

1. Il kernel monolitico è molto più vecchio di Microkernel . È usato in Unix. mentre Idea of ​​microkernel è apparso alla fine degli anni '80 .

2. l'esempio di os con i kernel monolitici sono UNIX, LINUX mentre i os con Microkernel sono QNX, L4, HURD , inizialmente Mach (non mac os x) successivamente verrà convertito in kernel ibrido, anche MINIX non è un kernel puro perché i driver di dispositivo sono compilato come parte del kernel.

3. Il kernel monolitico è più veloce del microkernel . mentre il primo microkernel Mach è più lento del 50% rispetto al kernel monolitico mentre la versione successiva come L4 è solo del 2% o 4% più lenta rispetto al kernel monolitico .

4. Il kernel monolitico è generalmente voluminoso . mentre il kernel monolitico puro deve essere di dimensioni ridotte anche adattarsi a s nella cache di primo livello del processore (microkernel di prima generazione).

5. nel kernel del dispositivo monolitico il driver del dispositivo risiede nello spazio del kernel . mentre nel driver di dispositivo Microkernel risiede nello spazio utente .

6. poiché il driver del dispositivo risiede nello spazio del kernel, rende il kernel monolitico meno sicuro del microkernel. (Il fallimento del driver può portare a crash) mentre i Microkernel sono più sicuri del kernel monolitico quindi utilizzato in alcuni dispositivi militari.

7. I kernel monolitici usano segnali e socket per garantire IPC mentre l'approccio microkernel utilizza le code dei messaggi . 1 gen di microkernel ha implementato male l'IPC, quindi i cambi di contesto sono lenti.

8. aggiungere nuove funzionalità a un sistema monolitico significa ricompilare l'intero kernel mentre è possibile aggiungere nuove funzionalità o patch senza ricompilare .