Architettura di rete di app Web modulare

Ricorda una regola chiave:

Non preoccuparti troppo di rendere l'architettura scalabile e tutto nel primo passaggio. Potrebbe essere necessario cambiarlo più volte man mano che la tua applicazione si evolve a seguito di un maggior numero di utenti / traffico / funzionalità / ecc.

Basta scendere a spedire qualcosa in modo che gli utenti REAL possano provarlo e agire sul loro feedback. Non pianificare in anticipo troppo perché non importa cosa pianificare, è destinato a cambiare.

Per quanto riguarda il problema, il proxy inverso e il server web possono generalmente essere la stessa applicazione - di solito nginx per cominciare. Quindi, man mano che si scala, la vernice può essere un proxy inverso più potente.

I server Web come nginx non parlano mai direttamente al database. I server delle applicazioni siedono tra i due.

- UPDATE -

Quanto sopra NON significa che non abbiamo affatto bisogno di pensare all'architettura. Significa non preoccuparsi di ottenere tutti gli ultimi dettagli architettonici fin dall'inizio.

Tuttavia, dovremmo pensare alla forma del sistema di alto livello. Le interazioni tra i componenti sono qualcosa che deve essere ben studiato prima di dare il via all'implementazione concreta.

puoi pensare ad App Server come una sorta di super versione di JDBC o ActiveRecord o qualsiasi altra cosa tu usi. Alcune applicazioni non avranno bisogno di questa separazione, e se questo è il tuo primo passaggio, come detto, non preoccuparti. Tuttavia, se si scopre che la logica responsabile dell'interazione con il database sta diventando molto complessa, può essere utile dividerla nel proprio servizio. Questo è praticamente sempre fatto in ambienti Big Data poiché la logica della programmazione del database è così complessa e coinvolgente.

Se tutto ciò che hai è una semplice web-app che non ha bisogno di nulla di più complesso di MySQL o Postgres, non mi preoccuperei ancora del Server App. Se si utilizza un framework decent web per il server Web (come Play, Django, Rails, ecc.), Il codice sarà abbastanza modulare da consentire lo scambio del livello DAO per un livello REST / HTTP per comunicare con un nuovo server applicazioni non dovrebbe essere troppo difficile.

È già stato detto che il server web può anche raddoppiare come proxy inverso. Di nuovo, se si scopre che questo diventa sufficientemente complesso lungo la strada per giustificare dando a quella logica la propria scatola, con tutti i mezzi. Ricorda che questa è una possibile direzione in cui l'app potrebbe andare in futuro quando stai programmando le cose in modo da non dover sbrogliare il codice non modulato per scomporre un server proxy dedicato.

Per un'architettura a 3 livelli, stai tentando (in parte) di scalare. Ciò significa che sarà possibile scaricare parte dell'elaborazione dal singolo database ad alcuni server delle applicazioni e scaricare l'elaborazione da essi su molti server Web. Ciò consente anche di scrivere codice per ogni livello specializzato, in modo che il server DB esegua solo il DB, i server delle app leggano solo (e memorizzano nella cache) i dati e applichino la logica aziendale, mentre i server Web gestiranno solo la presentazione del risultati ai clienti.

Ci sono altri motivi per creare un'architettura a 3 livelli come questa, la sicurezza è una delle ragioni principali: in tali architetture sicure il server Web è considerato il più probabile a essere compromesso e quindi viene eseguito in un ambiente con privilegi ridotti (ad es. accesso diretto al DB - se o quando qualcuno accede al tuo server web e può leggere qualsiasi tabella DB, allora tutte le tue password sono le loro.Se tutto ciò che può fare è fare una chiamata API al server delle applicazioni devono anche hackerare il app server).

È possibile creare tale architettura senza molti server fisici, eseguendoli su macchine virtuali o semplicemente creando ogni livello come servizio separato, ad es. il server web è uno, e il suo codice chiama un servizio che si troverà sul server delle app se ne hai uno, ma altrimenti è solo un servizio locale con cui comunichi usando lo stesso canale di comunicazione.

Per molti versi è facile concettualizzare questa architettura: se si utilizza un servizio di terze parti, si è già n-tier, il "server delle applicazioni" è qualsiasi servizio di terze parti che si consuma. Pertanto, se utilizzi un servizio di mappatura di Google per parte del tuo sito, è ovviamente in esecuzione su un server diverso e stai effettuando chiamate di rete per ottenere i dati combinati con i tuoi per creare una pagina. Sostituisci il servizio Google con il tuo che parla al tuo DB e hai un servizio a 3 livelli!

I proxy inversi sono generalmente una cosa di sicurezza, in quanto protegge il server web dagli aggressori - devono bypassare il proxy che dovrebbe essere difficile in quanto ha una superficie di attacco molto piccola. Un'architettura a 3 livelli spesso ha il server web svolgere questo ruolo in quanto non fa molto a parte generare HTML dai dati forniti dai servizi applicativi.