前言:这两天机器坏了,正在送修中,写个系列的大型网站架构的文章,希望对有志在互联网做出一番事业的站长朋友们一些帮助。
注意:这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以 实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构。我们这里不讨论是PHP还是JSP或 者.NET环境,我们从架构的方面去看问题,实现语言方面并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须要面对的。
文入正题:
首先讨论一下大型网站需要注意和考虑的问题
A. 海量数据的处理。
众所周知,对于一些相对小的站点来说,数据量并不是很大,select和update就可以解决我们面对的问题,本身负载量不是很大,最多再加几 个索引就可以搞定。对于大型网站,每天的数据量可能就上百万,如果一个设计不好的多对多关系,在前期是没有任何问题的,但是随着用户的增长,数据量会是几 何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
B. 数据并发的处理
在一些时候,2.0的CTO都有个尚方宝剑,就是缓存。对于缓存,在高并发高处理的时候也是个大问题。在整个应用程序下,缓存是全局共享的,然而 在我们进行修改的时候就,如果两个或者多个请求同时对缓存有更新的要求的情况下,应用程序会直接的死掉。这个时候,就需要一个好的数据并发处理策略以及缓 存策略。
另外,就是数据库的死锁问题,也许平时我们感觉不到,死锁在高并发的情况下的出现的概率是非常高的,磁盘缓存就是一个大问题。
C. 文件存贮的问题
对于一些支持文件上传的2.0的站点,在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对 文件按照日期和类型进行存贮。但是当文件量 是海量的数据的情况下,如果一块硬盘存贮了500个G的琐碎文件,那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题,哪怕你的带宽足够,但是你的 磁盘也未必响应过来。如果这个时候还涉及上传,磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题,但是还有个问题就是各地的访问问题,也许我们的服务器在北京,可能在云南或者新疆的访问速度如何解决?如果做分布式,那么我们的文件索引以及架构该如何规划。
所以我们不得不承认,文件存贮是个很不容易的问题
D. 数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库,里面布满了多对多关系,还能用GUID来替换INDENTIFY COLUMN 但是,多对多关系充斥的2.0时代,第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
E. 数据索引的问题
众所周知,索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是,在高UPDATE的情况下,update和delete付出的成本会高的无法想想,笔者遇到过一个情况,在更新一个聚焦索引的时候需要10分钟来完成,那么对于站点来说,这些基本上是不可忍受的。
索引和更新是一对天生的冤家,问题A,D,E这些是我们在做架构的时候不得不考虑的问题,并且也可能是花费时间最多的问题,
F. 分布式处理
对于2.0网站由于其高互动性,CDN实现的效果基本上为0,内容是实时更新的,我们常规的处理。为了保证各地的访问速度,我们就需要面对一个绝大的问题,就是如何有效的实现数据同步和更新,实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
G. Ajax的利弊分析
成也AJAX,败也AJAX,AJAX成为了主流趋势,突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post到服务器数 据,服务器接到数据请求之后返回来,这是一个很正常的AJAX请求。但是在AJAX处理的时候,如果我们使用一个抓包工具的话,对数据返回和处理是一目了 然。对于一些计算量大的AJAX请求的话,我们可以构造一个发包机,很容易就可以把一个webserver干掉。
H. 数据安全性的分析
对于HTTP协议来说,数据包都是明文传输的,也许我们可以说我们可以用加密啊,但是对于G问题来说的话,加密的过程就可能是明文了(比如我们知道的 QQ,可以很容易的判断他的加密,并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你,但是当你流量上来之后, 那么所谓的外挂,所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说,我们可以采用更高级别的判断甚至HTTPS来实现,注 意,当你做这些处理的时候付出的将是海量的database,io以及CPU的成本。对于一些群发,基本上是不可能的。笔者已经可以实现对于百度空间和 qq空间的群发了。大家愿意试试,实际上并不是很难。
I. 数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候,这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问 题了,数据基于网络传输根据数据库的设计的不同,数据延迟是很可怕的问题,也是不可避免的问题,这样的话,我们就需要通过另外的手段来保证在这延迟的几秒 或者更长的几分钟时间内,实现有效的交互。比如数据散列,分割,内容处理等等问题
K.数据共享的渠道以及OPENAPI趋势
Openapi已经成为一个不可避免的趋势,从google,facebook,myspace到海内校内, 都在考虑这个问题,它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台,数据开放平台就 成为必不可少的途径了,而在开放的接口的情况保证数据的安全性和性能,又是一个我们必须要认真思考的问题了。
当然还有更多需要考虑的问题,我这里就写一个最需要考虑的问题,欢迎补充。
下一篇文章将针对问题A,提出具体的解决方案和思路
转载自--疯狂代码,后面不在做阐述
分享到:
相关推荐
在系列的第一部分,"疯狂代码,大型网站架构系列之一,前言,不得不考虑的问题.doc",作者引入了大型网站架构设计所面临的根本问题。这部分可能包括了对高可用性、可扩展性、性能优化、数据一致性以及故障恢复等关键...
《大型分布式网站架构设计与实践》主要介绍了大型分布式网站架构所涉及的一些技术细节,包括SOA架构的实现、互联网安全架构、构建分布式网站所依赖的基础设施、系统稳定性保障和海量数据分析等内容;深入地讲述了...
《架构之美英文完整版(Beautiful Architecture)》是一本汇集了多位顶尖软件设计师和架构师智慧的作品,由Diomidis Spinellis和Georgios Gousios编辑。本书深入探讨了软件架构的各个方面,旨在向读者展示如何构建既...
【格兰仕网站架构方案书】是一份详细指导如何构建高效、全面的网站架构的文档,旨在帮助企业和个人制定满足特定需求的建站方案。方案书中涵盖了从需求分析到实施步骤,再到技术支持和培训等各个关键环节。 首先,...
架构设计并非随意为之,而是基于多种因素的考虑,如系统规模、功能需求、性能指标、开发周期、团队技能等。常见的误解有小型系统无需架构设计和敏捷开发可以忽略架构,但实际上,无论系统大小,清晰的架构都能提高...
《架构之美》是一本深入探讨软件架构的书籍,中文精选版虽然包含了一部分非正文内容,如广告、介绍和序言等,但其核心部分对于读者理解架构设计的精髓仍有着不可忽视的价值。这本书旨在引领读者领略软件架构的美学与...
《分站式网站架构开发方案书》探讨了构建高效、扩展性强且适应性强的网站架构的重要性和具体实施步骤。此方案书着重强调了二次开发在大型项目中的优势,特别是选择合适的开源B2B建站系统作为基础,以减少开发时间和...
一个高效且适应性强的B2B分站式网站架构对于企业的在线业务拓展至关重要。本方案旨在提供一种能够满足多元化需求、易于扩展和二次开发的网站架构。 一、前言 网站开发分为一次开发和二次开发。一次开发通常耗时较长...
设计模式中的分层架构(可以参考一下J2EE(Java 2 Platform, Enterprise Edition (是由Sun、IBM等厂商所主导,协同许多厂商共同参与所制定出的规范,以企业及企业间之运算为导向的JAVA平台环境)中MVC(Multiple ...
赢辉网络作为一家专业的网站策划与设计公司,其制定的网站策划书(前言+架构部分)深刻地阐述了品牌型网站构建的策略和方法,为品牌建设提供了理论与实践相结合的指导。 一、网站策划目的 在策划书的开篇,赢辉网络...
主机时代的银行核心系统以大型机为基础,结合单体架构、z/OS操作系统、TSO、COBOL编程、DB2数据库和CICS中间件,构建了一个强大而稳定的业务处理环境。然而,随着技术的发展和业务需求的变化,银行系统正逐步向...
第1章信息架构要解决的问题 3 你好,iTunes 5 信息架构要解决的问题 8 信息过载 9 访问信息的更多方式 10 加入信息架构 12 由信息构成的场所 13 渠道之间的一致性 13 系统化思维 15 本章回顾 16 第2章信息架构的定义...
推荐系统架构前言实践
ArchiMate的架构金字塔分为三层:业务层、应用层和技术层,每一层都有其特定的概念、关系和交互模式,形成了一种层次化的架构视图,便于理解和管理复杂的企业架构。 #### 架构组成与描述 ArchiMate通过定义核心...