对于大型 Web 应用程序架构有什么建议吗?

对于大型 Web 应用程序架构有什么建议吗?

这个问题很大:)我们用 LAMP 运行一个网站,规模不大,5 台 Web 服务器,带 LVS 负载均衡,3 台 MySQL 服务器,带复制和读写分离,我们使用 Memcached 进行缓存和一些全文搜索工具。到目前为止,它运行良好,因为我们目前没有很大的流量。

但当用户快速增长时,我们将不得不扩展我们的架构以满足需求。也许会引入分布式文件系统和数据库(以及并行计算?),以及一些集群和维护技术(如 Gearman 和 Pshell)。

网上有一些文章我可以参考。但我真的需要一些实践经验来切实有效地准备这个问题。

答案1

扩展 Web 应用程序和支持基础架构的方法有很多。Cal Henderson 就此主题写了一本好书,名为“构建可扩展网站”。这本书基于他在 Flickr 上的经验。除非你缓慢地发展,否则你会遇到许多其他人遇到的相同类型的增长问题。与许多其他主题一样,扩展是一段旅程,而不是目的地。

第一步是让一切都可重复、可测量、可管理。可重复是指使用 FAI 或 kickstart 等工具安装操作系统,并在安装基本操作系统后使用 puppet 或 cfengine 等工具配置机器。可测量是指使用 cacti、cricket 或 ganglia 等工具监控集群当前的运行情况。不仅要测量平均负载,还要测量呈现页面或处理请求所需的时间。刚开始时,这两项似乎都不重要,但应该在系统因负载而崩溃之前告诉您,并且可以很容易地一次添加 10 台或 100 台机器。根据数据而不是猜测制定增长计划。

可管理意味着将工具部署到位,以便您自动生成和测试尽可能多的配置。从现有内容开始,然后不断扩展。如果您将机器信息存储在数据库中,那很好。如果没有,您可能有一个可以导出的电子表格。如果还没有,请将您的配置放入某种源代码控制中。从数据库自动创建配置可以让您在增长时压力更小。在服务器上上线之前对其进行测试可以避免服务因拼写错误或其他错误而无法启动。

水平方法假设您可以适当地重复执行任务。考虑一下您的应用程序。哪些区域适合拆分?哪些区域可以由多台机器并行处理?延迟是否会影响您的应用程序?您遇到连接限制或其他瓶颈的可能性有多大?您是否要求 Web 服务器同时处理邮件传递、数据库或其他杂务?

我曾在拥有数百台 Web 服务器的环境中工作过。对于不同类型的负载,应该进行不同的划分。如果您有大量很少更改的数据文件,则将它们与频繁更改的“内容”分开,可能会为静态和动态数据提供更多的空间。不同的工具对不同的负载效果更好。Apache 和 Lighttpd 对某些东西效果很好,而 Nginx 对其他东西效果更好。

查看代理和缓存。用户和应用程序之间以及应用程序各部分之间均应如此。我了解到您已在使用 memcache,这很有帮助。根据应用程序流量,在负载均衡器和 Web 服务器之间放置 perlbal 或 pound 等反向代理可能很有意义。

在某些时候,您可能会发现 MySQL 主服务器 <-> (N * 从服务器) 复制跟不上,您需要对数据库进行分区。对数据库进行分区可能涉及设置另一层数据管理层。许多人使用另一个带有 memcache 的数据库进行此管理。在我工作过的一个地方,我们使用主服务器 <-> 主服务器复制对来存储大多数数据,并使用另一对带有 10 个读取从服务器的复制对来存储指向数据的指针。

这只是对我在拥有数百台机器的站点工作时遇到的一些问题的简单描述。从几台机器增长到几百台机器,问题层出不穷。我相信增长到数千台机器时也会有同样的问题。

答案2

最近有很多关于这个主题的好文献。开始于高可扩展性,很多最好的东西都来自那里。你可以看看Digg 的技术博客了解我们的工作方式,您还可以联系 SAGE 等资源 - SAGE 名单上的人员是宝贵的资源。

答案3

大多数 Web 应用程序的用户群高速增长,这就要求开发人员在数据库前使用 memcache。数据应计算并保存在缓存中。这将有助于减少根据用户请求向页面提供数据的时间。

相关内容