是否有专门针对拥有大量受众的网站的可扩展性最佳实践？

Posted 2023-02-23

【中文标题】是否有专门针对拥有大量受众的网站的可扩展性最佳实践？

【英文标题】：Are there any scalability best practices specifically for sites with huge audiences?

【发布时间】：2010-12-06 10:05:19

【问题描述】：

虽然之前曾在各种情况下提出过这个问题，但我找不到任何专门针对面向大量受众（例如数十万甚至数百万用户）的网站的信息。

在编写针对较小受众的网站时（例如，内部网托管的数据驱动型网站，可处理几到几千名用户），我们只倾向于在我们的项目预算/截止日期范围内遵循最佳做法 - 即开发人员成本，推出计划和可维护性对我们如何编写代码的影响比我们通常希望的要大得多。

有些东西也可以忽略不计（在某种程度上），例如交付时间、图像压缩/大小、带宽，因为 LAN 托管应用程序的性质往往意味着相对少量的财务成本（在合理范围内） ) 我们不必担心太多。

但是，如果要针对更广泛的受众群体，例如（希望）数百万用户的受众群体：

是否有无需担心的最佳实践（即，更多可以忽略更大的观众）？ 是否有任何应更严格遵守的做法？ 此外，是否有任何做法只有在您的观众达到一定临界质量时才会真正发挥作用[以及临界质量是多少]？即在专用网络上应用不会开始关注您的人为约束

到目前为止我遇到的例子是：

在 Google 上托管 jQuery 等代码库，因为它是从 Google 的 CDN 交付的，并且比您自己的服务器提供的服务速度要快得多。这也有助于降低交付网站所需的带宽成本。 在 CDN 上托管图片的原因与在其他地方托管您的 javascript 代码的原因相同。

【参考方案1】：

我会查看 YSlow 并遵循他们关于提高性能的建议。

【讨论】：

谢谢，他们的网站上有一些有用的提示可以参考。 +1

【参考方案2】：

我认为这里需要牢记三件事：

a) 你不会写下一个 twitter/youtube/facebook/ebay/amazon/whatever。它不会经常发生，所以它是 YAGNI 的一个大案例。

b) 如果您确实编写了其中一个，那么您将有机会多次重写该应用程序。

c) 从任何公开谈论过这些应用程序的架构类型中得到的唯一教训是，水平扩展是可行的方法。垂直最大化真的，真的很快。

另外，我认为在这些高大上，流程改进会变得更大。您将拥有大量的开发人员、严格的部署窗口和许多需要担心的问题。它最好是真正的脚本、自动化和可重复的。

【讨论】：

+1 表示 C，至于其他两点，我相信我会在不重复其他人的情况下犯足够多的错误......任何人都可以有一个想法，所以A对我来说有点过于失败主义了。

【参考方案3】：

我想这取决于压力“三角”的目标是什么：CAP（一致性、可用性和对分区的容忍度）。例如。当面临导致“P”的网络中断时，一个人只能有这么多的“C”。

如今，重点似乎更多地放在提供“良好的用户体验”上，这似乎取决于“产生结果的时间”（例如，在用户桌面上拥有完整的网页）：这转化为投资（其中其他东西）更多的是在“A”和“P”两侧，然后是“C”一侧。

更具体地说：花一些时间来决定 何时 为您的用户执行数据聚合，例如我可以在更长的时间段内聚合这些数据在重新计算另一个视图以推送吗？

当然，我只是勉强触及问题的表面。

【讨论】：

谢谢，我很欣赏这种洞察力。你有关于这个主题的推荐读物吗？

关于 CAP 的精彩演示：docs.google.com/…

@Jean-Lou Dupont：谢谢，我很欣赏这个链接。有时间我会跟进的。

【参考方案4】：

@jldupont - 刚刚查看了您链接到的演示文稿。我没有得到的一件事是，当您失去可用性以获得一致性和分区时，“分布式数据库”是如何成为示例场景的。 我认为对于分布式数据库，您会失去一致性。