構建「大型」Rails應用程序的最佳實踐

我的問題在於尋求最佳實踐，一般建議和洞察力，而不是針對特定問題的解決方案。構建「大型」Rails應用程序的最佳實踐

我在計劃一個我認爲相當大的Rails項目的早期階段。在最簡單的層面上，它爲目標用戶提供了一個餅乾CMS。因此，用戶註冊並選擇一個子域名，併爲CMS提供一個非常基本的網站。

因此整個應用程序大約有4個不同的「面」給它：

一個銷售網站上銷售的產品爲最終用戶 - www.myapp.com
中央管理區的工作人員可以登錄和管理帳戶等 - www.myapp.com/superadmin
用戶自己的網站 - subdomain.myapp.com
用戶的管理區/ CMS - subdomain.myapp.com/admin

所以我真正想要的是構建應用程序的最佳實踐。即應該將它們全部整合到一個巨大的應用程序中，還是應該將它分成兩個（或更多）更小的應用程序？

如果作爲一個應用程序部署，我可以看到有關路由的問題，因爲銷售網站和用戶的網站都需要一個根路徑集，另外我不希望爲銷售網站設置的路由可通過用戶的網站。任何事情都可以在Rails或Apache級別完成（mod重寫？），以確保沒有混合的路由？

如果拆分爲2個或更多應用程序，您如何獲得共享相同數據庫的應用程序？這是一個好主意嗎？分割應用程序是否有任何好處（例如隔離應用程序某個區域中的問題，而不是將所有內容都放下）？

我意識到這篇文章引發了很多不同的問題，但感謝您給我提供的任何建議和見解。

來源

2009-11-29 aaronrussell

好問題，我想聽聽人們對此的想法。 Rails 3被設置爲嵌入式應用程序，因此您可以將管理應用程序放入您的基本應用程序中，但我不確定在此之前要做的最好的事情是什麼。 – PreciousBodilyFluids 2009-11-29 21:25:49

好吧，既然沒有其他人發言，我鼓勵你去讀一下面向服務的體系結構。 Dan Chak的這本書Enterprise Rails提供了一些很棒的素材，你可以通過谷歌圖書閱讀大量的素材。試試第13章，here.我認爲它會讓你走上正軌。

來源

2009-11-30 05:24:11 PreciousBodilyFluids

我相信將您的疑慮隔離到單獨應用程序中的好處大於成本。我可能會開始只有2個應用程序（一個用於主站點和superadmin，一個用於客戶端站點和管理員），訪問相同的數據庫，但你可以做到這一點。4

缺點是你並不是真的因爲所有的應用都綁定到一個數據庫，所以具有隔離。您最終會遇到數據庫擴展問題，但從一個數據庫開始就可以啓動。稍後擴展的一個策略是添加客戶端站點和主站點應用程序使用的從屬數據庫，而管理應用程序使用主數據庫。這與緩存的TON一起會讓你非常滿意。

讓多個rails應用程序訪問一個db沒有任何問題，但是您需要一種方法來在應用程序之間共享通用代碼。大部分是您的模特。我之前通過將我的所有模型扔在一個作爲git中的子模塊或作爲svn中的外部模塊分享的插件中完成。擁有單獨的應用程序將使每個應用程序變得更小，更易於維護

但是，您在哪裏保留遷移？你在哪裏測試你的模型？我會選擇superadmin應用程序。此外，您對模型或模式進行了更改，現在您必須檢查2-4個應用程序並確保它們仍然可以正常工作！

更好的隔離，通過Web API（SOA）分離數據庫和應用程序間通信，您不必擔心這一點。 SOA我認爲是一定要走的路，但是當你第一次開始時，SOA可能爲時過早。

無論如何，擁有單獨的應用程序可以爲您設置SOA，但您不必跳過單個數據庫即可啓動。

來源

2009-11-30 06:58:48

感謝您的全面解答。儘管有一兩個人不同意關於分割應用程序，但我很欣賞你答案中的細節。有一次問題：如果模型等被保存在一個插件中，那麼這是否使用rails生成器來創建模型和遷移？ – aaronrussell 2009-11-30 11:41:40

