Io attualmente mi sono buttato su JHipster che genera ovviamente tutti i miei microservizi con spring boot. Devo dire che mi trovo da dio. Mi permette di concentrarmi sulle esigenze di business piuttosto che su tutto ciò che c’è intorno ( centralizzazione log, controllo accessi integrazione Kafka è molto altro ). Abbiamo fatto anche qualche verifica con jprofiler e mi pare un buon compromesso tra memoria e risparmio in termini di tempo per l’avvio di un servizio.
Vi pongo però un quesito che vorrei condividere con voi. In un microservizio che si dovrà occupare principalmente di gestire l’anagrafe generale di un ERP quindi operazioni CRUD ed altre funzionalità come attivazione blocco ecc di un soggetto anagrafico, contando anche l’integrazione con Kafka, quanta memoria pensate sia necessaria contando che le anagrafiche da gestire si aggirano intorno a 200/300k ? Mi sono affacciato da poco alla questione e mi piacerebbe avere un vostro parere. Ovviamente l’intera infrastruttura di servizi girerà su docker :-) quindi dovrei considerare che ogni container occupare un po’ di memoria per conto suo più quella del l’app Il giorno mar 6 nov 2018 alle 19:48 Uberto Barbini [email protected] [it-torino-java-jug] <[email protected]> ha scritto: > > > > > On Tue, 6 Nov 2018 at 15:11, Federico Fissore [email protected] > [it-torino-java-jug] <[email protected]> wrote: > >> >> >> Uberto Barbini [email protected] [it-torino-java-jug] ha scritto il >> 06/11/18 alle 10:46: >> > >> > >> > se parliamo di web server: sparkjava o http4k o scalatra (a seconda del >> > linguaggio) >> >> Grazie per questi nomi: l'approccio node.js nell'associare URL -> >> Handler mi è sempre piaciuto >> > > http4k va molto oltre, guardalo :) > >> >> > >> > btw finalmente lavoro in un team che condivide la mia irritazione con i >> > vari logger Singleton e usiamo domain events. >> > >> >> cosa intendi? emettete eventi invece di loggare? come li consultate? >> >> si eventi con payload serializzati in json che poi finiscono su kibana, > ma potrebbero anche finire su un file locale. > > Il punto e' che invece di avere loggerXY esiste un monitor che chi vuole > loggare qualcosa deve farsi "prestare" (no DI automatico) e ognuno > definisce gli eventi con i loro campi. > E' un modo incredibilmente produttivo, sia per chi scrive codice che per > chi deve cercare i bugs che evita tonnellate di logs inutili. > > Uberto > >> > -- Response to : [email protected]
