大型网站的架构设计问题.doc

大型网站的架构设计问题 在CSDN上看到一篇文章()讨论大型高并发负载网站的系统架构问题，作者提出了几点建议： 1.HTML静态化，这可以通过CMS自动实现； 2.图片服务器分离(类似的，在视频网站中，视频文件也应独立出来)； 3.数据库集群和库表散列，Oracle、MySQL等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的概念可以由流媒体数据扩展到图片、视频文件等静态资源的传输。不过，在电子商务领域，很少有这样的应用。 开源平台的高并发集群思考 目前碰到的高并发应用，需要高性能需求的主要是两个方面 1。网络 2。数据库 这两个方面的解决方式其实还是一致的 1。充分接近单机的性能瓶颈，自我优化 2。单机搞不定的时候( 数据传输瓶颈： 单位时间内磁盘读写/网络数据包的收发 cpu计算瓶颈)，把负荷分担给多台机器，就是所谓的负载均衡 网络方面单机的处理 1。底层包收发处理的模式变化(从select模式到epoll/kevent) 2。应用模式的变化 2.1应用层包的构造方式 2.2应用协议的实现2.3包的缓冲模式 2.4单线程到多线程 网络负载均衡的几个办法 1。代理模式：代理服务器只管收发包，收到包以后转给后面的应用服务器群(服务器群后可能还会有一堆堆的数据库服务器等等)，并且把返回的结果再返回给请求端 2。虚拟代理ip：代理服务器收发包还负载太高，那就增加多台代理服务器，都来管包的转发。这些代理服务器可以用统一的虚拟ip，也可以单独的ip 3。p2p：一些广播的数据可以p2p的模式来减轻服务器的网络压力 数据库(指mysql)单机的处理 1。数据库本身结构的设计优化(分表，分记录，目的在于保证每个表的记录数在可定的范围内) 2。sql语句的优化 3。master+slave模式 数据库集群的处理 1。master+slave模式(可有效地处理并发查询) 2。mysql cluster模式(可有效地处理并发数据变化) 相关资料： 主题：大型、高负载网站架构和应用初探 时间：30-45分钟 开题：163,sina,soh