Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse

Ciao, colleghi.

Oggi vi presentiamo la traduzione dell'articolo di Tugberk Ugurlu, che si è sforzato di esporre in modo relativamente conciso i principi di progettazione dei moderni sistemi software. Ecco cosa l'autore dice di sé in sintesi:

Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse
Poiché è assolutamente impossibile affrontare in un breve articolo un tema così colossale come i pattern architetturali e i pattern di progettazione aggiornati al 2019, consigliamo non solo il testo del signor Ugurlu, ma anche i numerosi riferimenti che ha gentilmente incluso. Se vi piacerà, pubblicheremo anche un testo più specializzato sulla progettazione di sistemi distribuiti.

Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse

Immagine di Isaac Smith da Unsplash

Se non hai mai affrontato sfide come la progettazione di un sistema software da zero, all'inizio di un lavoro del genere può essere difficile sapere da dove cominciare. Credo sia fondamentale delineare i confini, in modo da avere una certa sicurezza su cosa stai per progettare, per poi rimboccarti le maniche e lavorare senza oltrepassare questi confini. Un buon punto di partenza può essere un prodotto o un servizio (idealmente uno che ti piace molto) e analizzarne l'implementazione. Potresti sorprenderti di quanto possa sembrare semplice quel prodotto e di quanta complessità si nasconda realmente al suo interno. Non dimenticare: il semplice è spesso complesso, e va bene così.

Penso che il miglior consiglio che posso dare a chi inizia a progettare un sistema sia: non fare assunzioni! Fin dall'inizio è importante specificare i fatti noti su questo sistema e le aspettative ad esso correlate. Ecco alcune buone domande alle quali le risposte ti aiuteranno a iniziare 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 previsti di fallimento e come intendiamo gestirli?
  • Quali aspettative ci sono riguardo alla coerenza e disponibilità del sistema?
  • Dobbiamo considerare eventuali requisiti relativi a controlli esterni e regolamentazione?
  • Quali tipi di dati sensibili intendiamo conservare?

Queste sono solo alcune domande che sono state utili sia a me che ai team con cui ho collaborato nel corso degli anni. Se conosci le risposte a queste domande (e a qualsiasi altra nella tua situazione lavorativa), possiamo iniziare a entrare nei dettagli tecnici del compito.

Impostiamo il livello iniziale

Cosa intendo qui con "livello di base" (baseline)? Oggi, la maggior parte dei problemi nell'industria del software può essere "risolta" utilizzando metodi e tecnologie già esistenti. Pertanto, orientandosi in questo panorama, si ottiene un certo vantaggio quando si affrontano compiti che qualcun altro ha risolto prima di voi. Non dimentichiamo che i programmi vengono scritti per risolvere problemi di business e degli utenti; per questo motivo, cerchiamo di affrontare la questione nel modo più diretto e semplice possibile (dal punto di vista dell'utente). Perché è importante ricordarlo? Forse nel vostro sistema di coordinate preferite trovare soluzioni uniche per ogni problema, poiché pensate: "Che tipo di programmatore sarei se seguissi sempre i modelli"? In realtà, l'arte qui consiste nel prendere decisioni su dove e cosa fare.. Naturalmente, a tutti noi capita di affrontare problemi unici di tanto in tanto, ognuno dei quali rappresenta una vera sfida. Tuttavia, se il nostro punto di partenza è ben definito, sappiamo su cosa investire le nostre energie: nella ricerca di soluzioni pronte per il compito assegnato, oppure nella sua ulteriore esplorazione e comprensione più profonda.

Credo di avervi convinto che, se uno specialista comprende in modo chiaro quali siano le componenti architettoniche di alcuni straordinari sistemi software, queste conoscenze saranno indispensabili per padroneggiare l'arte dell'architetto e costruire una solida base in questo campo.

Bene, da dove iniziare? A Donna Martin ha un repository su GitHub chiamato system-design-primer, da cui potrai apprendere come progettare sistemi su larga scala e prepararti per interviste su questo tema. Nel repository c'è una sezione con esempi di architetture reali, che discutono, tra l'altro, come alcune aziende ben note affrontano il design dei loro sistemi , come Twitter, Uber, ecc., ad esempio, Twitter, Uber, ecc.

