單頁應用程序服務器分離問題

客戶端將通過ajax通過asp.net web api與數據庫交談的asp.net mvc網頁。

我的問題真的存在可擴展性。我應該從服務器分離客戶端嗎？即一個項目中的客戶端/前端代碼/視圖和另一個獨立項目服務器中的webapi。因此，如果一個服務器開始（服務器A）以最大負載/大小超出所有需要做的就是創建另一個服務器實例（服務器B），並且所有新客戶都將指向服務器B上的webapi。

或應該它被全部集成爲一個項目，並且隨着負載增加（動態雲縮放）而擴展SQL Server端的東西？

在將我們的帽子扔進戒指之前需要一些建議。

在此先感謝

來源

2012-07-12 Matt

從研究香港專業教育學院做過即時將所有雞蛋去放在一個籃子裏（保持客戶端和webapis在一個項目），並運行它在Windows Azure上的可擴展性。有什麼建議？ – Matt 2012-07-12 05:06:55

每個人都做什麼（MVC和WebAPI）？舉個例子。 – Aliostad 2012-07-12 08:44:23

我們採用了分離出API和單頁的應用程序的途徑。原因在於它迫使您將單頁面應用程序視爲另一個客戶端，這反過來導致API提供您需要完整客戶端的所有功能的API ...

在部署方面，我們堅持單頁應用程序作爲網站根與包含API部署的/ api應用程序。在前提下，我們可以使用應用程序請求路由或某些內容感知路由機制，以便在必要時將事情發送到不同的服務器。在Azure中，我們使用多個網站每個角色機制（http://msdn.microsoft.com/en-us/library/windowsazure/gg433110.aspx）並根據負載來擴展此角色。

似乎生活在同一個領域讓事情變得更容易，因爲您不必爲打擾JSONP或CORS的醜陋而煩惱！

乾杯，院長

來源

2012-07-12 12:51:14

嗨Dean，謝謝你的迴應。你可以擴展你的情況如何使用請求路由嗎？你不必擔心JSONP的原因是因爲它不是跨域的，這是對的嗎？ – Matt 2012-07-13 01:30:28

我們使用請求路由，讓'n'個服務器接受請求，然後根據URL轉發給適當的主機。例如。/API請求代理到API集羣，而網站內容請求則直接提供或代理到相關內容服務器。使用JSONP進行研究 - 我們發現它導致更麻煩的方式，因此有一個邏輯域服務於所有內容是有意義的。 – 2012-07-13 12:25:49

單頁應用程序服務器分離問題

回答

相關問題