如何设计托管Web应用程序?

参考37个信号——他们是这个领域的专家,有很多文章可以回答社区问题(很多像你这样的人应该会提出)。

High Scalability = 37signals Architecture

Ask 37signals: How do you process credit cards?

关于数据库的数量,来自David Heinemeier Hansson What do you want to know?

一些技术答案

兰斯,我们所有的预定账单 操作是自动化的。什么都可以 那会让我们发疯的。 确保 应急处理到位 信用卡失效。最后一 看,我相信我们收费的5% 由于信用卡 已过期,超过限制,或 关闭。一定要处理好 优雅。

我们只使用authorize.net和 单独的信用卡申请(微型 在Rails中开发并由 内部网络上的其他应用程序 通过休息)保持数字 安全。

沃伦,我们有免费的和付费的账户 在同一数据库上。它是一个 每个应用程序的数据库。一个数据库 每个帐户通常是一个真正的, 真是个坏主意。通常数据是 相当标准化,但我们 绝对不信教。我 通常我的源代码比我的 图式。所以如果我能得到 通过弯曲更好/更漂亮的源代码 一个模式,我通常会这样做。但是 从规范化和非规范化开始 作为性能或代码结构 要求它。

杰森,我们用电子邮件发短信。全美国 运营商有 电话:phone@carrier-gateway.com gateway。

杰克很好,啊,很好的ol___ 它扩展了__问题。我回答的是 几年前。什么都没有 从那以后我们就变了。我们管理 千百万动态 每天请求,甚至没有 使用大量缓存(大多数 我们大多数应用程序中的屏幕 在每个用户的基础上是不同的,所以 传统的缓存方案更难实现 应用)。

还有很多其他的铁轨 应用程序管理数十个 每天数百万次的请求。所有 或多或少遵循相同的共享 没有办法。所有的技术 高高在上 那里。这可不是万能钥匙 解决方案,但任何承诺 就是说,通常都是这样。

如果您只谈论数千个客户(而不是数十万或数百万),那么差异非常小,除非您知道您的表可能每个客户都有数千行或更多行。那么你的设计可能会改变。

基于关系数据库的数据存储的正常设置将 customer_id 大多数表上都有外键。然后,不要将数据显示给除该客户以外的任何人(或者在某些情况下,他们以某种方式指示将显式权限授予其他人)。

不要太担心RDBMS的缩放问题,直到看起来一个表中可能有数百万行。然后可能是时候研究分布式密钥/值存储了。但请记住,这类问题是最好的问题,因为这可能意味着你赚了一大笔钱。

也就是说,当你来到这座桥的时候,要穿过它。尽你目前的能力设计事物,否则,过早的优化是万恶之源。

我是许多SaaS应用程序的顾问,因此看到了不同的架构。我建议:

1. 为所有客户提供一个数据库。一定要设计好数据库,这样你就有了一个用户的主密钥,这是你自己的唯一ID。我看到过一些混乱的地方,设计的有效性(实际上不是,但它也可能)使一些东西,如电子邮件,电话号码等作为主密钥。另外,不要最终把所有东西都扔到一个巨大的用户桌上。

   1. 您将希望在某个时刻开始跟踪大量用户交互行为。为此,您可以使用NoSQL名称值存储,并开始向其中抛出事件以供以后分析。或者,使用类似于混合板或亲吻的东西。

   2. 通过向KPI表中写入行来跟踪每日的KPI,使查询一段时间内发生的事情变得容易。否则,您将最终想要向数据库提出问题,并发现这样做是一个巨大的查询。

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