不排除生成器，但您有額外的步驟將生成的代碼移入插件。生成，破解模型，讓它工作，然後將它移入你的插件。對於遷移，您可以使用一個應用程序執行所有遷移。其他應用程序在遷移後必須更新其schema.rb文件（rake db：schema：dump）。 – 2009-11-30 16:31:47

我看到分離成幾個應用程序的最大問題是您失去了靈活性。如果將來以前的管理任務（例如上傳一種文件類型）成爲「用戶任務」，會發生什麼？您必須將代碼從一個應用程序移到另一個應用程序。

我會把所有的東西放在單個應用程序上 - 並使用角色來過濾每個用戶可以看到和做的事情。開始時可能會有點困難，但在不久的將來會有所收益。

查看授權框架，如declarative_authorization或cancan。

來源

2009-11-30 08:33:25 kikito

我看到你面臨的問題是，試圖建立一個應用程序，它將有不同的子域，所以account_manager插件可以解決你的問題。

如果您的應用程序足夠大以維護而不是將它們拆分爲兩到三個將是個好主意，通過restfull資源可以使您的應用程序彼此交談等等。

雖然如果你想在一個數據庫中使用它們，那很容易在rails中使用establish_connection。

我認爲你可以在三到四個不同的應用程序中分割應用程序，其中一組集羣將處理每個應用程序請求，所以速度會很好。你也可以在一個應用程序中捆綁類似的功能，以確保維護它們很容易。

http://www.railslodge.com/plugins/1113-subdomain-fu

來源

2009-11-30 09:15:09

我會捆綁到所有這些相同的應用程序，因爲你不會在所有的應用程序來複制類（模型，插件等）。另外：運行4個應用程序意味着你將有4個進程消耗內存，因爲它們已經加載了4個單獨的Rails堆棧。

將其編譯爲一個應用程序可消除此問題。銷售網站和用戶網站之間的問題必須有不同的根源才能解決，as mentioned earlier，作者：subdomain_fu。讓我從一個應用程序，我有一些示例代碼擴展：

map.with_options :conditions => {:subdomain => 'logs'} do |admin| 
    admin.resources :channels do |channel| 
    channel.resources :logs 
    end 
    map.root :channels 
    map.connect ':id', :controller => "channels", :action => "show" 
end

正如我們在這裏看到的，:conditions爲with_options方法設置:subdomain是logs這意味着什麼進來的logs.mysite.com將滿足這些條件並因此被路由。

現在進一步在此路由文件我把一切都以類似的其他塊包裹起來：

map.with_options :conditions => {:subdomain => nil} do |admin| 
    # shebang! 
end

一切要mysite.com會去這些路由。

最後，將它編譯成一個超級超級應用程序將消除數據庫共享問題。

來源

2009-11-30 10:45:18

謝謝你。 subdomain_fu確實看起來像解決了我對路線的主要擔憂。你可以分配路由到通配符子域嗎？如： map.with_options：conditions => {：subdomain => *} do | site | – aaronrussell 2009-11-30 11:44:56

「最後，將其全部編譯成一個超級超級應用程序將消除數據庫共享問題。」並在此過程中創建一系列其他問題。 – maletor 2014-10-02 02:46:32

@maletor當我發佈這個答案時，引擎並不是什麼東西。六邊形/服務式開發（或任何你想給它的名字）都不是。雖然建議不再相關，但我仍然認爲它與發佈時間相關*，因此我選擇（在這種情況下）將我的原始答案留在它的所有未經編輯的榮耀中。如果人們在這裏遵循建議，那麼這是他們運氣不好。他們應該知道更好地遵循5歲以上職位的建議。 – 2014-10-02 03:58:10

就我的研究發現，大多數高規模的公司都會選擇帶有多個數據庫的SOA。以下是有關Linked In和EBay如何考慮的一些信息的鏈接。爲了迴應PreciousBodilyFluids，我強烈推薦Dan Chak編寫的Enterprise Rails圖書。

來源

2011-01-13 17:16:49 Tony

構建「大型」Rails應用程序的最佳實踐

回答

相關問題