高流量网站的推荐结构[关闭]

Posted 2023-02-24

【中文标题】高流量网站的推荐结构[关闭]

【英文标题】：Recommended structure for high traffic website [closed]

【发布时间】：2011-05-18 00:32:47

【问题描述】：

我正在重写一个大型网站，需要非常坚固的架构，这是我的几个问题，请原谅我将苹果和橙子以及可能还有猕猴桃混合在一起：) 我做了很多研究，结果完全糊涂了。

主要问题：您会采用哪种方法来构建一个有望在各个方面发展的大型网站？

单一入口点，对数据库中的数据进行分页，通过将 GET 变量与数据库条目关联来拉取 (?pageid=whatever)

单一入口点，页面数据位于不同文件中，基于 GET 变量包含（?pageid=whatever 将包含whatever.php）

MVC（好吧，伙计们，我完全赞成，但除了检查那里的所有教程和框架外，无法掌握这个概念，他们是否将“视图”存储在数据库中？在我看来，如果您有 1000 个相同类型的页面，它们可以由 1 个模型塑造，但我仍然需要有 1000 个“视图”文件？）

PAC - 这对我来说听起来更合乎逻辑，但没有找到太多资源 - 如果这是一个好方法，你能推荐任何书籍或链接吗？

DAL/DAO/DDD - 在发布问题之前，我通过认真阅读堆栈溢出来了解这些术语。不确定它是否属于此列表

坐下来创建我自己的架构（如果没有人在这里启发我，可能会这样做：）

没有提到的东西……

谢谢。

【问题讨论】：

我是 MVC 设计模式的忠实拥护者，这里有一个教程，我认为可以澄清你的一些问题。 php-html.net/tutorials/model-view-controller-in-php

如果您打算制作自己的架构，请给我打电话 =D 在对 Drupal 非常失望之后，我一直在考虑制作更强大的东西。如果有人是 Drupal 的粉丝，也请随时与我联系。我很乐意分享我的糟糕经历。如果您想直接找出我的问题，请尝试为具有可变列的表创建内容类型。

您在这里提到的所有这些事情都与处理高流量无关。你可以选择任何你想要的东西，虽然有些点很蹩脚。还要记住，99% 的人在这里说“MVC”这个词，根本不知道它是什么。

仅仅因为 MVC 不是 PHP 原生的并且实现方式各不相同，并不意味着它不是一个好主意。尤其是抽象视图是一个非常好的主意。紧随其后的是抽象对数据的访问和逻辑操作的有用性。

MVC 是一种编写代码的方式。它与语言本身无关，而是一种您纠正代码以便执行的方式。您可以在任何语言中正确使用 MVC 模式。

【参考方案1】：

您提到的任何项目都不能最好地解决网站的可扩展性/可用性（iow。高流量）。尤其是第 1 点和第 2 点；将页面定义存储在数据库中是绝对不行的。 MVC 和其他类似模式更多是为了代码清晰和维护，而不是为了可扩展性。

一个重要的缺失信息是您期望每秒的并发命中数是多少？有时，没有建立高流量网站的人会对实际上构成“可扩展性噩梦”的点击率感到惊讶。

有一些关于如何设计可扩展架构的书籍，因此 SO 帖子将无法与主题公正，但一些非常***的概念，没有特定的顺序，是：

最好首先通过查看基于硬件的解决方案来处理可扩展性。配备一系列 SSD 磁盘的强大服务器可以发挥很大作用。 将任何可以是静态的东西设为静态。尽可能多地从 Web 服务器而不是数据库提供服务。例如，网站上的许多页面从数据库中动态生成数据列表，这些数据存储很少或从未真正改变。 不经常更改的缓存输出，并调整缓存刷新。 将动态页面构建为无状态或异步。查看 CQRS 和事件溯源，了解有利于/促进扩展的模式。 调整您的查询。数据库通常是最大的瓶颈，因为它是共享资源。许多网络应用开发者使用 ORM 来创建糟糕的查询。 调整您的数据库引擎。备份、复制、扫描、日志记录，所有这些都只需要你引擎的一点资源。对其进行调整可以产生更快的数据库，从而为您从横向扩展中争取时间。 减少来自客户端的 HTTP 请求数。每个 HTTP 连接都有开销。检查您的页面，看看您是否可以增加每个请求中的负载，以减少单个请求的总数。

此时，您已经优化了一台服务器上的行为，您必须“向外扩展”。现在，事情变得非常复杂非常快。各种类型的负载平衡场景（分片、DNS 驱动、哑平衡等），在不同 DB 上分离读取数据和写入数据，使用 Google Apps 等虚拟化解决方案，将静态内容卸载到大型 CDN 服务，使用像 Erlang 或 Scala 这样的语言并并行化您的应用程序等...

【讨论】：

re #4，不能过分强调memcached 的优点，其次，APC 有助于解决 #2（避免重新编译等）

实际上，在#2 中，该技术涉及专门且完全绕过活动缓存子系统。我已经构建了具有来自数据库数据的完全静态页面的站点，其中该页面的创建是由表的更新触发的。除了创建相关页面外，永远不会读取该表。如果表格几个月没有更新，则相关页面保持不变。缓存总是涉及一定数量的“轮询”，这只是更多的资源命中。

