大型网站架构(1) 历史演变(上)

我们知道一个网站都是随着业务的发展,逐渐演变成几万服务器,几亿用户数的大型网站,经历了若干年,甚至上十年的发展成为大型网站,然而真正亲身经历这个发展过程的人已经不多了,这种人也是拿着公司股票,赶都赶不走的人,所以正因为很多人没有亲身经历过,所以对架构的演变没有深刻的了解,包括我自己在内,不过没吃过猪肉,也看过猪跑。。。

一:第一代架构

这年头创业大多都是从穷屌丝开始的,奔着 “快好省”的原则建立网站,将“应用程序”,“文件”,“数据库”通通放在一台服务器上,匆匆的就走上了网站架构之路。

我们知道业务的发展对技术会有更高的要求,业务的创新会触动技术的创新,当业务逐渐发展起来的时候,最容易出现的问题就是”存储空间“和通用的”性能低下“,这个时候就需要做到”应用程序“和”数据“的分离。

二:第二代架构

随着业务规模的扩大,需要将”应用程序“,”文件“,”数据库“进行分离,用更强大的cpu处理服务器来承载应用程序,记得在上一家用的cpu就是16核,”文件“的话则需要更大的磁盘空间的服务器,”数据库“的话需要更大的磁盘和超大内存的服务器,我们知道sqlserver还是很吃内存的,记得用过最大的是120g的内存。

随着业务规模不断扩大,访问人数逐渐增多,我们也开心了,起码挣到钱了,然后我们会发现数据库开始出现瓶颈了,大量的读写操作让数据库出现访问延迟以及死锁现象的发生,继而影响用户体验。

时间: 2024-08-19 23:48:01

大型网站架构(1) 历史演变(上)的相关文章

大型网站架构体系的演变(上)

互联网上有很多关于网站架构的各种分享,有些主要是从运维和基础架构的角度去分析的(堆机器,做集群),太关注技术细节实现,普通的开发人员基本看不太懂. 本文上篇将主要介绍大型网站基础架构的扩展,下篇则重点从应用程序的角度去介绍网站架构的扩展和演变. 草根时期,快速开发网站并上线.当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限. 有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了. 市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了.于是,决定

大型网站架构体系的演变(下)

接着上篇的继续 在做扩展满足了基本的性能需求后,我们会逐渐关注"可用性"(也就是我们通常听别人吹牛时说的SLA.几个9).如何保证真正"高可用",也是个难题. 几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已. 还有一招用的比较多的,那就是动静分离.可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型).有了单独的静态文件服务器之后,存储也是个问题,也需要扩展.多台服务器

大型网站架构演变

之前也有一些介绍大型网站架构演变的文章,例如LiveJournal的.ebay的,都是非常值得参考 的,不过感觉他们讲的更多的是每次演变的结果,而没有很详细的讲为什么需要做这样的演变,再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂 的技术,于是有了写这篇文章的想法,在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系,希望能给 想从事互联网行业的同学一点初步的概念,:),文中的不对之处也请各位多给点建议,让本文真正起到抛砖引玉的效果.

【转载】大型网站架构演化

大型网站系统特点 高并发.大流量:PV 量巨大 高可用:7*24 小时不间断服务 海量数据:文件数目分分钟 xxTB 用户分布广泛,网络情况复杂:网络运营商 安全环境恶劣:黑客的攻击 需求快速变更,发布频繁:快速适应市场,满足用户需求 渐进式发展:慢慢地运营出大型网站 大型网站架构演化过程 (1)初始阶段网站架构:一台 Server 就刚需.应用程序.数据库.文件等所有资源都集中在一台 Server 上,典型案例:基于 LAMP 架构的 PHP 网站: (2)应用和数据服务分离:三台 Serve

大型网站架构系列:负载均衡详解(3)

原文:大型网站架构系列:负载均衡详解(3) 软件负载均衡概述 Ngnix负载均衡 Lvs负载均衡 Haproxy负载均衡 本次分享总结 一.软件负载均衡概述 硬件负载均衡性能优越,功能全面,但是价格昂贵,一般适合初期或者土豪级公司长期使用.因此软件负载均衡在互联网领域大量使用.常用的软件负载均衡软件有Nginx,Lvs,HaProxy等.本文参考大量文档,部分为直接拷贝,参考出处见负载均衡详解(4). 二.Ngnix负载均衡 Ngnix是一款轻量级的Web服务器/反向代理服务器,工作在七层Htt

大型网站架构系列:消息队列(二) (转)

本文是大型网站架构系列:消息队列(二),主要分享JMS消息服务,常用消息中间件(Active MQ,Rabbit MQ,Zero MQ,Kafka).[第二篇的内容大部分为网络资源的整理和汇总,供大家学习总结使用,最后有文章来源] 本次分享大纲 消息队列概述(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息队列应用场景(见第一篇:大型网站架构系列:分布式消息队列(一)) 消息中间件示例(见第一篇:大型网站架构系列:分布式消息队列(一)) JMS消息服务 常用消息队列 参考(推荐)资料 本

大型网站架构系列:负载均衡详解(1)

原文:大型网站架构系列:负载均衡详解(1) 面对大量用户访问.高并发请求,海量数据,可以使用高性能的服务器.大型数据库,存储设 备,高性能Web服务器,采用高效率的编程语言比如(Go,Scala)等,当单机容量达到极限时,我们需要考虑业务拆分和分布式部署,来解决大型网站访 问量大,并发量高,海量数据的问题. 从单机网站到分布式网站,很重要的区别是业务拆分和分布式部署,将应用拆分后,部署到不同的机器上,实现大规模分布式系统.分布式和业务拆分解决 了,从集中到分布的问题,但是每个部署的独立业务还存在

大型网站架构系列:负载均衡详解(4)

原文:大型网站架构系列:负载均衡详解(4) 本文是负载均衡详解的第四篇,主要介绍了LVS的三种请求转发模式和八种负载均衡算法,以及Haproxy的特点和负载均衡算法.具体参考文章,详见最后的链接.   三.LVS负载均衡 LVS是一个开源的软件,由毕业于国防科技大学的章文嵩博士于1998年5月创立,用来实现Linux平台下的简单负载均衡.LVS是Linux Virtual Server的缩写,意思是Linux虚拟服务器. 基于IP层的负载均衡调度技术,它在操作系统核心层上,将来自IP层的TCP/

大型网站架构不得不考虑的几点问题

前言:这两天机器坏了,正在送修中,写个系列的大型http://www.aliyun.com/zixun/aggregation/11116.html">网站架构的文章,希望对有志在互联网做出一番事业的站长朋友们一些帮助. 注意:这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构.我们这里不讨论是PHP还是JSP

作为大型网站架构必须考虑的十大问题

这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例 比如海内,开心网等类似的web2.0系列架构.我们这里不讨论是PHP还是JSP或者.NET环境,我们从架构的方面去看问题,实现语言方面并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须要面对的. 这里讨论一下大型网站需要注意和考虑的问题 1.海量数据的处理 众所周知,对于一些相对小的站点