RoR SaaS應用程序的體系結構

Question

我已經完成了相當數量的基礎RoR工作，但在縮放和運行多個應用程序方面並沒有真正面對太多問題。

我正在爲客戶構建一個應用程序，我希望向類似行業的其他用戶推廣這個應用程序，但我正在爲高層架構而苦苦掙扎。似乎沒有必要爲每個客戶端運行一個完全獨立的應用程序實例，但我不知道如何爲各種用戶加載不同的配置/佈局/功能。我不希望每個應用程序都具有極高的流量，因此每個應用程序擁有獨特的實例/數據庫似乎都是一種浪費。但是，每個實例可能都需要自己的CSS以及潛在的可用功能的不同配置。

這是可以使用子域輕鬆完成的事情嗎？我可以根據這個加載不同的配置嗎？有沒有人對37信號應用程序如何根據帳戶管理不同的配置有所瞭解？

Answer 1

免責聲明

確保您實際上能夠向市場推出你寫給其他客戶的應用程序。你有沒有和你的客戶簽訂合同？如果是這樣，他們很可能擁有您正在編寫的代碼的權利，在這種情況下您將違反您的合同。

---

在維基百科上有關於Multitenancy的非常好的文章，你應該閱讀。它會回答你很多問題，並讓你思考你的策略。我的建議是以這樣的方式構建應用程序，以便您可以支持多租戶，因爲在事實之後將其更加困難。

除了可能通過更改樣式表的設置完成的配色方案之外，37s應用程序不允許進行任何自定義。例如：

<%= stylesheet_link_tag(@tenant.style.name) %> 

您將加載基於子域租戶：

before_filter :load_tenant, :if => :tenant_request? 
def tenant_request? 
    request.subdomain.present? && !request.subdomain == 'www' 
end  

def load_tenant 
    @tenant = Tenant.find_by_name(request.subdomain) 
end 

如果你希望能夠擁有的功能，你可以打開和關閉的最簡單的方法可能是添加一個位掩碼（有一個gem for bit masks），它允許您查詢可用的特徵。這不會超過一定數量的功能，但會是一個好的開始。你會最終視圖代碼，如：

<% if tenant.has_feature?(:messaging) %> 
    <li><%= link_to 'Messages', messages_url %></li> 
<% end %> 

確保無論選擇你做，你做的工作最簡單的事情。

Answer 2

當我們正在爲我們的應用程序相同的決定，我們認爲一些事情......

首先，我們考慮的複雜性。當您開始將多個客戶添加到同一個數據庫時，您需要考慮如何分段數據。如果你已經爲一個客戶編寫了應用程序，那麼你可能不必太擔心這一點。在很多情況下，這些問題都源於核心數據模型，這將導致重構（如果不是全部重寫）。

此外，你永遠不會逃避這種複雜性。特別是在面向企業的應用程序中，將一位客戶的數據公開給另一位客戶可能是致命的。你總是需要添加額外的代碼和很多額外的測試來保護你自己。

其次，我們考慮成本。當我們認爲我們可以在同一個RDS實例中的同一Amazon EC2實例上使用自己的Amazon RDS數據庫在自己的Rails實例中運行多個客戶時，成本變得非常有吸引力。由於我們有一個面向企業的應用程序，並且很快就不會有超過200個客戶，所以我們可能在3 - 5年的時間內談論幾千美元的額外託管成本。

當我們比較的成本與複雜性，我們認爲保持在自己的情況下，每個人都非常值得理論結垢的問題。

這種方法的缺點是您必須確保能夠跟上維護，監控和升級多個實例。一些簡單的腳本和工具，如廚師可以在這裏走很長的路。