{"id":92810,"date":"2020-08-31T07:42:09","date_gmt":"2020-08-31T05:42:09","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1"},"modified":"2020-08-31T07:42:09","modified_gmt":"2020-08-31T05:42:09","slug":"vybor-arhitekturnogo-stilya-chast-1","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/vybor-arhitekturnogo-stilya-chast-1","title":{"rendered":"Scelta dello stile architettonico (parte 1)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Ciao, Habr. Proprio ora, OTUS ha aperto le iscrizioni per un nuovo ciclo di corsi. \u00abSoftware Architect\u00bb<\/a><\/noindex>In vista dell'inizio del corso, voglio condividere con voi il mio articolo originale.<\/i><\/b><\/p>\n

<\/p>\n

Introduzione<\/h2>\n

\nLa scelta dello stile architettonico \u00e8 una delle decisioni tecniche fondamentali nella costruzione di un sistema informatico. In questa serie di articoli, propongo di analizzare gli stili architettonici pi\u00f9 popolari per la costruzione delle applicazioni e rispondere alla domanda su quale stile architettonico sia il pi\u00f9 preferibile in ciascun caso. Nel corso dell'esposizione cercher\u00f2 di tracciare il filo logico che spiega lo sviluppo degli stili architettonici dai monoliti ai microservizi.
\n<\/a><\/noindex><\/p>\n

Un po' di storia<\/h2>\n

\nSe provate a chiedere agli sviluppatori: \u00abA cosa servono i microservizi?\u00bb, otterrete risposte molto diverse. Sentirete che i microservizi migliorano la scalabilit\u00e0, semplificano la comprensione del codice, migliorano la resilienza, a volte si sente dire che permettono di \u00abripulire il codice\u00bb. Rivolgiamoci alla storia per capire quale obiettivo ha perseguito l'emergere dei microservizi.<\/p>\n

In breve, i microservizi, come li intendiamo oggi, sono emersi nel seguente modo: nel 2011, James Lewis, analizzando il lavoro di diverse aziende, ha notato l'emergere di un nuovo paradigma \u00abmicro-app\u00bb, che ha ottimizzato l'SOA in termini di accelerazione del deployment dei servizi. Poco dopo, nel 2012, durante un summit architettonico, il paradigma \u00e8 stato rinominato in microservizio. Pertanto, l'obiettivo iniziale dell'implementazione dei microservizi era il miglioramento del famigerato time to market<\/b>.<\/p>\n

Nel 2015, i microservizi erano sulla cresta dell'onda. Secondo alcune ricerche, nessuna conferenza si svolgeva senza una relazione sui microservizi. In effetti, alcune conferenze erano dedicate esclusivamente ai microservizi. Oggi molti progetti iniziano gi\u00e0 con questo stile architettonico, e se un progetto contiene tonnellate di codice legacy, \u00e8 probabile che stia avvenendo una migrazione attiva verso i microservizi.<\/p>\n

Nonostante quanto sopra, ancora un numero limitato di sviluppatori riesce a definire il concetto di 'microservizio'. Ma di questo parleremo pi\u00f9 avanti...<\/p>\n

Monolite<\/h2>\n

\nLo stile architettonico opposto a quello dei microservizi \u00e8 il monolite (o 'tutto in uno'). Non ha molto senso spiegare cos'\u00e8 un monolite, quindi proceder\u00f2 immediatamente a elencare gli svantaggi di questo stile architettonico che hanno portato allo sviluppo di stili architettonici alternativi: dimensione, interdipendenza, distribuzione, scalabilit\u00e0, affidabilit\u00e0 e rigidit\u00e0. Di seguito, propongo di esaminare ciascuno di questi svantaggi separatamente.<\/p>\n

Dimension<\/h3>\n

\nIl monolite \u00e8 molto grande. Comunica generalmente con un'ampia base di dati. L'applicazione diventa cos\u00ec complessa che \u00e8 difficile da comprendere per un singolo sviluppatore. Solo coloro che hanno trascorso molto tempo a lavorare su questo codice possono gestire bene il monolite, mentre i neofiti possono impiegare molto tempo nel tentativo di capirlo, senza la certezza di riuscirci. Di solito, c'\u00e8 sempre un 'senior' condizionale che conosce abbastanza bene il monolite e corregge i nuovi sviluppatori per un anno o anche pi\u00f9. Ovviamente, un tale senior rappresenta un singolo punto di fallimento, e la sua partenza pu\u00f2 portare alla rovina del monolite. <\/p>\n

Coesione<\/h3>\n

\nIl monolite \u00e8 descritto come un 'grande gomitolo di fango' (big ball of mud), e apportare modifiche in esso pu\u00f2 avere conseguenze imprevedibili. Cambiando una parte, si potrebbero rovinare altre aree del monolite (si tratta di 'grattarsi un orecchio e far cadere il resto'). Questo \u00e8 dovuto al fatto che i componenti nel monolite hanno relazioni molto complesse e, soprattutto, non ovvie.<\/p>\n

Distribuzione<\/h3>\n

\nIl deployment di un monolite, a causa delle complesse interconnessioni tra i suoi componenti, \u00e8 un processo lungo con il suo rituale. Questo rituale di solito non \u00e8 standardizzato in modo definitivo e viene trasmesso \"da bocca a bocca\". <\/p>\n

Scalabilit\u00e0<\/h3>\n

\nI moduli del monolite possono avere esigenze di risorse in conflitto, il che richiede di cercare un compromesso in termini di hardware. Immaginate un monolite composto dai servizi A e B. Il servizio A \u00e8 esigente in termini di spazio su disco, mentre il servizio B lo \u00e8 in termini di memoria. In questo caso, o la macchina su cui viene installato il monolite deve soddisfare i requisiti di entrambi i servizi, oppure sar\u00e0 necessario disattivare manualmente uno dei servizi.<\/p>\n

Un altro esempio (pi\u00f9 classico): il servizio A \u00e8 molto pi\u00f9 popolare del servizio B, quindi volete avere 100 istanze del servizio A e 10 del servizio B. Anche qui ci sono due opzioni: o deployiamo 100 monoliti completi, oppure su alcuni di essi sar\u00e0 necessario disattivare manualmente i servizi B. <\/p>\n

Affidabilit\u00e0<\/h3>\n

\nPoich\u00e9 tutti i servizi sono integrati, se il monolite fallisce, falliscono tutti i servizi contemporaneamente. In realt\u00e0, forse non \u00e8 cos\u00ec male; almeno non ci saranno guasti parziali in un sistema distribuito. D'altra parte, a causa di un errore in una funzionalit\u00e0 utilizzata dallo 0,001% degli utenti, puoi perdere tutti gli utenti del tuo sistema. <\/p>\n

Rigidit\u00e0<\/h3>\n

\nA causa delle dimensioni del monolite, \u00e8 difficile adottare nuove tecnologie. Di conseguenza, diventa una sfida mantenere quello che potremmo definire il senior. La stack tecnologica scelta all'inizio del progetto pu\u00f2 diventare un ostacolo allo sviluppo del prodotto. <\/p>\n

Conclusione<\/h2>\n

\nLa prossima volta parleremo di come le persone hanno tentato di risolvere i problemi evidenziati passando a componenti e SOA.<\/p>\n

\"Scelta<\/a><\/noindex><\/p>\n

\n

Leggi di pi\u00f9:<\/h4>\n

<\/p>\n