Architettura software e design dei sistemi: quadro generale e guida alle risorse

Salve, colleghi.

Oggi vi proponiamo la traduzione di un articolo di Tugberk Ugurlu, il quale si è preso la responsabilità di esporre in modo relativamente conciso i principi di progettazione dei moderni sistemi software. Ecco cosa riferisce l'autore di sé nel suo essenziale.

Architettura software e design dei sistemi: quadro generale e guida alle risorse
Poiché è decisamente impossibile coprire in un articolo così vasto un tema colossale come i pattern architettonici + i pattern di progettazione aggiornati al 2019, raccomandiamo non solo il testo del signor Ugurlu, ma anche i numerosi link che ha gentilmente fornito. Se vi piace, pubblicheremo anche un testo più specializzato sulla progettazione di sistemi distribuiti.

Architettura software e design dei sistemi: quadro generale e guida alle risorse

Immagine di Isaac Smith dal sito Unsplash

Se non vi siete mai trovati ad affrontare sfide come la progettazione di un sistema software da zero, all'inizio di un lavoro del genere non è chiaro da dove cominciare. Ritengo sia necessario delineare i confini, per avere un'idea più o meno chiara di cosa si intende progettare, e poi rimboccarsi le maniche e lavorare senza uscire da questi limiti. Come punto di partenza, si potrebbe prendere un prodotto o un servizio (idealmente, uno che vi piace molto) e approfondire la sua realizzazione. Potreste restare stupiti da quanto possa sembrare semplice quel prodotto e dalla grande complessità che vi si cela. Non dimenticate: il semplice è spesso complesso, e questo è normale.

Credo che il miglior consiglio che posso dare a chi inizia a progettare un sistema sia: non ammettere alcuna supposizione! Fin dall'inizio è necessario concretizzare i fatti noti su questo sistema e le aspettative correlate. Ecco alcune buone domande, le cui risposte vi aiuteranno ad avviare la progettazione:

  • Qual è il problema che stiamo cercando di risolvere?
  • Qual è il numero massimo di utenti che interagiranno con il nostro sistema?
  • Quali pattern di scrittura e lettura dei dati utilizzeremo?
  • Quali sono i casi di errore previsti e come intendiamo affrontarli?
  • Quali sono le aspettative riguardo alla coerenza e alla disponibilità del sistema?
  • Dobbiamo prendere in considerazione requisiti legati a verifiche esterne e regolamentazioni durante il lavoro?
  • Quali tipi di dati riservati intendiamo conservare?

Queste sono solo alcune domande che sono state utili sia per me che per i team con cui ho avuto il piacere di lavorare nel corso della mia carriera professionale. Se conosci le risposte a queste domande (e a tutte le altre pertinenti al contesto in cui lavori), puoi iniziare a addentrarti nei dettagli tecnici del compito.

Impostiamo il livello iniziale

