您將如何設計託管的Web應用程序？我正在尋找像Basecamp，Campaign Monitor，Freshbooks等應用程序......用戶可以在線註冊併爲他們託管應用程序。如何設計託管的Web應用程序？
編輯： 我發現討論的多租戶數據架構的MSDN文章： http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4
參考37signals的 - 他們是這方面的專家，有很多的文章，他們回答問題的社區（很多人喜歡你的）。
High Scalability = 37signals Architecture
Ask 37signals: How do you process credit cards?
在問候的數據庫，由戴維·海因梅耶爾·漢臣數What do you want to know?
一些技術解答...
蘭斯，我們的所有調度結算 操作自動化。任何會使我們瘋狂的東西。 確保 對於發生信用卡失敗的應變處理 尤其重要。最後我在 看來，我相信我們的5％的收費 反彈，由於信用卡 已過期，超過限額或 關閉。一定要妥善處理 。
我們只是使用Authorize.net和 獨立的信用卡申請（微 應用程序通過REST內部網絡 在Rails的開發和使用由 其他應用程序），保持數字 安全。
沃倫，我們運行免費和支付帳戶 在同一個數據庫。每個應用程序有一個 數據庫。一個數據庫 每個帳戶通常是真的， 真的壞主意。通常數據是 相當規範化，但我們是 絕對不是宗教的。 I 通常將我的源代碼重新定義在我的 模式中。所以如果我能通過彎曲 模式獲得更好/更漂亮的源代碼，我通常會這樣做。但 從規範化和非規範化 開始，因爲性能或代碼結構 要求它。
傑森，我們使用電子郵件短信。所有美國 運營商都有 [email protected]網關。
傑克好，啊，好的'但是它確實 它規模'的問題。幾年前，我在 回答說。自那時以來， 沒有任何變化。我們管理 數以百萬計的動態 請求中的每一天，甚至沒有 訴諸多少緩存（最 屏幕在我們的大多數應用 的是在每個用戶的基礎不同，所以 傳統的緩存方案更難 適用）。
還有很多其他Rails 應用程序在那裏管理數十萬個日常請求的數十個 。全部 或多或少都遵循共享 沒有辦法。所有的技術 爲高標準和高標準在那裏出 。這幾乎不是交鑰匙解決方案，但承諾 的東西通常只是充滿了它。
如果你只談論數以千計的客戶（相對於成千上萬或數以百萬計），那麼除非你知道每個客戶可能有成千上萬行的表或者更多，否則這種差異是非常小的。那麼你的設計可能會改變。
基於關係數據庫的數據存儲的正常設置將在您的大多數表上放置一個customer_id外鍵。然後，只要不向該客戶以外的任何人展示該數據（或者在他們以某種方式表明明確許可授予其他人的情況下）。
不要太擔心RDBMS縮放問題，直到它看起來像你可能開始在一個表中有數百萬行。那麼可能是調查分佈式密鑰/值存儲的時候了。但請記住，這樣的問題是一個很好的問題，因爲這可能意味着你需要大量現金。
即，當你到達它時，穿過縮放橋。根據你當前的能力來設計事物，但否則，不成熟的優化是所有邪惡的根源。
我是一些SaaS應用程序的顧問，所以看到了不同的體系結構。我推薦：
爲所有客戶提供一個數據庫。一定要很好地設計數據庫，以便爲用戶提供一個主鍵，這是您自己的唯一ID。我已經看到了一些混亂，其中設計的有效性（不是實際上，但它可能有）使得諸如電子郵件，電話號碼等作爲主鍵）。另外，不要把所有東西都扔進一個巨大的用戶表中。
你會想在某個時刻開始跟蹤大量的用戶交互行爲。爲此，您可以使用NoSQL名稱 - 值存儲，並開始將事件投入其中以供以後分析。或者，使用諸如MixPanel或KISSmetrics之類的東西。
通過將行寫入KPI表，可以輕鬆查詢隨時間發生的事件，從而跟蹤每日KPI。否則，你最終會想問問db的問題，並發現這是一個巨大的查詢。
具有單個SQL數據庫的一個重要優點是，如果你的營銷人都知道SQL（推薦！），那麼他們可以直接查詢。如果你走NoSQL路線，那就更困難了，然後營銷開始做出通常是錯誤的假設，並且基於這些假設，你浪費了很多時間走錯了路。
如果我託管它，我會如何設計它？ – 2009-10-27 22:04:40
我一次託管一個客戶的應用程序，但現在我想知道如何設計它，以便我可以託管許多客戶，同時仍然保持可管理性。我不太瞭解如何爲成百上千的客戶制定應用規模。 – dtc 2009-10-27 22:22:39