Cosa si intende per sistema scalabile? Quali tecniche possono essere utilizzate per ottenere la scalabilità?

Migliore risposta

Scalabile significa che il sistema può, con relativa facilità, essere adattato a una base di utenti più ampia di quanto inizialmente o originariamente previsto . I fattori che determinano la scalabilità di unapplicazione includono:

• buona struttura del programma (quanto è facile comprendere ed espandere il programma per supportare nuovi ruoli)
• più utenti e accesso e modifica simultanei al database (per evitare il blocco del database, negazione dellaccesso, danneggiamento o perdita di dati)
• disposizioni di sicurezza sia per laccesso dellutente che per lintegrità del database
• capacità di funzionare come applicazione distribuita su più server e database su più fusi orari
• backup, correzione e ripristino del database
• disposizioni linguistiche e culturali
• predisposizione per lintercomunicazione con terze parti applicazioni esponendo uninterfaccia di programma ben gestita o sottoscrivendo standard di settore
• utilizzo delle risorse e dipendenze hardware / sistema operativo
• prestazioni in tempo reale

Ci sono altri fattori, dipendenti da specifici domini aziendali, ma questi sono i fattori che vediamo abitualmente diventare un i ssue quando unazienda cerca di “scalare” o “estendere” le proprie applicazioni.

La scalabilità di solito soffre quando uno / o uno:

• il programma è concepito e scritto da qualcuno esperto nelle discipline dello sviluppo di applicazioni
• la responsabilità di scrivere un programma è affidata a una specifica che non esplora tutti i fattori appropriati alle esigenze future dei clienti (una specifica debole spesso porta a soluzioni non scalabili )
• non vi è alcuna supervisione da parte di un ingegnere software esperto che comprende il dominio aziendale

Un semplice esempio di mancata scalabilità è un programma di inventario di magazzino su cui ho lavorato indietro nel 1990 (ish).

Il programma originale è stato scritto per un utente, un server e backup notturni (durante i quali il sistema non era disponibile). In ordine successivo, il cliente desiderava:

• aumentare il numero di utenti da 1 a 50+ e applicare vari ruoli e privilegi di accesso per ciascun utente.
• espandere lapplicazione per supportare più magazzini allinterno dello stesso paese
• espandere lapplicazione per tenere conto di nuovi magazzini offshore che implicano il supporto per più fusi orari, lingue, standard legali e procedure operative

Il programma originale non era mai stato strutturato per un requisito di scalabilità così forte. Il database soffriva di frequenti blocchi di “abbraccio mortale”, perdita di dati e tempi di inattività inaccettabili a causa delle procedure di backup del database. Lapplicazione non prevedeva limmissione di dati “offline” e ovviamente non era stata scritta per tollerare i problemi di comunicazione. Anche il tentativo di aggiornare il programma si è rivelato un incubo: fondamentalmente lintero sistema si è bloccato per le diverse ore necessarie per installare un aggiornamento globale.

Prima di essere chiamati, come consulenti, il programma è stato “patchato” dal programmatore originale (singolare) che si era successivamente chiuso ed era scomodamente scomparso.

Lapplicazione delle patch ha offuscato la struttura e la funzionalità del codice – tuttavia dubito che il programma sia mai stato adeguatamente strutturato o documentato – nessuno ne sapeva abbastanza per rendersi conto del rischio che questo rappresentava per lazienda! Il codice è stato scritto in C ++ e utilizzava array di byte invece di stringhe standard di settore, multibyte character set (MBCS) … hai unidea generale!

Siamo stati chiamati per “correggere” il i problemi. La verità è che sarebbe stato più semplice ed economico trasferire il cliente a un prodotto di gestione dellinventario commerciale, tuttavia avevano una modellazione finanziaria profondamente incorporata nel sistema e nessuno capiva abbastanza come funzionava per trasferire queste funzionalità a una pubblicità programma (almeno senza rischi significativi).

