分离通用和用户专有数据流，实现可扩展的网站

作者 Gavin Terrill译者 乔梁 发布于 2008年3月6日 下午5时36分

社区

Architecture

主题

性能和可伸缩性

标签

缓存,

负载均衡

Gojko Adzic是一位作者兼IT咨询师，他发表了一篇很有趣的文章，该文章阐述了利用分离动静态内容这种架构的好处达到扩展Web应用的目的：

在一个要求可扩展性的网站项目中，有很多需要早做决定的架构问题，其中之一就是将数据流分离成两部分：一是用户特定数据，二是通用数据。

这种分离数据方法的主要原理是因为它们的使用约束意味着两种不同的缓存和状态管理方法：

例如，大部分通用数据流是完全无状态的，但用户的特定操作通常是有状态的。如果把这两种数据流清晰划分开，那么我们就可以通过无状态的服务和服务器来处理通用操作。无状态服务比有状态服务更容易理解，因为他们可以很容易地被代替而不会影响任何的系统操作。你如果想达到更大的吞吐量，只要使用round-robin策略和简单的负载均衡器将请求分发给更多廉价的服务器就可以了。而有状态服务的扩展却不是如此容易的事——它们可能会依赖于资源锁定，而负载均衡器就不得不将来自于同一个Session的所有请求发送到同一个服务器上。如果一个有状态的服务器宕机了，那么对系统运行有明显的影响，所以这些有服务必须比那些无状态服务具备更快的恢复能力。

Gojko 提出了如何分离数据流的指导原则。对于一个双层架构的应用，要创建不同的数据源。对于静态数据流，要打开缓存，关闭事务。对于三层架构的应用来说就更复杂一些：

在三层架构中，我喜欢在中间层就直接分离为用户特有数据服务器组和通用服务器组。Web服务器在前端从第一组中间件服务器中得到通用数据，而利第二组中间件服务器管理事务。通用数据流服务器可以做成集群，很容易扩展，而且任何负载均衡系统都可以在集群外部运行。它们可以被重启、直接从集群中拿掉或者再放回去，这些都不会影响系统的运行。透明的缓存也很容易应用于这些服务器。而另一方面，用户特有数据的服务器在这些方面要复杂一些，而且不能使用透明的缓存。这种分离方法就是为了将来的扩展和缓存做打算，因为通用数据服务器可以按区域划分，放在几层缓存服务器之下，通过产品界限或类型垂直分开。而用户特定数据服务器的功能要专一且独立，所以当我们以后需要分割时，只要关注这一小部分就可以了。

Gojko建议，尽可能让通用服务器利用缓存能力，如使用AJAX技术将用户特定内容加载到通用页面，使用cookies保存每个页面顶部都要显示的用户详细信息。通用数据流可以使用高性能的http服务器，如LightHttpd。

查看英文原文：Generic versus User Specific Data Streams for Scalable Web Sites

• 更早的 >