針對單個代碼庫的服務器體系結構所需的建議多個子域（多租戶體系結構）MVC .NET。

Question

針對單一代碼庫的服務器體系結構所需的建議多個子域（多租戶體系結構）MVC .NET。

介紹 基於子域名，創建基於Web的應用程序，它將連接到不同的數據庫。 012k2k帳戶，將有大約100個用戶。

尋找最好的架構建議來處理這個問題。

描述 - 帳戶/子域計數將爲2K或更多。 - 每個賬戶將包含大約100個用戶。 - 數據庫將MSSQL，每個子域將有不同的數據庫連接。

我可否要求你幫/專家反饋如下問題，

問題

1. URL結構，將套房最適合上述要求的類型。 邏輯1或邏輯2或邏輯3，這是最好的？

   

2. 服務器如何能承受如此多的反應？這是否與.NET中的應用程序池相關？請在這方面提供更多建議。 2000 Subdomain X 100 Users = 2,00,000個請求，一個代碼庫可以處理這麼多請求？

3. 邏輯1或邏輯2或邏輯3，哪個最好實現？對其他人有什麼優勢？

4. 谷歌/ Facebook等處理單個域與多個servers.Is這是最好的行業標準？我們知道，邏輯1，我們可以爲每個子域設置多個應用程序池，這也適用於邏輯3嗎？

5. 考慮邏輯1和邏輯3，這是最好的，爲什麼？當Web服務器上的負載過重時，我們需要在當時添加另一個Web服務器，哪種邏輯最適合？

共享這被稱爲點，

1. 我們可以爲不同的子域添加不同的應用程序池。
2. APP服務器應該是高端服務器來管理這麼多的請求。
3. 當服務器上的負載/流量增加時，需要添加負載平衡器。
4. 需要一個最好的方法，昂貴的基礎設施也可以考慮。

Answer 1

URL結構是真的無關緊要在這裏（只要它是不「邏輯3」 - 只是不暴露在查詢字符串你的「數據庫名稱」）。但是，請注意，如果您轉到「每個客戶的子域」方式，則必須購買通配符SSL證書，而且這些證書的價格要高一些。另外，IIS 仍然是does not support通配符子域名，所以在設置時會出現怪癖。除此之外，任何一個選項都可以。

這些天，負載平衡器是非常必要的。另一方面，我不會投資「高端」硬件。一些中間服務器將綽綽有餘。你應該擔心的是獲得這20萬用戶。

關於數據庫架構，請參閱MSDN上的Multi-Tenant Data Architecture文章。基本上，沒有單一的正確答案。每個選項都有其自身的優點和缺點。

單個「代碼庫」（如在應用程序的單個實例中）可以根據需要處理儘可能多的數據庫。這裏唯一的限制是SQL Server本身。 Maximum Capacity Specifications for SQL Server表示「SQL Server每個實例的數據庫數量」的最大值是32 767，但是否是實用的是debatable。