Alla fine, nonostante abbiamo indicato soluzioni più convenienti, abbiamo dovuto decodificare il prodotto e riscrivere completamente lapplicazione. Ci sono voluti 2 progettisti di sistema, 4 ingegneri principali, 20 ingegneri software, 5 convalidatori e 2 ingegneri di strumenti / metodologie per riscrivere il prodotto e quasi 2 anni di tempo per portare lapplicazione in versione generale.

Quindi come si ottiene la scalabilità?

1. Inizia assicurandoti di aver scritto i tuoi requisiti di scalabilità nelle specifiche del prodotto. Generalmente la pressione del tempo e il costo più basso causeranno sacrifici in aree che non erano adeguatamente obbligatorie nelle specifiche.
2. Lavora con esperti di dominio che possono aiutarti a sviluppare una struttura che soddisferà le (probabili) esigenze future.
3. Approfitta di design pattern, librerie, applicazioni 4GL / AI e architetture che sono state formulate da zero per evitare problemi di scalabilità (molte delle quali sono state sviluppate da esperienze amare).
4. Leggi tutte le aree chiave come database distribuiti e tolleranti agli errori per applicazioni altamente concorrenti, architetture di sicurezza integrate, replica di database, elaborazione nel cloud ecc.
5. Assicurati di utilizzare ingegneri esperti ed esperti in posizioni chiave. Direi che quasi il 50\% dei progetti di salvataggio che abbiamo intrapreso sono stati la conseguenza di ingegneri capo e progettisti di sistemi inesperti. Il resto era dovuto a errori di gestione o comunicazioni improprie tra lingegneria e il cliente.

Ecco fatto. Oggigiorno non ci sono davvero scuse per problemi di scalabilità nelle aziende di medie e grandi dimensioni, tuttavia molte aziende iniziano con solo una manciata di persone che hackerano le soluzioni nel miglior modo possibile. Quindi lazienda cresce e la scalabilità diventa un incubo piuttosto che la progressione ordinata che dovrebbe essere!

Risposta

La scalabilità nellingegneria del software si riferisce, normalmente, alla progettazione di sistemi software in modo tale che , poiché il numero di utenti del sistema aumenta (anche di 100 volte o più), il software continuerà a funzionare con tempi di risposta comparabili. Ora, la domanda successiva è “come si ottiene?”

Il software desktop autonomo (ad es. Giochi) è sempre scalabile al 100\% perché ogni utente ha un intero computer. Questa è una forma banale di scalabilità.

I sistemi software client-server e basati sul web, tuttavia, dipendono dai server , che sono computer che forniscono servizi a più utenti. Dovrebbe essere ovvio che un dato server può gestire solo un numero limitato di utenti simultanei.

Esistono due tecniche generali che consentono a un sistema di scalare oltre ciò che un singolo server può gestire. I sistemi altamente scalabili combineranno entrambe le tecniche.

Il primo è suddividere la funzionalità in parti diverse. Una divisione comune è avere un server separato per ospitare il database su cui si basa il sistema (cè quasi sempre una sorta di database per contenere informazioni persistenti). Al server di database viene fornita una grande quantità di memoria e dischi o array RAID molto veloci, mentre laltro tipo di server necessita di meno memoria e relativamente poco spazio su disco.

Questo può essere esteso a unarchitettura a più livelli, dove sempre più funzionalità (e dati, per i database) sono suddivisi tra diversi processi. Quando il carico aumenta, i processi vengono migrati su server separati per mantenere le prestazioni. Tieni presente che tutti questi server si trovano fisicamente nella stessa server farm e sono connessi tramite connessioni di rete ad altissima velocità.

Laltra tecnica utilizzata per la scalabilità è la replica . Ciò significa che, ad esempio, vengono utilizzati più server Web e ogni utente è collegato a uno solo di essi. Per supportare più utenti, il sistema necessita solo di più hardware (sistemi di server web in questo esempio). I database sono anche in grado di replicarsi, in modo che più server di database possano supportare cloni del database (a volte è difficile mantenere aggiornate le diverse copie del database, ma i dba gestiscono questo problema da anni). Per i sistemi più grandi, esistono database progettati per essere scalabili, distribuendo i dati su più server.

A2A: “Cosa si intende per” scalabilità “nellingegneria del software?”