Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse

Ciao colleghi.

Oggi offriamo alla vostra considerazione la traduzione di un articolo di Tugberk Ugurlu, che si è impegnato a delineare in un volume relativamente piccolo i principi della progettazione dei moderni sistemi software. Ecco in sintesi cosa dice di sé l'autore:

Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse
Poiché è assolutamente impossibile trattare in un articolo habro un argomento così colossale come i modelli architettonici + i modelli di design a partire dal 2019, raccomandiamo non solo il testo dello stesso signor Uruglu, ma anche i numerosi link che ha gentilmente incluso in esso. Se ti piace, pubblicheremo un testo più altamente specializzato sulla progettazione di sistemi distribuiti.

Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse

Foto Isacco Smith da Unsplash

Se non hai mai dovuto affrontare sfide come la progettazione di un sistema software da zero, quando si inizia questo lavoro a volte non è nemmeno chiaro da dove iniziare. Credo che tu debba prima tracciare i confini in modo da avere un'idea più o meno sicura di cosa progetterai esattamente, quindi rimboccarti le maniche e lavorare entro quei confini. Come punto di partenza, puoi prendere un prodotto o un servizio (idealmente uno che ti piace davvero) e capire come implementarlo. Potresti rimanere stupito da quanto sia semplice questo prodotto e da quanta complessità contenga effettivamente. Non dimenticare: semplice - solitamente complesso, e va bene così.

Penso che il miglior consiglio che posso dare a chiunque inizi a progettare un sistema sia questo: non fare supposizioni! Fin dall'inizio è necessario specificare i fatti noti su questo sistema e le aspettative ad esso associate. Ecco alcune domande utili da porre per aiutarti a iniziare con il tuo progetto:

  • Qual è il problema che stiamo cercando di risolvere?
  • Qual è il numero massimo di utenti che interagiranno con il nostro sistema?
  • Quali modelli di scrittura e lettura dei dati utilizzeremo?
  • Quali sono i casi di fallimento previsti, come li gestiremo?
  • Quali sono le aspettative in termini di coerenza e disponibilità del sistema?
  • Quando si lavora è necessario tenere conto di eventuali requisiti relativi alla verifica e alla regolamentazione esterna?
  • Quali tipi di dati sensibili conserveremo?

Queste sono solo alcune domande che sono state utili sia a me che ai team a cui ho partecipato in questi anni di attività professionale. Se conosci le risposte a queste domande (e ad eventuali altre rilevanti per il contesto in cui devi operare), allora potrai gradualmente approfondire i dettagli tecnici del problema.

Imposta il livello iniziale

