关注点的单页应用服务器分离答案

【问题标题】：Single Page Application Server Separation of Concern关注点的单页应用服务器分离
【发布时间】：2012-07-11 17:47:34
【问题描述】：

我正在为多租户企业系统整合基本框架。

客户端将是一个 asp.net mvc 网页，通过 ajax 通过 asp.net web api 与数据库对话。

我的问题确实与可扩展性有关。我应该将客户端与服务器分开吗？即一个项目中的客户端/前端代码/视图和另一个单独的项目服务器中的 webapi。因此，如果一台服务器（服务器 A）开始出现负载/大小峰值，那么只需创建另一个服务器实例（服务器 B），所有新客户都将指向服务器 B 上的 webapi。

还是应该将它们全部集成为一个项目，并随着负载的增加（动态云扩展）向外扩展 sql server 端？

在将我们的帽子扔进擂台之前需要一些建议。

提前致谢

【问题讨论】：

根据我所做的研究，我将把所有鸡蛋放在一个篮子里（将客户端和 webapis 放在一个项目中）并在 Windows azure 上运行以实现可扩展性。有什么建议吗？
各自做什么（MVC和WebAPI）？举个例子。

标签： sql-server asp.net-mvc client-server scalability asp.net-web-api

【解决方案1】：

我们采用了分离 API 和单页应用程序的路线。这里的原因是它迫使您将单页应用程序视为另一个客户端，这反过来会导致 API 提供完整客户端所需的所有功能...

在部署方面，我们将单页应用程序作为网站根目录，并使用包含 API 部署的 /api 应用程序。在前提下，我们可以使用应用程序请求路由或一些内容感知路由机制在必要时将内容发送到不同的服务器。在 Azure 中，我们使用每个角色机制的多个网站 (http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx) 并根据负载扩展此角色。

看起来生活在同一个域中使事情变得更容易，因为您不必为 JSONP 或 CORS 的丑陋而烦恼！

干杯，院长

【讨论】：

您好，院长，感谢您的回复。您能否详细说明在您的案例中如何使用请求路由？而你不用担心JSONP的原因是它不是跨域的，对吗？
我们使用请求路由，让“n”个服务器接受请求，然后根据 URL 转发到适当的主机。例如。对 /api 的请求被代理到 API 集群，而对网站内容的请求要么被直接服务，要么被代理到相关的内容服务器。关注 JSONP - 我们发现它会带来更多麻烦，因此让一个逻辑域为所有内容提供服务是有意义的。