多租戶中間層架構

Question

我們正在開發一個「中間層」來替換現有的業務邏輯/數據訪問層。我們面臨的一個設計問題是，我們需要設計一個允許多客戶的數據庫和/或中間層作爲我們託管產品的一部分位於同一服務器上的方式。託管環境的數據庫模式和設置在這一點上是相當重要的，因爲它已經在生產中。實際上，在託管環境中的給定數據庫服務器上，每個客戶都有一個使用其唯一客戶ID命名的SQL Server實例。

我們正在試圖決定的是，是否從客戶端應用程序到Web服務，業務邏輯以及每個客戶對數據庫的數據訪問都有單獨的路徑，或者擁有單個共享實例其中數據訪問層負責從正確的SQL Server實例或兩者之間的某處獲取數據。通過一條單一的共享路徑，如果任何一條路由器停止運行，所有訪問它的客戶端都會死在水中。另一方面，對於每個客戶而言，個人的道路還有（看似）更多的維護，除了可能過於複雜？下面是我們正在考慮的兩個選項一個可怕的ASCII藝術圖片：

[Client]--|                |--[DB] 
[Client]--|                |--[DB] 
      |--> [Web Service] --> [Business Logic] --> [Data Access] ----| 
[Client]--|                |--[DB] 
[Client]--|                |--[DB] 

或者這樣：

[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 
[Client] --> [Web Service] --> [Business Logic] --> [Data Access] --> [DB] 

其中哪一個（或什麼-之間選擇）會比較好，爲什麼？

Answer 1

這是一個相當普遍的問題，所以我會給出一個相當一般的答案。我已經建立了類似的原則平臺在過去，我可以給你的唯一忠告是仔細考慮將建築分爲兩層：

• 完全通用框架，處理所有常見的通用操作
• 可定製的「客戶」特定圖層，您可以在其中包含任何不尋常的客戶特定功能。

也許很多客戶可以單獨使用通用框架，但是當客戶願意爲您付費時，您可以通過擴展來修改通用層。

通常我們通過非常標準的技術處理泛型和專業行爲的這種可擴展性和耦合 - 每個客戶的配置文件定義他們的處理「管道」，動態加載客戶程序集，大量使用接口，允許通用將操作委託給標準實現或運行時客戶特定實現的組件等等。

希望有所幫助。