Perché Java EE è scalabile?

Ho sentito da varie fonti che Java EE è altamente scalabile, ma a me sembra che non si possa mai scalare un’applicazione Java EE al livello del motore di ricerca di Google o di qualsiasi altro sito web di grandi dimensioni.

Mi piacerebbe sentire i motivi tecnici per cui è così scalabile.

Java EE è considerato scalabile perché se si considera l’architettura EJB ed è eseguito su un server delle applicazioni appropriato, include funzionalità per il cluster trasparente e consente l’utilizzo di più istanze dell’EJB per soddisfare le richieste.

Se hai gestito le cose manualmente in plain-old-java, dovresti capire tutto da solo, ad esempio aprendo le porte, sincronizzando gli stati, ecc.

Non sono sicuro che potresti definire Google un “sito web di grandi dimensioni”. Sarebbe come paragonare Internet alla LAN dell’ufficio. Java EE non è stato concepito per scalare a livello globale, motivo per cui siti come Amazon e Google utilizzano le proprie tecnologie (ad esempio, con l’uso di MapReduce).

Ci sono molti articoli che discutono dell’efficienza della scalabilità di Java EE. Ad esempio questo

Ciò che rende scalabile Java EE è ciò che rende tutto più scalabile: la separazione delle preoccupazioni. A mano a mano che le esigenze di elaborazione o di I / O aumentano, puoi aggiungere nuovo hardware e ridistribuire il carico in modo semitrasparente (per lo più trasparente per l’app, ovviamente meno per le scimmie di configurazione) perché i problemi isolati e separati non sanno o non importano se sono ” ri sullo stesso hardware fisico o su diversi processori in un cluster.

È ansible rendere le applicazioni scalabili in qualsiasi lingua o piattaforma di esecuzione. (Sì, anche COBOL su antichi mainframe di System 370). Quali framework applicativi come Java EE (e altri, naturalmente – Java EE è praticamente unico in questo senso!) Ti danno la possibilità di fare (relativamente parlando) facilmente facendo ciò molto del pesante sollevamento per te.

Quando la mia app Web utilizza, ad esempio, un bean per eseguire alcune logiche di business, tale bean può trovarsi sullo stesso core della CPU, su un core diverso nella stessa CPU, su una CPU diversa interamente o, in casi estremi, forse anche attraverso il pianeta. Non lo so e, per la maggior parte, purché lo spettacolo sia lì, non mi interessa. Allo stesso modo, quando invio un messaggio sul bus dei messaggi per essere gestito, non so né mi interessa dove va quel messaggio, quale componente esegue l’elaborazione e dove si svolge tale elaborazione, sempre finché la performance rientra nel mio esigenze. Questo è tutto per le scimmie di configurazione. La tecnologia consente questo e gli strumenti sono in atto per valutare quali pezzi devono andare dove ottenere prestazioni accettabili mentre il sistema si dimensiona.

Ora, quando provo a consegnare tutto questo, parto subito dai problemi. Se non penso a tutto il proxy, la programmazione e la distribuzione e così in anticipo, quando la mia app si espande oltre i limiti della gestione di una singola macchina, ora ho delle grosse riscritture mentre sposto alcune delle applicazioni in un’altra casella. E poi ogni volta che le mie capacità crescono devo farlo ancora e ancora.

Se penso a tutto questo in anticipo, sto scrivendo un bel po ‘di codice per ogni applicazione che fa piccole variazioni di tutte le stesse cose. Posso codificare le cose in modo scalabile, ma voglio farlo ogni volta. dannato. tempo. Scrivo un’app?

Quindi, ciò che Java EE (e altri framework) portano in tavola è il boilerplate pre-scritto per i requisiti comuni di rendere le applicazioni scalabili. Scrivere le mie app non garantisce che sarebbero scalabili, ma i framework rendono la scrittura di queste app scalabili molto più semplice.

Si potrebbe guardare ad un’architettura scalabile dal punto di vista di ciò che fornisce il framework di base (come Java EE). Ma questo è solo l’inizio.

Progettare per un’infrastruttura scalabile è un’arte architettonica. È come l’arte della proiezione … come si comporterà quando esploderà in modo reale. Le domande di base sono:

  • Dove tengo le cose a cui si accede frequentemente in modo che quando così tante persone lo chiedono, non devo farlo per così tanto tempo (cache)?
  • Dove tengo le cose di ogni individuo in modo che quando ci sono così tante persone che hanno bisogno di roba conservata, non avrò problemi a gestirle tutte.
  • Come ricordo cosa ha fatto una persona qui l’ultima volta che sono venuti qui, dal momento che potrebbero non tornare allo stesso nodo particolare che hanno visitato l’ultima volta.
  • Per quanto tempo dovrò aspettare (bloccare) una procedura di lunga durata se così tante persone lo richiedono?

… quel genere di cose va oltre ciò che un framework può avvolgere. In altre parole, il framework potrebbe essere scalabile ma il prodotto è cablato troppo stretto per essere scalato.

Java EE, come framework è abbastanza scalabile, come la maggior parte dei moderni framework aziendali basati su microprocessori. Ma ho visto cose straordinarie (non in senso buono) costruite anche dal meglio di loro.

Per una pletora di riferimenti, cerca su Google “Progettazione per la scalabilità”

La cosa della “scalabilità” parla di “cosa farai quando la tua applicazione non si adatta più a un singolo computer?”.

Le applicazioni scalabili possono crescere su più computer di uno.

Nota che i server di grandi dimensioni possono avere applicazioni MOLTO grandi con molta memoria e molte CPU – vedi http://www.sun.com/servers/highend/m9000/ o http://www-03.ibm.com/systems/ i / hardware / 595 / index.html – ma di solito è più costoso che avere molti piccoli server con l’applicazione che si diffonde su di essi.