在两个物理服务器中托管ASP.NET MVC项目

Question

I have a ASP.NET MVC project that needed to be hosted on two different servers. I know this seems weird but this's the requirement from my client.

In details, I will have 2 load balanced servers

• Web Server - expose to public (domain will point to public ip of this server)
• App Server - communicate with internal infrastructures (Active Directory, Database, Security, etc)

I'm thinking of creating another layer (ASP.NET Web API) , so that the webserver only serve HTML pages, the app server will contains the business logics and expose endpoints for all clients (web, mobile) to call. Web Server will communicate with App Server via RESTFUL services.

Is there any better way to do? Any solution will be greatly appreciated.

Thanks in advance,

Answer 1

This is a fairly normal way of doing things - let the web servers concentrate on serving pages and let the back end servers do the hard work with the application business logic. If it's heavily used with a large data throughput, I would consider making it three tiers with separate web, application and database servers.

Web API is a pretty good choice for communication between the two servers too, but it might be worth considering WCF as an alternative if you find you need to go beyond the basic REST operations. It's a bigger overhead to get it running though, and it's definitely not for the faint-hearted!

EDIT

So what you'll need to do is move all your current business logic out of your existing controllers and into a corresponding set of Web API controllers which will sit on the second server. If you're careful, you should just be able to copy your MVC controller methods straight into your Web API controllers and add the appropriate routing attributes. Your database (if you have one) will need to sit on the second server too.

Once you've done that, all your MVC controllers will do is make calls to the Web API running on the second server. The MVC controllers shouldn't do any kind of processing on your data beyond basic tweaks to make it look nice (keeping your controllers clean is good practice anyway).

That should give you a basic idea of what you need to do. If you need anything more specific about any of the steps, just shout and I'll see if I can elaborate.

Answer 2

We are using a similar structure in our project. A service layer is exposing REST APIs which are being consumed by multiple websites and mobile apps. The beauty of this architecture is that all the business complexities are hidden behind the APIs whereas the front end mostly deals with presentation needs.

But you need to be careful about two things while developing this architecture:

1. Protecting the end points (REST APIs) - If you are planning to develop mobile apps that will consume the APIs then you have to expose the endpoints through the firewall and make accessible to the internet. One of option is to use a bearer token validation to authenticate request. You can use Oauth protocol to secure the endpoints.

2. Challenge on Serializing and Deserializing: Since REST uses JSON as a standard format of data transfer and Json is not strongly typed, the challenge is to map data to appropriate models at both ends. To solve this we created a common project for models and added to both the (api and web) projects. When at API end we serilized a model we deserilized it to the same model at the web project. They mapped perfectly without hiccups.

Hope the tips above will help you.