Cosa intendo qui per «livello iniziale» (baseline)? In effetti, ai nostri tempi, la maggior parte dei problemi nel settore del software «può» essere risolta utilizzando metodi e tecnologie già esistenti. Pertanto, orientandoti in questo panorama, ottieni un vantaggio quando affronti compiti che qualcuno ha già risolto prima di te. Non dimentichiamo che i programmi vengono scritti per risolvere i problemi delle aziende e degli utenti, quindi cerchiamo di affrontare il compito nel modo più diretto e semplice (dal punto di vista dell'utente) possibile. Perché è importante ricordarlo? Forse nella tua personale sistematica ti piace cercare soluzioni uniche per ogni problema, poiché pensi: «che tipo di programmatore sarei se seguisco sempre schemi»? In realtà, l'arte sta nel prendere decisioni su dove e cosa fare. Ovviamente, ognuno di noi di tanto in tanto deve affrontare problemi unici, ognuno dei quali rappresenta una vera sfida. Tuttavia, se il nostro livello iniziale è chiaramente definito, sappiamo su cosa concentrare le nostre energie: cercare soluzioni già pronte per il compito che ci è stato assegnato o approfondire la questione per una comprensione più profonda.

Penso di averti convinto che, se uno specialista ha una buona comprensione di quale sia la componente architettonica di alcuni eccellenti sistemi software, tali conoscenze saranno essenziali per padroneggiare l'arte dell'architetto e costruire una solida base in questo campo.

Bene, da dove iniziamo? Su Donna Martin ha un repository su GitHub chiamato system-design-primer, grazie al quale potrai imparare a progettare sistemi su larga scala e prepararti a colloqui su questo tema. Nel repository c'è una sezione con esempi di architetture reali, dove, in particolare, si discute di come progettano i loro sistemi alcune aziende ben note, ad esempio, Twitter, Uber, ecc.

Tuttavia, prima di passare a questo materiale, approfondiamo le sfide architettoniche più importanti che si devono affrontare nella pratica. Questo è importante perché è necessario specificare MOLTI aspetti di un problema complesso e multifaceted, e poi risolverlo nel contesto della regolamentazione vigente in questo sistema. Jackson Gabbard, ex dipendente di Facebook, ha registrato un video di 50 minuti sugli colloqui relativi alla progettazione dei sistemi, dove ha condiviso la sua esperienza nella valutazione di centinaia di candidati. Anche se il video riguarda specificamente la progettazione di grandi sistemi e i criteri di successo, importanti nella selezione di un candidato per tale posizione, rimane una risorsa completa su quali siano le cose più importanti nella progettazione dei sistemi. Propongo anche un riassunto di questo video.

Acquisisci conoscenze sulla memorizzazione e recupero dei dati

Di norma, la tua decisione su come memorizzare e fornire i tuoi dati a lungo termine influisce in modo critico sulle prestazioni del sistema. Pertanto, devi prima di tutto comprendere le caratteristiche attese di scrittura e lettura dei dati nel tuo sistema. Successivamente, è necessario essere in grado di valutare questi parametri e fare una scelta basata sulle valutazioni effettuate. Tuttavia, per gestire efficacemente questo compito, sarà indispensabile avere familiarità con i modelli di memorizzazione dei dati esistenti. Di fatto, questo implica avere una solida conoscenza legata alla selezione del database.

I database possono essere considerati strutture dati che presentano un'eccezionale scalabilità e longevità. Pertanto, la conoscenza delle strutture dati dovrebbe tornarti molto utile anche nella scelta di un database specifico. Ad esempio, Redis è un server di strutture dati che supporta diversi tipi di valori. Permette di lavorare con strutture dati come liste e insiemi e di leggere i dati utilizzando algoritmi ben noti, come ad esempio LRU, organizzando tale attività in uno stile durevole e altamente disponibile.

Architettura software e design dei sistemi: quadro generale e guida alle risorse

Immagine Samuel Zeller dal sito Unsplash

Quando vi orienterete sufficientemente sui vari modelli di archiviazione dei dati, potrete passare a studiare la coerenza e la disponibilità dei dati. La prima cosa che dovrete assimilare è il teorema CAP , almeno a grandi linee, e poi affinare queste conoscenze approfondendo i modelli consolidati di coerenza e disponibilità. In questo modo acquisirete una visione d'insieme in quest'area e capirete che la lettura e la scrittura dei dati sono in realtà due problemi molto diversi, ognuno dei quali presenta le proprie sfide specifiche. Armati di alcuni modelli per garantire coerenza e disponibilità, potrete aumentare significativamente le prestazioni del sistema, garantendo nel contempo un flusso continuo di dati alle vostre applicazioni.

Infine, concludendo la discussione sulle questioni di archiviazione dei dati, è opportuno menzionare anche la memorizzazione nella cache. Deve essere eseguita simultaneamente sia sul client che sul server? Quali dati avrete in cache? E perché? Come organizzerete l'invalidazione della cache? Viene effettuata regolarmente, a intervalli di tempo definiti? Se sì, con che frequenza? Raccomando di iniziare il lavoro su questi temi con il seguente capitolo del suddetto manuale di progettazione dei sistemi.

Modelli di comunicazione

I sistemi sono composti da vari componenti; possono essere diversi processi che operano all'interno dello stesso nodo fisico o diverse macchine che agiscono in diverse parti della vostra rete. Alcune di queste risorse all'interno della vostra rete possono essere private, ma altre devono essere pubbliche e aperte ai consumatori che vi accedono dall'esterno.

È necessario garantire la comunicazione tra queste risorse e anche lo scambio di informazioni tra l'intero sistema e il mondo esterno. Nel contesto della progettazione dei sistemi, qui ci troviamo nuovamente ad affrontare un insieme di nuove sfide uniche. Scopriamo come possono essere utili i flussi di lavoro asincroni, e quali sono i diversimodelli di comunicazione disponibili.

Architettura software e design dei sistemi: quadro generale e guida alle risorse

Immagine Tony Stoddard dal sito Unsplash

Nell'organizzare la comunicazione con il mondo esterno è sempre molto importante sicurezza, un obiettivo al quale bisogna avvicinarsi con grande serietà e dedicarsi attivamente.

Distribuzione delle connessioni

Non sono sicuro che rendere questo argomento una sezione autonoma sembri giustificato a tutti. Tuttavia, presenterò qui questa concettualizzazione in modo dettagliato, ritenendo che il materiale di questa sezione sia meglio descritto dal termine «distribuzione delle connessioni» (connection distribution).

I sistemi si formano attraverso il corretto collegamento di numerosi componenti, e la loro comunicazione tra di loro è spesso organizzata sulla base di protocolli consolidati, come TCP e UDP. Tuttavia, questi protocolli talvolta non sono sufficienti a soddisfare tutte le esigenze dei moderni sistemi, che sono spesso sotto un carico elevato e dipendono fortemente dalle necessità degli utenti. Spesso è necessario trovare modi per distribuire le connessioni, al fine di gestire carichi così elevati nel sistema.

Alla base di tale distribuzione c'è un sistema dei nomi di dominio (DNS). Un sistema di questo tipo consente di convertire un nome di dominio, ad esempio un algoritmo round robin pesato (weighted round robin) e metodi basati su ritardi, che aiutano a distribuire il carico.

Il bilanciamento del carico è fondamentale, e praticamente qualsiasi grande sistema su Internet con cui ci confrontiamo oggi è situato dietro uno o più bilanciatori di carico. I bilanciatori di carico aiutano a distribuire le richieste dei clienti tra molti istanze disponibili. I bilanciatori di carico possono essere sia hardware che software, ma nella pratica ci si trova più spesso con soluzioni software, come ad esempio HAProxy e ELB. I proxy inversi sono concettualmente molto simili ai bilanciatori di carico, anche se ci sono una serie di differenze nette. Queste differenze devono essere necessariamente considerate quando si progetta un sistema in base alle propri necessità.

Bisogna anche essere a conoscenza delle reti di distribuzione dei contenuti (CDN). Un CDN è una rete globale distribuita di server proxy che fornisce informazioni da nodi che sono geograficamente più vicini a un particolare utente. È preferibile utilizzare reti CDN se si lavora con file statici scritti in JavaScript, CSS e HTML. Inoltre, oggi sono comuni servizi cloud che offrono gestori del traffico, come ad esempio, Azure Traffic Manager, che ti offre distribuzione globale e minori ritardi nel lavorare con contenuti dinamici. Tuttavia, tali servizi sono generalmente utili in quei casi in cui ci si trova a lavorare con servizi web senza stato.

Parliamo della logica di business. Strutturazione della logica di business, flussi di lavoro e componenti

Quindi, siamo riusciti a discutere vari aspetti infrastrutturali del sistema. È probabile che l'utente non si preoccupi affatto di tutti questi elementi del tuo sistema e, a dirla tutta, non ci pensi nemmeno. L'utente è interessato a come interagire con il tuo sistema, cosa è possibile ottenere procedendo in questo modo, e come il sistema esegue i comandi dell'utente, cosa fa e come gestisce i dati dell'utente.

Come è chiaro dal titolo di questo articolo, intendevo trattare dell'architettura software e del design dei sistemi. Di conseguenza, non intendevo approfondire i pattern di design del software, che descrivono come si creano i componenti software. Tuttavia, più ci rifletto, più mi sembra che il confine tra pattern di design del software e pattern architettonici sia molto sfumato, e queste due concezioni siano strettamente collegate. Prendiamo, ad esempio, la registrazione degli eventi (event sourcing). Non appena adotterai questo pattern architettonico, influenzerà praticamente tutti gli aspetti del tuo sistema: la conservazione a lungo termine dei dati, il livello di coerenza adottato nel tuo sistema, i contorni dei componenti al suo interno, ecc. Pertanto, ho deciso di menzionare alcuni pattern architettonici che riguardano direttamente la logica di business. Anche se in questo articolo dovrò limitarmi a una semplice lista, ti consiglio di familiarizzarti con essa e riflettere sulle idee ad essa associate. Ecco a te:

Approcci collaborativi

È estremamente improbabile che tu sia l'unico partecipante al progetto responsabile del processo di progettazione del sistema. Al contrario, probabilmente dovrai interagire con i colleghi, che lavorano sia nell'ambito del tuo compito sia al di fuori di esso. In questo caso, potrebbe essere necessario valutare le soluzioni tecnologiche scelte insieme ai colleghi, estrapolare le esigenze aziendali e capire come meglio parallelizzare le attività.

Architettura software e design dei sistemi: quadro generale e guida alle risorse

Immagine Kaleidico dal sito Unsplash

Innanzitutto, è necessario sviluppare una comprensione precisa e riconosciuta di quale sia l'obiettivo aziendale che stai cercando di raggiungere e con quali elementi variabili dovrai confrontarti. Tecniche di modellazione di gruppo, in particolare, storming di eventi (event storming) aiutano significativamente ad accelerare questo processo e aumentano le tue possibilità di successo. Puoi iniziare a lavorare su questo prima o dopo aver delineato i confini dei tuoi servizi, e poi approfondirlo man mano che il prodotto matura. Facendo affidamento sul livello di coerenza che verrà raggiunto qui, puoi anche formulare un linguaggio comune per il contesto limitato in cui operi. Quando sarà necessario parlare dell'architettura del tuo sistema, potrebbe esserti utile il modello C4, proposto da Simon Brown, specialmente quando devi capire quanto dovrai scendere nei dettagli del problema, visualizzando le cose che desideri comunicare.

Probabilmente in questo campo esiste anche un'altra tecnologia matura, altrettanto utile della progettazione orientata agli oggetti. Tuttavia, torniamo sempre alla comprensione del dominio, quindi la conoscenza e l'esperienza nel campo della progettazione orientata agli oggetti dovrebbero esserti utili.

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS - ProHoster