Cosa intendo qui per “baseline”? In realtà, ai nostri giorni, la maggior parte dei problemi dell’industria del software “può” essere risolta utilizzando metodi e tecnologie esistenti. Di conseguenza, navigando in questo panorama, ottieni un certo vantaggio di fronte a problemi che qualcun altro ha dovuto risolvere prima di te. Non dimenticare che i programmi sono scritti per risolvere problemi aziendali e degli utenti, quindi ci sforziamo di risolvere il problema nel modo più diretto e semplice (dal punto di vista dell'utente). Perché è importante ricordarlo? Forse nel tuo sistema di coordinate ti piace cercare soluzioni uniche per tutti i problemi, perché pensi: "che tipo di programmatore sono se seguo schemi ovunque"? Infatti, l'arte qui sta nel prendere decisioni su dove e cosa fare. Naturalmente, ognuno di noi deve affrontare di volta in volta problemi unici, ognuno dei quali rappresenta una vera sfida. Tuttavia, se il nostro livello iniziale è chiaramente definito, allora sappiamo su cosa spendere le nostre energie: cercare opzioni già pronte per risolvere il problema che ci viene posto, oppure studiarlo ulteriormente e acquisire una comprensione più profonda.

Penso di essere riuscito a convincerti che se uno specialista comprende con sicurezza qual è la componente architettonica di alcuni meravigliosi sistemi software, allora questa conoscenza sarà indispensabile per padroneggiare l'arte di un architetto e sviluppare solide basi in questo campo.

Ok, quindi da dove cominciare? U Donna Martina C'è un repository su GitHub chiamato primer-design-di-sistema, da cui puoi imparare come progettare sistemi su larga scala, nonché prepararti per interviste su questo argomento. Il repository ha una sezione con esempi vere e proprie architetture, dove, in particolare, si considera il modo in cui affrontano la progettazione dei loro sistemi alcune aziende molto notead esempio Twitter, Uber, ecc.

Tuttavia, prima di passare a questo materiale, diamo uno sguardo più da vicino alle sfide architettoniche più importanti che dobbiamo affrontare nella pratica. Questo è importante perché è necessario specificare MOLTI aspetti di un problema ostinato e sfaccettato, e poi risolverlo nel quadro delle normative vigenti in un dato sistema. Jackson Gabbard, ha scritto un ex dipendente di Facebook Video di 50 minuti sulle interviste sulla progettazione dei sistemi, dove ha condiviso la propria esperienza nello screening di centinaia di candidati. Sebbene il video si concentri principalmente sulla progettazione di sistemi di grandi dimensioni e sui criteri di successo importanti quando si cerca un candidato per tale posizione, fungerà comunque da risorsa completa su quali sono gli aspetti più importanti durante la progettazione dei sistemi. Suggerisco anche riepilogo questo video.

Sviluppare conoscenze sull'archiviazione e il recupero dei dati

In genere, la decisione su come archiviare e recuperare i dati a lungo termine ha un impatto critico sulle prestazioni del sistema. Pertanto, è necessario innanzitutto comprendere le caratteristiche di scrittura e lettura previste del proprio sistema. Poi bisogna essere in grado di valutare questi indicatori e fare delle scelte in base alle valutazioni effettuate. Tuttavia, puoi affrontare efficacemente questo lavoro solo se comprendi i modelli di archiviazione dei dati esistenti. In linea di principio, ciò implica una solida conoscenza relativa a selezione della banca dati.

I database possono essere pensati come strutture di dati estremamente scalabili e durevoli. Pertanto, la conoscenza delle strutture dei dati dovrebbe esserti molto utile quando scegli un particolare database. Per esempio, Redis è un server di struttura dati che supporta vari tipi di valori. Ti consente di lavorare con strutture di dati come elenchi e insiemi e di leggere dati utilizzando algoritmi noti, ad esempio, LRU, organizzando tale lavoro in uno stile duraturo e altamente accessibile.

Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse

Foto Samuel Zeller da Unsplash

Una volta acquisita una conoscenza sufficiente dei vari modelli di archiviazione dei dati, passa allo studio della coerenza e della disponibilità dei dati. Prima di tutto bisogna capire Teorema del CAP almeno in termini generali, per poi affinare questa conoscenza dando uno sguardo più attento ai modelli consolidati consistenza и disponibilità. In questo modo, svilupperai una comprensione del campo e capirai che la lettura e la scrittura dei dati sono in realtà due problemi molto diversi, ciascuno con le proprie sfide uniche. Grazie ad alcuni modelli di coerenza e disponibilità, puoi aumentare significativamente le prestazioni del sistema garantendo al tempo stesso un flusso di dati fluido verso le tue applicazioni.

Infine, concludendo la conversazione sui problemi di archiviazione dei dati, dovremmo menzionare anche il caching. Dovrebbe essere eseguito contemporaneamente sul client e sul server? Quali dati saranno nella cache? E perché? Come organizzi l'invalidazione della cache? Verrà fatto regolarmente, a determinati intervalli? Se sì, quanto spesso? Consiglio di iniziare a studiare questi argomenti con sezione successiva il suddetto primer per la progettazione del sistema.

Modelli di comunicazione

I sistemi sono costituiti da vari componenti; questi potrebbero essere processi diversi in esecuzione all'interno dello stesso nodo fisico o macchine diverse in esecuzione su parti diverse della rete. Alcune di queste risorse all'interno della tua rete potrebbero essere private, ma altre dovrebbero essere pubbliche e aperte ai consumatori che vi accedono dall'esterno.

È necessario garantire la comunicazione di queste risorse tra loro, nonché lo scambio di informazioni tra l'intero sistema e il mondo esterno. Nel contesto della progettazione dei sistemi, anche in questo caso ci troviamo di fronte a una serie di sfide nuove e uniche. Vediamo come possono essere utili flussi di attività asincroni, e ciò che pSono disponibili diversi modelli di comunicazione.

Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse

Foto Tony Stoddard da Unsplash

Quando si organizza la comunicazione con il mondo esterno, è sempre molto importante sicurezza, la cui fornitura deve essere presa sul serio e perseguita attivamente.

Distribuzione delle connessioni

Non sono sicuro che mettere questo argomento in una sezione separata sembrerà giustificato a tutti. Tuttavia, presenterò questo concetto in dettaglio qui e credo che il materiale in questa sezione sia descritto più accuratamente dal termine "distribuzione delle connessioni".

I sistemi sono formati collegando opportunamente molti componenti e la loro comunicazione reciproca è spesso organizzata sulla base di protocolli stabiliti, ad esempio TCP e UDP. Tuttavia, questi protocolli in quanto tali non sono spesso sufficienti a soddisfare tutte le esigenze dei sistemi moderni, che spesso funzionano sotto carico elevato e sono anche fortemente dipendenti dalle esigenze degli utenti. Spesso è necessario trovare modi per distribuire le connessioni per far fronte a carichi così elevati sul sistema.

Questa distribuzione si basa sul noto Domain Name System (DNS). Un sistema di questo tipo consente trasformazioni di nomi di dominio come round robin ponderato e metodi basati sulla latenza per aiutare a distribuire il carico.

Bilancio del carico è di fondamentale importanza e praticamente ogni grande sistema Internet con cui abbiamo a che fare oggi si trova dietro uno o più sistemi di bilanciamento del carico. I bilanciatori del carico aiutano a distribuire le richieste dei client su più istanze disponibili. I bilanciatori di carico sono disponibili sia in hardware che in software, tuttavia, in pratica, più spesso devi avere a che fare con quelli software, ad esempio HAProxy и ELB. Proxy inversi concettualmente molto simili anche ai bilanciatori di carico, anche se esiste un range tra il primo e il secondo differenze distinte. Queste differenze devono essere prese in considerazione quando si progetta un sistema in base alle proprie esigenze.

Dovresti anche saperlo reti di distribuzione dei contenuti (CDN). Una CDN è una rete distribuita globale di server proxy che fornisce informazioni da quei nodi che si trovano geograficamente più vicini a un utente specifico. È preferibile utilizzare i CDN se lavori con file statici scritti in JavaScript, CSS e HTML. Inoltre, oggi sono comuni i servizi cloud che forniscono gestori del traffico, ad esempio Gestione traffico di Azure, offrendoti una distribuzione globale e una latenza ridotta quando lavori con contenuti dinamici. Tuttavia, tali servizi sono generalmente utili nei casi in cui è necessario lavorare con servizi Web senza stato.

Parliamo di logica aziendale. Strutturare la logica aziendale, i flussi di attività e i componenti

Siamo quindi riusciti a discutere vari aspetti infrastrutturali del sistema. Molto probabilmente, l'utente non pensa nemmeno a tutti questi elementi del tuo sistema e, francamente, non se ne preoccupa affatto. L'utente è interessato a cosa vuol dire interagire con il sistema, cosa si può ottenere in questo modo e anche come il sistema esegue i comandi dell'utente, cosa e come fa con i dati dell'utente.

Come suggerisce il titolo di questo articolo, avrei parlato di architettura software e progettazione di sistemi. Di conseguenza, non avevo intenzione di trattare i modelli di progettazione del software che descrivono come vengono creati i componenti software. Tuttavia, più ci penso, più mi sembra che il confine tra modelli di progettazione software e modelli architettonici sia molto labile e che i due concetti siano strettamente correlati. Prendiamo ad esempio registrazione dell'evento (fonte di eventi). Una volta adottato questo modello architetturale, influenzerà quasi ogni aspetto del tuo sistema: archiviazione a lungo termine dei dati, livello di coerenza adottato nel tuo sistema, forma dei componenti in esso contenuti, ecc., Ecc. Pertanto, ho deciso di menzionare alcuni modelli architettonici che si riferiscono direttamente alla logica aziendale. Anche se questo articolo dovrà limitarsi a un semplice elenco, ti incoraggio a conoscerlo e a riflettere sulle idee associate a questi modelli. Ecco:

Approcci collaborativi

È estremamente improbabile che ti ritroverai in un progetto come partecipante unico responsabile del processo di progettazione del sistema. Al contrario, molto probabilmente dovrai interagire con colleghi che lavorano sia all’interno che all’esterno del tuo compito. In questo caso, potrebbe essere necessario valutare le soluzioni tecnologiche selezionate con i colleghi, identificare le esigenze aziendali e capire come parallelizzare al meglio le attività.

Architettura software e progettazione di sistemi: il quadro generale e la guida alle risorse

Foto Caleidico da Unsplash

Il primo passo è sviluppare una comprensione accurata e condivisa di quale sia l’obiettivo aziendale che si sta cercando di raggiungere e con quali parti in movimento si dovrà avere a che fare. Tecniche di modellazione di gruppo, in particolare eventi tempestosi (event storming) aiutano ad accelerare notevolmente questo processo e ad aumentare le possibilità di successo. Questo lavoro può essere svolto prima o dopo la delineazione confini dei tuoi servizi, per poi approfondirlo man mano che il prodotto matura. In base al livello di coerenza che verrà raggiunto qui, puoi anche formulare linguaggio comune per il contesto limitato in cui lavori. Quando hai bisogno di parlare dell'architettura del tuo sistema, potresti trovarlo utile modello C4proposto Simone Marrone, soprattutto quando avrai bisogno di capire quanto dovrai entrare nei dettagli del problema, visualizzando le cose che vuoi comunicare.

Probabilmente esiste un’altra tecnologia matura su questo argomento che non è meno utile del Domain Driven Design. Si torna però in qualche modo alla comprensione della materia, quindi alla conoscenza e all'esperienza sul campo Progettazione basata sul dominio dovrebbe esserti utile.

Fonte: habr.com

Aggiungi un commento