Cosa significa architettura N-tier al giorno d'oggi?

Question

In senso tradizionale, N-tier significa separare l'applicazione in "tier" e inserire ogni "tier" su server diversi. Ciò è stato fatto per almeno 3 ragioni:

1. Manutenzione:

   a) codice di manutenzione: Più facile da fare correzioni di bug e funzionalità aggiunte.

   b) Manutenzione hardware: l'interruzione di un server non interrompe il servizio da un altro livello.

2. Prestazioni: spesso un server non era abbastanza veloce da gestire le richieste Web, i calcoli della logica aziendale e l'accesso al database/file contemporaneamente.

3. scalabilità: Specificamente scalabilità orizzontale

   a) Fault Tolerance: Possibilità di avere più di 1 server fisico per livello quando cioè 1 server è giù, l'applicazione può ancora funzionare come un tutto.

   b) Bilanciamento del carico: disporre di più istanze di un livello consente di gestire una grande quantità di richieste.

Oggigiorno, l'hardware e le reti sono abbastanza veloci da servire migliaia di richieste al secondo su un singolo server. Inoltre, la parola d'ordine per l'IT in questo momento è "consolidamento". Quindi, anche se l'applicazione è suddivisa in livelli, probabilmente finiranno per ospitare su macchine virtuali su un singolo server.

Penso che oggigiorno, quando si parla di architettura N-tier, si parli di separazione delle preoccupazioni all'interno dell'applicazione. È più una separazione logica che una fisica. Penso che finché raggiungiamo una buona separazione delle preoccupazioni e un accoppiamento lento, le applicazioni non devono essere N-tier. Sembra solo che molti programmatori ritengano che l'architettura N-tier sia uno standard d'oro che ogni applicazione web deve rispettare.

Quindi, che cos'è l'architettura N-tier al giorno d'oggi?

Answer 1

Sicurezza per uno? Preferirei che colpissi i miei server web rispetto ai miei server di app!

Answer 2

Penso che sia, ed è sempre stato, una distinzione artificiale. Sono d'accordo con la tua premessa che si riferisce principalmente alla separazione logica dei componenti in questi giorni. Tuttavia, ci sono ancora molte applicazioni che sono troppo grandi (usare saggi o dati) per adattarsi a una singola macchina, quindi l'idea di separare un'applicazione in componenti discreti per motivi di scalabilità non è sicuramente morta.

Answer 3

Dall'articolo wikipedia ho letto:

In generale, i livelli termine è usato per descrivere la distribuzione fisica dei componenti di un sistema su server separati, computer o reti (nodi di elaborazione). Un'architettura a tre livelli avrà quindi tre nodi di elaborazione . I livelli si riferiscono a un raggruppamento logico di componenti che possono o meno essere localizzati fisicamente su un nodo di elaborazione.

Penso che il concetto di "livello" e il concetto di "livello" si siano confusi con il tempo. Personalmente preferisco parlare solo di livelli piuttosto che di livelli, perché preferisco le soluzioni PAAS in cui le mie preoccupazioni riguardano solo il software e l'industria si sta lentamente muovendo in questa direzione.

Inoltre, quando si pianifica un'applicazione che potrebbe espandersi notevolmente, non penso che si debba pensare a livello n per la scalabilità. In effetti, i siti Web molto popolari con molto traffico si separano solo in 3 componenti: Server di database, server Web (inclusi i server di memorizzazione nella cache) e alcuni CDN (reti di distribuzione dei contenuti). Questo tipo di separazione può essere raggiunto in qualsiasi applicazione.

Ma per concludere, penso che un programmatore dovrebbe pensare solo agli strati e alla separazione delle preoccupazioni all'interno dell'applicazione per ottenere il compito più importante (e difficile): la manutenzione a lungo termine.