4

您将如何设计托管的 Web 应用程序？我正在研究 Basecamp、Campaign Monitor、Freshbooks 等应用程序，用户可以在线注册并为他们托管应用程序。

  1. 您会使用 1 个大型数据库来存储所有客户的数据，还是会以不同的方式处理数据？你会使用超过 1 个数据库吗？你会为每个客户建立一个数据库吗？
  2. 您会为每个注册/客户复制代码库，还是使用 1 个代码库来处理所有客户？
  3. 还有其他我应该考虑的设计元素吗？
  4. 有没有讨论这个的网站或书籍？

编辑：我发现了一篇讨论多租户数据架构的 MSDN 文章：http: //msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_topic4

4

3 回答 3

2

请参阅 37signals——他们是该领域的专家，并且有很多文章回答了社区问题（应该出现很多像你一样的问题）。

高可扩展性 = 37signals 架构

问37signals：你们是如何处理信用卡的？

关于数据库的数量，来自 David Heinemeier Hansson 在你想知道什么？

一些技术答案……</p>

Lance，我们所有预定的计费操作都是自动化的。任何这样的事情都会让我们发疯。确保对失败的信用卡进行应急处理尤为重要。最后我看了一下，我相信我们有 5% 的费用因为信用卡过期、超过限额或关闭而被退回。一定要优雅地处理它。

我们只使用 Authorize.net 和一个单独的信用卡应用程序（在 Rails 中开发并通过 REST 由内部网络上的其他应用程序使用的小应用程序）来保证数字安全。

沃伦，我们在同一个数据库上运行免费和付费账户。每个应用程序一个数据库。每个帐户一个数据库通常是一个非常非常糟糕的主意。通常数据是相当标准化的，但我们绝对不相信它。我通常重视我的源代码而不是我的模式。因此，如果我可以通过弯曲模式获得更好/更漂亮的源代码，我通常会这样做。但是从规范化和非规范化开始，因为性能或代码结构需要它。

杰森，我们使用电子邮件发送短信。所有美国运营商都有一个 phone@carrier-gateway.com 网关。

Jake Good，啊，好“但它是否规模化”的问题。几年前我回答了这个问题。从那以后，我们什么都没有改变。我们每天管理数以百万计的动态请求，甚至不需要大量缓存（我们大多数应用程序中的大多数屏幕在每个用户的基础上都不同，因此传统的缓存方案更难应用）。

还有许多其他 Rails 应用程序管理着每天数千万的请求。所有人都或多或少地遵循相同的 Shared Nothing 方法。所有缩放高高的技术都在那里。这几乎不是一个交钥匙解决方案，但任何承诺的东西通常都充满了它。

于 2009-10-28T01:03:42.503 回答
2

如果您只谈论成千上万的客户（与数十万或数百万客户相比），那么差异非常小，除非您知道每个客户可能有数千行或更多行的表。那么你的设计可能会改变。

customer_id基于关系数据库的数据存储的正常设置将在大多数表上放置一个外键。然后只是不要向除该客户之外的任何人显示该数据（或者在他们以某种方式指示将明确权限授予其他人的情况下）。

不要太担心 RDBMS 扩展问题，直到看起来您可能开始在一个表中拥有数百万行。然后可能是时候研究分布式键/值存储了。但请记住，这类问题是很好的问题，因为这可能意味着您正在赚取大量现金。

即，当你来到它时，越过缩放桥。尽您目前的能力设计事物，否则，过早的优化是万恶之源。

于 2009-10-28T01:04:09.930 回答
2

我担任许多 SaaS 应用程序的顾问，因此看到了不同的架构。我建议：

  1. 为所有客户提供一个数据库。请务必设计好数据库，以便您拥有用户的主键，即您自己的唯一 ID。我已经看到一些混乱，其中设计有效（实际上不是，但它也可能）将电子邮件、电话号码等作为主键）。此外，不要最终将所有内容都扔到一个巨大的用户表中。

    1. 您需要在某个时候开始跟踪大量用户交互行为。为此，您可以使用 NoSQL 名称-值存储，然后开始将事件放入其中以供以后分析。或者，使用 MixPanel 或 KISSmetrics 之类的东西。

    2. 通过将行写入 KPI 表来跟踪每日 KPI，这样可以轻松查询一段时间内发生的事情。否则你最终会想问数据库的问题并发现这样做是一个巨大的查询。

拥有单个 SQL 数据库的一个关键优势是，如果您的营销人员知道 SQL（推荐！），那么他们可以直接查询它。如果你走 NoSQL 路线，那就更难了，然后营销开始做出通常是错误的假设，你会浪费大量时间基于这些假设走上错误的道路。

于 2012-12-10T17:53:53.893 回答