{"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. In questo momento \u00e8 aperta in OTUS l'iscrizione a un nuovo ciclo del corso \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 informativo. In questa serie di articoli, propongo di analizzare gli stili architettonici pi\u00f9 popolari per la creazione di applicazioni e rispondere alla domanda su quale stile architettonico sia preferibile in ciascun caso. Durante la mia esposizione cercher\u00f2 di elaborare una catena logica che spiega l'evoluzione degli stili architettonici dai monoliti ai microservizi.
\n<\/a><\/noindex><\/p>\n

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

\nSe provi a chiedere ai programmatori: \u00abA cosa servono i microservizi?\u00bb, riceverai le risposte pi\u00f9 varie. Sentirai che i microservizi migliorano la scalabilit\u00e0, semplificano la comprensione del codice, aumentano la resilienza, e a volte si pu\u00f2 sentire che permettono di \u00abripulire il codice\u00bb. Rivolgiamoci alla storia per comprendere quale obiettivo ha guidato l'emergere dei microservizi.<\/p>\n

In breve, i microservizi nella nostra attuale comprensione sono emersi in questo modo: nel 2011, James Lewis, analizzando il lavoro di diverse aziende, ha notato l'emergere di un nuovo modello chiamato \u00abmicro-app\u00bb, che ottimizzava il SOA dal punto di vista del rapido dispiegamento dei servizi. Poco dopo, nel 2012, durante un summit architettonico, il modello \u00e8 stato ribattezzato microservizio. Pertanto, l'obiettivo iniziale dell'implementazione dei microservizi era il miglioramento del time to market<\/b>.<\/p>\n

Nel 2015, i microservizi erano sulla \u00abcresta dell'onda\u00bb. Secondo alcune ricerche, nessuna conferenza si svolgeva senza una relazione sui microservizi. Inoltre, alcune conferenze erano dedicate esclusivamente ai microservizi. Attualmente, molti progetti iniziano utilizzando questo stile architettonico, e se un progetto contiene tonnellate di codice legacy, \u00e8 probabile che si stia effettuando una migrazione attiva verso i microservizi.<\/p>\n

Nonostante quanto detto, solo un numero relativamente ridotto di sviluppatori riesce a definire il concetto di \u00abmicroservizio\u00bb. Ma di questo ne discuteremo pi\u00f9 tardi...<\/p>\n

Monolite<\/h2>\n

\nLo stile architettonico contrapposto ai microservizi \u00e8 il monolite (o \u00abtutto in uno\u00bb). Spiegare cos'\u00e8 un monolite probabilmente non ha senso, quindi elencher\u00f2 subito i difetti di questo stile architettonico che hanno avviato lo sviluppo di altri stili architettonici: dimensioni, coesione, distribuzione, scalabilit\u00e0, affidabilit\u00e0 e rigidit\u00e0. Di seguito propongo di esaminare ciascuno di questi difetti separatamente.<\/p>\n

Dimensione<\/h3>\n

\nIl monolite \u00e8 molto grande. E, di norma, comunica con un database molto grande. L'applicazione diventa troppo grande perch\u00e9 possa essere compresa da un singolo sviluppatore. Solo coloro che hanno trascorso molto tempo con questo codice possono lavorare bene con un monolite, mentre i neofiti passeranno molto tempo a cercare di capire il monolite senza garanzie di successo. Di solito, quando si lavora con un monolite, c'\u00e8 sempre un \u00absenior\u00bb che conosce il monolite abbastanza bene e tiene a bada per un anno o un anno e mezzo gli altri sviluppatori nuovi. \u00c8 evidente che tale senior rappresenta un punto di guasto unico e la sua partenza pu\u00f2 portare alla morte del monolite. <\/p>\n

Coesione<\/h3>\n

\nIl monolite \u00e8 come un \u00abgrande groviglio di fango\u00bb (big ball of mud), in cui le modifiche possono portare a conseguenze imprevedibili. Apportando modifiche in un luogo, si pu\u00f2 danneggiare il monolite in un altro (proprio come nel detto \u00abho grattato l'orecchio e qualcosa \u00e8 andato storto\u00bb). Questo \u00e8 dovuto al fatto che i componenti all'interno del monolite hanno relazioni molto complesse e, soprattutto, poco evidenti.<\/p>\n

Distribuzione<\/h3>\n

\nLa distribuzione del monolite, a causa delle complesse relazioni tra i suoi componenti, \u00e8 un processo lungo con il suo rituale. Questo rituale non \u00e8 solitamente completamente standardizzato e si trasmette \u00abdi bocca in bocca\u00bb. <\/p>\n

Scalabilit\u00e0<\/h3>\n

\nI moduli del monolite possono avere esigenze conflittuali in termini di risorse, il che rende necessario cercare un compromesso dal punto di vista dell'hardware. Immaginate di avere 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 RAM. In questo caso, la macchina su cui viene installato il monolite deve supportare i requisiti di entrambi i servizi, oppure si dovr\u00e0 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 vuoi che ci siano 100 servizi A e 10 servizi B. Anche in questo caso ci sono due opzioni: o distribuiamo 100 monoliti completi, oppure su alcuni di essi dovremo disattivare manualmente i servizi B. <\/p>\n

Affidabilit\u00e0<\/h3>\n

\nPoich\u00e9 tutti i servizi sono insieme, se il monolite fallisce, tutti i servizi cadono contemporaneamente. In realt\u00e0, potrebbe non essere cos\u00ec male, almeno non ci saranno guasti parziali in un sistema distribuito, ma dall'altra parte, a causa di un errore in una funzionalit\u00e0 utilizzata dallo 0,001% degli utenti, potresti perdere tutti gli utenti del tuo sistema. <\/p>\n

Rigidit\u00e0<\/h3>\n

\nA causa delle dimensioni del monolite, \u00e8 difficile passare a nuove tecnologie. Di conseguenza, una delle sfide \u00e8 mantenere quel senior condizionale. Il stack tecnologico scelto all'inizio del progetto pu\u00f2 diventare un blocco, ostacolando lo sviluppo del prodotto. <\/p>\n

Conclusione<\/h2>\n

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

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

\n

Leggi anche:<\/h4>\n

<\/p>\n