2015-12-08 9 views
9

Ho un progetto ASP.NET MVC che aveva bisogno di essere ospitato su due server differenti. So che questo sembra strano ma questo è il requisito del mio cliente.Host progetto ASP.NET MVC in due server fisici

Nel dettaglio, avrò 2 carico server bilanciati

  • Web Server - esporre a pubblico (dominio punterà al IP del pubblico di questo server)
  • App Server - comunicare con interno infrastrutture (Active Directory, database, sicurezza, ecc)

Simple diagram

Sto pensando di creare un altro strato (API Web ASP.NET), in modo che il server web serva solo pagine HTML, il server app conterrà le logiche di business e esporrà endpoint per tutti i client (web, mobile) a chiamata. Il server Web comunicherà con App Server tramite servizi RESTFUL.

C'è un modo migliore di fare? Qualsiasi soluzione sarà molto apprezzata.

Grazie in anticipo,

risposta

5

questo è un modo abbastanza normale di fare le cose - Lasciate che i server web si concentrano sulla pubblicazione di pagine e lasciare che il server back-end fare il duro lavoro con la logica di business dell'applicazione. Se è fortemente utilizzato con un elevato throughput di dati, prenderei in considerazione la possibilità di creare tre livelli con server Web, applicazioni e database separati.

Web API è una scelta piuttosto buona per la comunicazione tra i due server, ma potrebbe valere la pena considerare WCF come alternativa se si scopre che è necessario andare oltre le operazioni REST di base. È un overhead più grande per farlo funzionare, e non è sicuramente per i deboli di cuore!

EDIT

Così che cosa è necessario fare è di spostare tutta la tua logica di business corrente fuori i controller esistenti e in un corrispondente insieme di controller Web API che sedersi sul secondo server. Se fai attenzione, dovresti riuscire a copiare i metodi del controller MVC direttamente nei tuoi controller API Web e aggiungere gli attributi di routing appropriati. Il tuo database (se ne hai uno) dovrà essere presente anche sul secondo server.

Una volta fatto, tutti i controller MVC eseguiranno le chiamate all'API Web in esecuzione sul secondo server. I controller MVC non dovrebbero eseguire alcun tipo di elaborazione sui dati oltre alle modifiche di base per renderlo piacevole (mantenere i controller puliti è comunque una buona pratica).

Questo dovrebbe darti un'idea di base di ciò che devi fare. Se hai bisogno di qualcosa di più specifico su una qualsiasi delle fasi, basta gridare e vedrò se riesco a elaborare.

+0

Capisco il vantaggio di questa architettura, ma in questa situazione, ASP.NET MVC non funzionerà (vista e controller sono strettamente accoppiati). Esiste comunque la possibilità di separare il progetto MVC senza modificare tutto? –

+1

Ah, vedo cosa stai cercando di fare ora. No, non puoi prendere un progetto MVC esistente e dividerlo, come dici tu i controller e le viste sono strettamente accoppiati. Aggiornerò la mia risposta con una spiegazione più dettagliata, ma sì, è necessario rimuovere la logica aziendale dai controller MVC. – Mourndark

+0

Quando si effettuano chiamate da controller MVC a controller Webapi, è necessario effettuare chiamate interne o chiamate di servizi Web? Ho anche problemi con l'autenticazione del modulo perché la logica di autenticazione corrente viene scritta nel livello MVC, ci vorranno così tanti sforzi per spostarlo nel livello WebAPI. Inoltre, avrei bisogno di implementare nuovamente la logica e di proteggere l'API (consentire solo la connessione dell'app di fiducia) per renderla più solida. C'è qualche idea? Grazie –

4

Stiamo utilizzando una struttura simile nel nostro progetto. Un livello di servizio espone le API REST che vengono utilizzate da più siti Web e app mobili. La bellezza di questa architettura è che tutte le complessità aziendali sono nascoste dietro le API, mentre il front end si occupa principalmente delle esigenze di presentazione.

Ma è necessario stare attenti a due cose mentre lo sviluppo di questa architettura:

1. Proteggere i punti finali (REST API) - Se avete intenzione di sviluppare applicazioni mobili che consumeranno le API allora si devono esporre gli endpoint attraverso il firewall e renderli accessibili a Internet. Una delle opzioni consiste nell'utilizzare una convalida del token al portatore per autenticare la richiesta. È possibile utilizzare il protocollo Oauth per proteggere gli endpoint.

2. Challenge serializzazione e la deserializzazione: Dal REST utilizza JSON come formato standard di trasferimento dei dati e JSON non è fortemente tipizzato, la sfida è quella di mappare i dati a modelli appropriati alle due estremità. Per risolvere ciò abbiamo creato un progetto comune per modelli e aggiunto a entrambi i progetti (api e web). Quando alla fine dell'API abbiamo serivizzato un modello, lo abbiamo deserializzato allo stesso modello nel progetto web. Hanno mappato perfettamente senza singhiozzi.

Spero che i suggerimenti sopra ti aiuteranno.

Problemi correlati