Tuttavia, prima di passare a questo materiale, analizziamo più a fondo le sfide architettoniche più importanti che si devono affrontare nella pratica. Questo è cruciale, poiché è necessario specificare molteplici aspetti di un problema complesso e multiforme e quindi affrontarlo nel contesto della regolamentazione vigente in questo sistema. Jackson Gabbard, ex dipendente di Facebook, ha registrato un video di 50 minuti sulle interviste relative alla progettazione di sistemi, dove ha condiviso la sua esperienza dopo aver esaminato centinaia di candidati. Sebbene il video si concentri specificamente sulla progettazione di grandi sistemi e sui criteri di successo importanti durante la selezione di un candidato per tale posizione, sarà comunque una risorsa esaustiva su quali aspetti siano più rilevanti nella progettazione dei sistemi. Propongo anche un riepilogo di questo video.

Acquisisci conoscenze su archiviazione e recupero dei dati

In generale, la tua decisione su come archiviare e gestire i dati a lungo termine influisce in modo critico sulle prestazioni del sistema. Di conseguenza, devi prima comprendere le caratteristiche attese di scrittura e lettura dei dati nel tuo sistema. Poi, è necessario essere in grado di valutare questi parametri e prendere decisioni in base alle valutazioni effettuate. Tuttavia, potrai affrontare efficacemente questo compito solo se comprendi i modelli esistenti di archiviazione dei dati. Questo implica, in linea di principio, una solida conoscenza riguardante la scelta del database.

I database possono essere considerati strutture dati caratterizzate da un'eccezionale scalabilità e longevità. Pertanto, la conoscenza delle strutture dati ti sarà molto utile anche nella scelta di un database specifico. Ad esempio, Redis è un server di strutture dati che supporta vari tipi di valori. Consente di lavorare con strutture dati come liste e insiemi, e di leggere i dati utilizzando algoritmi noti come LRU, organizzando tale lavoro in uno stile duraturo e altamente disponibile.

Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse

Immagine Samuel Zeller da Unsplash

Quando avrete una buona comprensione dei vari modelli di archiviazione dei dati, potrete passare a studiare la coerenza e la disponibilità dei dati. Per prima cosa, dovrete apprendere il teorema CAP almeno a grandi linee, e poi affinare queste conoscenze esaminando più dettagliatamente i modelli consolidati di coerenza e disponibilità. In questo modo, svilupperete una visione più ampia di questo campo e capirete che la lettura e la scrittura dei dati sono in realtà due problemi molto diversi, ciascuno con le sue sfide specifiche. Armati di diversi modelli per garantire la coerenza e la disponibilità, sarete in grado di aumentare significativamente le prestazioni del sistema, garantendo nel contempo un'alimentazione continua dei dati alle vostre applicazioni.

Infine, concludendo il discorso sulle questioni relative alla memorizzazione dei dati, è importante menzionare anche la memorizzazione nella cache. Dovrebbe essere eseguita simultaneamente sul client e sul server? Quali dati saranno memorizzati nella cache? E perché? Come organizzate l'invalidazione della cache? Avverrà regolarmente, a intervalli di tempo definiti? Se sì, con quale frequenza? Suggerisco di iniziare a approfondire questi temi con la seguente sezione del suddetto manuale sulla progettazione dei sistemi.

Modelli di comunicazione

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

È necessario garantire la comunicazione tra queste risorse e lo scambio di informazioni all'interno del sistema e con il mondo esterno. Nel contesto della progettazione dei sistemi, ci troviamo ad affrontare un insieme di nuove sfide uniche. Vediamo come possono essere utili flussi di lavoro asincroni, e qualidiversi modelli di comunicazione sono disponibili.

Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse

Immagine Tony Stoddard da Unsplash

Quando si organizza la comunicazione con il mondo esterno, è sempre molto importante sicurezza, a cui bisogna avvicinarsi con tutta serietà e a cui dedicarsi attivamente.

Distribuzione delle connessioni

Non sono sicuro che trattare questo argomento in una sezione separata sembri giustificato a tutti. Tuttavia, esplicherò qui questa concezione, ritenendo che il materiale di questa sezione sia meglio descritto dal termine "distribuzione delle connessioni".

I sistemi sono costituiti dalla corretta combinazione di numerosi componenti, e la loro comunicazione reciproca è spesso organizzata sulla base di protocolli consolidati, come TCP e UDP. Tuttavia, questi protocolli da soli non sono sempre sufficienti per soddisfare tutte le esigenze dei sistemi moderni, che spesso operano sotto elevato carico e dipendono fortemente dalle necessità degli utenti. È frequentemente necessario trovare modalità di distribuzione delle connessioni per gestire tali carichi elevati nel sistema.

Alla base di tale distribuzione si trova un sistema di nomi di dominio (DNS). Questo sistema consente di trasformare il nome di dominio, utilizzando ad esempio algoritmi di round robin ponderato e metodi basati sui tempi di attesa, per aiutare a distribuire il carico.