哇！我真的要感谢在这里发帖的每一个人，这么多非常棒和有用的信息。我有一个关于 alphadogg 的问题，关于“将页面定义存储在数据库中是绝对不行的”——这是否也包括 html 代码？因为我正在开发的网站将有 CMS，带有一种所见即所得的编辑器，这意味着会有一些 html 标签。

“页面定义”是指 HTML。如果您将内容存储在给定的 mypage.htm 中，以及所有关联的 mypage.css、mypage1.inc、mypage2.inc 等页面作为数据库中的记录，那么您在可伸缩性方面倒退了一步。缓存是避免进入数据库的实时方式。但是，即使缓存仍然有开销和资源消耗。尽可能多地制作静态，即使这意味着有时您必须将数据库数据操作到静态页面中。

顺便说一句，该系统不是 MVCed、DDDed 或 IOCed，这些天被视为宗教。这些都不会使它明显更快。这是很好的程序代码。重新思考了真正的瓶颈。

【参考方案2】：

单一入口点，页面中的数据 数据库，通过关联 GET 拉取 带有数据库条目的变量 (?pageid=whatever)

维护的潜在噩梦。如果您的团队超过 2-3 人，也可以用于开发。您需要创建一套严格的规则让每个人都遵守 - 如果使用 MVC，这些努力会更好。 2 也是一样。

MVC（好吧，伙计们，我完全赞成，但是 不能理解这个概念 检查所有教程和框架 在那里，他们是否将“视图”存储在 数据库？在我看来，从例子 如果你有 1000 页相同的 它们可以由 1 个模型塑造， 但我仍然需要 1000 “视图”文件？）

这取决于有多少页面布局。大多数 MVC 框架允许您使用结构化视图（即主页面视图、子视图）。将视图视为网页的 HTML 模板。您需要多少个模板和子模板就是您将拥有多少个视图。我相信大多数网站最多可以有 50 个主视图和 100 个子视图 - 但这些都是非常大的网站。看看我运行的一些网站，总共有 50 次浏览。

DAL/DAO/DDD - 我了解了这些 通过认真阅读条款 发布前堆栈溢出 题。不确定是否属于 这个列表

确实如此。如果您需要元视图或元模型，DDD 非常棒。假设所有模型在结构上都非常相似，但仅在使用的数据库表上有所不同，并且您的视图几乎 1:1 映射到模型。在这种情况下，现在是 DDD 的好时机。一个很好的例子是一些 ERP 软件，你不需要为所有的数据库表单独设计，你可以使用一些统一的方式来完成所有的 CRUD 操作。在这种情况下，您可能会摆脱一个模型和几个视图 - 所有这些都是在运行时使用元模型动态生成的，该元模型将数据库列、类型和规则映射到编程语言的逻辑。但是，请注意，构建高质量的 DDD 引擎确实需要一些时间和精力，以使您的应用程序看起来不像是被黑掉的 MS Access 程序。

坐下来创造我自己的 架构（如果没有人可能会做 在这里启发我:)

如果您正在构建一个面向公众的网站，那么您很可能会使用 MVC 做得很好。一个很好的起点是查看 CodeIgniter 视频教程。它帮助我了解 MVC 的真正含义以及如何使用它，比我阅读的任何 HOWTO 或手册更好。而且它们总共只需要 29 分钟：

http://codeigniter.com/tutorials/

享受吧。

【讨论】：

MVC 和 DDD 与处理高流量的能力没有直接关系。

引用 OP：一个有望在各个方面发展的大型网站。这意味着维护很重要。 MVC 和 DDD 都与此直接相关。处理高流量的能力完全不同，应该研究 PageSpeed、YSlow、PHP-APC、nginx、负载平衡、mysql 优化等东西，但这不是 OP 所要求的。也许他应该稍微改变一下问题的标题。

【参考方案3】：

我建议使用一些野外的 web mvc 框架创建一个模拟应用程序，然后选择一个，你的开发足够顺利。如果您想掌握 mvc 的概念并准备好轻松地将新功能添加到您的 Web 中，那么在坚实的基础上建立您的代码至关重要。

【参考方案4】：

如果您正在创建一个“大”网站并且没有完全掌握 MVC 或 Web 框架，那么 CMS 可能是更好的途径，因为您可以使用您认为合适的插件来扩展它。通过这条路线，您可以更多地担心内容和页面结构，而不是平台。只要您选择合适的 CMS。

【讨论】：

CMS 对于高流量网站来说并不是一个好主意。

不同意。 backendbattles.com/backend/drupal

如果缓存可以在 CMS 中实现，或许它可以很好地扩展。

【参考方案5】：

我是 MVC 的粉丝，因为我发现当一切都有一个位置并且很好并且分开时，扩展您的团队会更容易。这需要一些时间来适应，但掌握它的最简单方法是潜入。

也就是说，一定要查看您当地的图书馆，看看他们是否有 O'Reilley 关于缩放的书：http://oreilly.com/catalog/9780596102357，这是一个很好的起点。