設計決策 - 擴展基於Web的應用程序的體系結構

Question

這個問題是關於設計決策的。我目前正在開發一個網絡項目，該項目將有4萬用戶，並且在幾個月內預計將增長5千萬用戶（儘管不是併發用戶）。我想要有一個可以輕鬆擴展而不需要太多努力的架構。

爲了解釋，我想使用一個微不足道的場景。比方說，用戶實體和服務，如CreateUser，AuthenticateUser等，是頁面控制器的簡單方法調用。但是，一旦流量增加，例如，認證用戶（或與用戶實體相關的這類服務）必須被移出到不同的內部服務器以傳播負載。但是同時在用戶數爲40K時通過網絡使用RPC調用會變得過度。

我的建議是最初使用IPC，當我們需要擴展時，我們可以間接切換到基於TCP的RPC調用，以便它可以輕鬆擴展。例如，我指的是System.IO.Pipes.NamedPipeStreamServer開頭，稍後再轉到TcpListener。

如果我們有適當的設計可以封裝上述方法，那麼我們很容易將服務擴展到多個網絡服務器，但同時避免在用戶數較少時進行網絡調用。

這是最好的方法嗎？任何建議都會很棒..

注意：數據庫縮放定義爲第二階段優化，因此我們已經制定了適當的架構設計，以便在流量增加時輕鬆分區數據。主要的瓶頸將是這段時間內的應用程序服務器。

Answer 1

如果你打算做的是（如果我正確地讀了它的話）將認證和授權工作劃分給中央服務器，那麼我認爲如果你嘗試去做，你會發現可伸縮性方面的問題使用命名管道甚至低級別的TCP套接字。沒有理由不能通過常規Web服務甚至基於TCP通道的WCF服務訪問這些內部服務器。

我會走這條路線的原因是因爲調用無狀態Web服務（ASMX或WCF）將允許您使用「auth和auth」（身份驗證和授權）服務器以及用戶管理服務器（createuser等）在農場。因此，隨着您對這些服務的訪問量的增加，您可以擴展響應這些調用的服務器數量，而無需更改客戶端代碼。

Answer 2

根據我的經驗，「你現在不需要它，所以不要在上面浪費精力」和「這裏有龍」之間總是存在一種張力。

當需求出現時，您的縮放策略是使用特定的remotng技術將工作片段卸載到其他主機。聽起來像它可能工作。 [順便說一下，另一種方法是讓同一事物具有許多並行實例，因此將所有事物保持在本地 - 我的直覺是，這可能會更好。但讓我們堅持你的計劃，現在...]

我的一般建議是早期攻擊風險。因此，在這種情況下，您打算在將來使用遠程技術卸載一些工作。增加這個新的（對你的系統）技術將有（至少）兩個影響：

1. 新的故障模式
2. 延遲增加

哦，還有的（admitedly不太可能）可能性遠程控制策略不起作用！您可能看不到您期望的擴展收益。表現非常不直觀。

所以我在這裏看到風險，我想要解決這個風險現在。即使沒有必要，我會立即做遠程處理。然後，您將對所有性能進行測試，測試增加的延遲時間以及測試失敗模式的所有彈性。當壓力關閉時，你正在做這件事，而用戶人數很少。您也可以對實際的可伸縮性進行一些測試。

Answer 3

在我的一個旅遊行業項目（每天約100萬點擊）中，我們有一個單獨的auth服務器場。當時大約有四臺負載均衡服務器。我們的業務層稱爲認證Web服務（asmx），傳遞用戶憑證並獲取XML結果。如果用戶數量增加，我們可以進一步擴展auth場。通過http（在Intranet上）使用Web服務的恕我直言，給予比TCP更多的性能好處。