Bilanciamento del carico è fondamentale e praticamente qualsiasi grande sistema su Internet con cui ci troviamo a dover interagire si trova dietro uno o più bilanciatori di carico. I bilanciatori di carico aiutano a distribuire le richieste dei clienti su molteplici istanze disponibili. I bilanciatori di carico possono essere sia hardware che software, tuttavia, nella pratica, ci si trova più spesso ad affrontare quelli software, ad esempio con HAProxy e ELB. Proxy inversi sono concettualmente molto simili ai bilanciatori di carico, anche se tra i due ci sono una serie di differenze nette. Queste differenze devono essere prese in considerazione quando si progetta un sistema in base alle proprie esigenze.

È anche importante essere a conoscenza di reti di distribuzione dei contenuti (CDN). CDN – è una rete globale distribuita di server proxy che fornisce informazioni dai nodi che sono geograficamente più vicini a un utente specifico. È preferibile utilizzare le reti CDN se si lavora con file statici scritti in JavaScript, CSS e HTML. Inoltre, oggi sono comuni servizi cloud che forniscono gestori di traffico, come Azure Traffic Manager, che offrono distribuzione globale e minori ritardi nella gestione dei contenuti dinamici. Tuttavia, questi servizi sono generalmente utili nei casi in cui si lavora con servizi web senza stato.

Parliamo della logica commerciale. Strutturare la logica commerciale, i flussi di lavoro e i componenti

Quindi, abbiamo avuto l'opportunità di discutere vari aspetti infrastrutturali del sistema. È probabile che l'utente non si preoccupi di tutti questi elementi del tuo sistema e, sinceramente, non ci pensi nemmeno. Ciò che interessa all'utente è come interagire con il tuo sistema, quali risultati può ottenere agendo in un certo modo e come il sistema esegue i comandi degli utenti e gestisce i dati degli utenti.

Come è chiaro dal titolo di questo articolo, intendevo parlare di architettura software e progettazione di sistemi. Pertanto, non avevo pianificato di trattare i pattern di progettazione software che descrivono come vengono creati i componenti software. Tuttavia, più ci penso, più mi sembra che il confine tra i pattern di progettazione software e i pattern architetturali sia molto sfocato e che queste due concetti siano strettamente legati. Prendiamo, ad esempio, la registrazione degli eventi (event sourcing). È sufficiente adottare questo pattern architetturale affinché influisca praticamente su tutti gli aspetti del tuo sistema: la persistenza dei dati, il livello di coerenza accettato nel tuo sistema, la definizione 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 si dovrà limitare a un semplice elenco, ti consiglio di prenderlo in considerazione e riflettere sulle idee associate a questi pattern. Ecco a te:

Approcci collaborativi

È estremamente improbabile che tu sia l'unico responsabile del processo di progettazione del sistema in un progetto. Al contrario, è molto probabile che tu debba collaborare con colleghi che lavorano sia nel tuo ambito di competenza che oltre. In tal caso, sarà necessario valutare le soluzioni tecnologiche scelte insieme ai colleghi, identificare le esigenze aziendali e capire come meglio suddividere i compiti.

Architettura software e progettazione dei sistemi: panoramica generale e guida alle risorse

Immagine Kaleidico da Unsplash

Innanzitutto, dovrai sviluppare una rappresentazione precisa e comunemente accettata dell'obiettivo aziendale che stai cercando di raggiungere e quali elementi mobili dovrai affrontare. Le tecniche di modellazione di gruppo, in particolare, storming di eventi (event storming) aiutano notevolmente a velocizzare questo processo e aumentano le tue possibilità di successo. Puoi iniziare questo lavoro prima o dopo aver delineato i confini dei tuoi servizi, per poi approfondirlo man mano che il prodotto matura. Basandoti sul livello di coerenza raggiunto qui, puoi anche formulare un linguaggio comune per il contesto limitato in cui operi. Quando è necessario parlare dell'architettura del tuo sistema, potresti trovare utile il modello C4, proposto da Simon Brown, soprattutto quando è necessario capire quanto dovrai approfondire i dettagli del problema, visualizzando le cose che desideri comunicare.

Probabilmente ci sarà anche un'altra tecnologia matura in questo ambito, altrettanto utile quanto il design orientato agli oggetti. Tuttavia, torniamo comunque alla comprensione dell'area tematica, quindi le conoscenze e l'esperienza nel campo del design orientato agli oggetti ti saranno utili.

Fonte: habr.com

Acquista un hosting affidabile per siti con protezione DDoS, server VPS VDS 🔥 Acquista un hosting affidabile per siti con protezione DDoS, server VPS VDS | ProHoster