虽然之前已经在各种情况下提出了这个问题，但我找不到任何专门针对大量受众群体的网站的信息 - 例如，数十万甚至数百万用户的数量。
在编写面向较小受众群体的网站（例如内部网托管数据驱动网站，处理从几个到几千个用户）时，我们只倾向于遵循项目预算/截止日期范围内的最佳做法 - 即开发者成本，推出时间表和可维护性对我们编码事物的方式产生了更大的影响。
有些事情也可以忽略不计（到某一点），例如交付时间，图像压缩/大小，带宽，因为LAN托管应用程序的性质往往意味着相对较少的财务成本（在合理范围内） ）我们不需要太担心。
然而，在寻找更广泛的受众时，例如（希望）数百万用户的受众群体：
到目前为止我遇到的例子是：
答案 0 :(得分：3)
我认为这里要记住三件大事：
a）你不会写下一个twitter / youtube / facebook / ebay / amazon /等等。它不会经常发生，因此它是YAGNI的一个大案例。
b）如果您碰巧写了其中一个，那么您很可能会有机会多次重写该应用程序。
c）只有公开谈论这些应用的任何体系结构类型的对象课程都是横向扩展是要走的路。垂直最大化真实，快速。
另外，我认为在这些崇高的规模上，流程改进会变得更大。您将拥有大批开发人员，严格的部署窗口和许多需要担心的盒子。它最好是真实的脚本，自动化和可重复的。
答案 1 :(得分：3)
我想这取决于人们对压力“三角形”的目标：CAP（一致性，可用性和对分区的容忍度）。例如。当遇到导致“P”的网络中断时，人们只能拥有这么多“C”。
如今，似乎重点在于提供“良好的用户体验”，这似乎取决于“结果的时间”（例如，在用户的桌面上有一个完整的网页）：这转化为投资（其中）其他事情）更多关于“A”和“P”方面，然后是“C”方。
更具体地说：花一些时间决定何时为您的用户执行表示层的数据聚合，例如我可以在较长的时间段之前汇总这些数据重新计算另一个要推送的视图吗？
当然，我只是在解决问题的表面上。
答案 2 :(得分：1)
我会查看YSlow并遵循他们关于提高效果的建议。
答案 3 :(得分：0)
@jldupont - 只是查看了您链接到的演示文稿。我没有得到的一件事是，当您失去可用性以获得一致性和分区时，“分布式数据库”是一个示例场景。 我认为对于分布式数据库，您会失去一致性。