Sto notando un sacco di progetti (DropWizard, Grails, ecc.) Che iniziano ad abbracciare la nozione di un JAR "grasso" (utilizzando un server Web incorporato come Jetty o Tomcat) rispetto alla tradizionale distribuzione di WAR. Entrambi i metodi implicano un singolo processo JVM (ad esempio, indipendentemente dal numero di WAR distribuiti su Tomcat, è lo stesso processo JVM).Distribuire WAR o "JAR grasso"?
In quali circostanze è preferibile l'altro metodo di implementazione rispetto all'altro?
I WAR-to-Tomcat tradizionali vanno bene per le app interne (utilizzate da utenti interni/dipendenti) che in realtà non hanno esigenze di gestione di ridimensionamento/configurazione. Nel momento in cui hai un componente (app web o REST, ecc.) Che deve essere pubblico, devi ridimensionare quel componente alla sua velocità e devi (beh, * dovrebbe *) automatizzare la configurazione dei nodi quel componente sopravvive (vedi Ansible/Chef/Puppet/Salt/etc.).Scalabilità e automazione CM sono quasi impossibili da realizzare su nodi eterogenei che contengono diverse combinazioni di file WAR ... – smeeb
... ad esempio: se si hanno 10 nodi Tomcat e 30 file WAR (che rappresentano 30 diversi componenti), allora per ottenere CM automatizzati è necessario definire * tipi * di nodi (nodo DB, nodo app, nodo Microservice, nodo cache, ecc.) e distribuire lo stesso sottoinsieme dei 30 componenti per ogni tipo di nodo. Ma poi avrai problemi di ridimensionamento, perché inevitabilmente i componenti condivisi su ciascuna istanza di Tomcat avranno requisiti di ridimensionamento diversi. Quindi si riduce a: cosa stai distribuendo e quali sono i suoi requisiti? – smeeb
Componenteria interna va bene come WAR-to-Tomcat. La componentistica della scala Web ha bisogno di omogeneità, e questo può essere solo ** pulito ** compiuto con questi cosiddetti JAR grassi. – smeeb