总是很难忘记生活的点点滴滴, 脑海中总是闪过好多的曾经, 美好的回忆, 但成长中却让我们失去了很多, 很想在忙碌的生活中淡淡忘记; 不曾放低的东西却始终让我忘记不了, 但我还要在忙碌的生活中继续生活!

【转载】大型网站的架构设计问题

上一篇 / 下一篇  2008-10-10 10:40:34 / 个人分类:心情点滴

转载】大型网站的架构设计问题
在CSDN上看到一篇文章讨论大型高并发负载网站的系统架构问题,作者提出了几点建议:

1. HTML静态化,这可以通过CMS自动实现;

2. 图片服务器分离(类似的,在视频网站中,视频文件也应独立出来);

3. 数据库集群和库表散列,OracleMySQL等DBMS都有完美的支持;

4. 缓存,比如使用Apache的Squid模块,或者是开发语言的缓存模块,;

5. 网站镜像;

6. 负载均衡。

作者将负载均衡称为“是大型网站解决高负荷访问和大量并发请求采用的终极解决办法”,并提出“一个典型的使用负载均衡的策略就是,在软件或者硬件四层交换的基础上搭建squid集群”。在实践时可以考虑建立应用服务器集群和Web服务器集群,应用服务器集群可以采用Apache+Tomcat集群和WebLogic集群等,Web服务器集群可以用反向代理,也可以用NAT的方式,或者多域名解析均可。

从提升网站性能的角度出发,静态资源不应和应用服务器放在一起,数据库服务器也应尽量独立开来。在典型的MVC模式中,由谁来完成数据逻辑处理的,对系统性能有着至关重要的影响。以Java EE为例,在OO的设计思想中,我们强调系统的抽象、重用、可维护性,强调下层的更改不会扩散到上层逻辑,强调系统移植的便捷性,因而往往存在一种过分抽象的问题,比如在Hibernate的基础上再加入一层DAO的设计。另外一方面,却会忽视利用DBMS本身的优秀特性(存储过程、触发器)来完成高效的数据处理。诚然,如果客户要求将数据从Oracle移植到MySQL,那么DBMS特性的东西越少,移植便越容易。但事实上,在实践中,提出类似移植要求的情况非常少见,因此在做架构设计时,不一定为了这种潜在的需求而大幅牺牲系统的性能与稳定性。此外,我不建议采用分布式数据库管理结构,这样带来的开销太大,数据维护也是个头痛的问题,尽可能采用集中式的数据管理。

在商业系统中,算法逻辑本身并不复杂,在这种情况下,程序设计本身的好坏不会对系统的性能造成致命的影响。重要的影响因素反而变为软件系统架构本身。在传统的CORBA、J2EE、DCOM等对象模型中,我们看到专家们对分布式对象计算的理论偏好,但实践证明,对象的分布带来的恶劣影响远远胜过其积极意义。这也是现在轻量级的开发框架受推崇的一个重要原因。如果能用简单的,就不要用复杂的,例如能够用Python、RoR完成的任务,是否一定要用Java来做?我看未必。对于用户来说,他们关心的不是采用什么先进的技术,而是我们提供的产品能否满足他的需求。而且,Python、RoR这些开发工具已经强大到足以应对大部分网站应用,在各种缓存系统的帮助下,在其他技术的协调配合下,完全能够胜任高负载高并发的网站访问任务。

在HTML静态化方面,如果是对于更新相对较少的页面,可以这样处理,例如新闻、社区通告、或者类似与淘宝网的产品分类信息。但若数据更新频繁,这样做的意义便不大。

网站镜像是个传统的技术,更高级的应用来自流媒体领域的CDN(Content Delivery Network),CDN的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过,在电子商务领域,很少有这样的应用。


TAG: 网站 tomcat 性能 心情点滴

 

评分:0

我来说两句

Open Toolbar