大型网站架构体系的演变
2015-12-18 10:37
603 查看
互联网上有很多关于网站架构的各种分享,有些主要是从运维和基础架构的角度去分析的(堆机器,做集群),太关注技术细节实现,普通的开发人员基本看不太懂。
本文上篇将主要介绍大型网站基础架构的扩展,下篇则重点从应用程序的角度去介绍网站架构的扩展和演变。
草根时期,快速开发网站并上线。当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3OZSEB7iarAfNR5V3NT2jvE5uZjF6hDOscSe7uKibHAr7xupxSvF2dvDA/640?wx_fmt=png&wxfrom=5&tp=webp&wx_lazy=1)
有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3mUTQkeo63cWyl2ul2HyRe2WrdVePiaoPxo6FQaaVicmhcMrKvbRwDLWQ/640?wx_fmt=png&wxfrom=5&tp=webp&wx_lazy=1)
市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把DB和APP做分离。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3jMibeLs5XZQLuDBN9rZudyv1DHXiaAZPB43Ihic8j9XJKFxb5HpEMyycg/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3pSnXoiavyQqfY9Llpc7auJwdLdCRtxD9hIbSem0z1YhicTNLPCxUHuBQ/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3icVeoSia0WBoMA2pUHk18TErUvic51zgjQLnyIiaicDJ66145OG5EUotWyQ/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
加机器谁都会加,关键是加完之后得有效果,加完之后可能会引发一些问题。例如非常常见的:页面输出缓存和本地缓存的问题,Session保存的问题......
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3xo57f1icODz0XnOiaicmSicBXEaoI58zyahnUmG4EsxlCjbpCLRudPiaBjg/640?wx_fmt=png&wxfrom=5&tp=webp&wx_lazy=1)
到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引。
Java领域用的较多的是Lucene、Solr等,而php领域用的比较多的是sphinx/coreseek。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3SK3twLqPCjfgfpBpY7ic3hpHXIAiaqCAnFmpyAppHImiajBicmq2Wt2qFQ/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。当然,每一步扩展里面都会有很多技术实现的细节,后续有时间会写文章单独去剖析那些细节。
在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3zoJLdZfy7wCIqY1usczYLpLCXmF4R2Rn1pqeAUPsrWsuIfgcVK1r0w/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已。
还有一招用的比较多的,那就是动静分离。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名
等信息来判断资源类型)。有了单独的静态文件服务器之后,存储也是个问题,也需要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件 系统也派上用场了。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3nUlOG5xymicht1M5NiavOelBQ9CQeb5yqmecNBu6xA6ABY9wYTOTaxJQ/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN可以有效解决这个问题。
CDN的基本原理并不复杂,可以理解为智能DNS+Squid反向代理缓存
,然后需要有很多机房节点提供访问。
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3Z7icU6VlyEw10yUrWmzVM3IVkWVBWBEktRq2PLWZnpfU4bfeFMWjTYw/640?wx_fmt=jpeg&wxfrom=5&tp=webp&wx_lazy=1)
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。
如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?
随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。
应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到
处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。这样,传说中的SOA的价值就得到体现了。
应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利
器出现了
![](http://mmbiz.qpic.cn/mmbiz/KqJwozCG9MdbhiccbiaKuhG7vSgyxia3XM3l4UKUwQcyGcvD1UV1XI30WVcGmIU4I1kibrvibZBiaiaZ00W6hYuxmaQ5g/640?wx_fmt=png&wxfrom=5&tp=webp&wx_lazy=1)
最后,还介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发站和各方面非常迫切,不要轻易走这一步。
因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
本文上篇将主要介绍大型网站基础架构的扩展,下篇则重点从应用程序的角度去介绍网站架构的扩展和演变。
草根时期,快速开发网站并上线。当然,通常只是先试水,用户规模也没有形成,经济能力和投入也非常有限。
有一定的业务量和用户规模了,想提升网站速度,于是,缓存出场了。
市场反响还不错,用户量每天在增长,数据库疯狂读写,逐渐发现一台服务器快撑不住了。于是,决定把DB和APP做分离。
单台数据库也感觉快撑不住了,一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。Salve的台数,取决于按业务评估的读写比例。
数据库层面是缓解了,但是应用程序层面也出现了瓶颈,由于访问量增大,加上早期程序员水平有限写的代码也很烂,人员流动性也大,很难去维护和优化。所以,很常用的办法还是“堆机器”。
加机器谁都会加,关键是加完之后得有效果,加完之后可能会引发一些问题。例如非常常见的:页面输出缓存和本地缓存的问题,Session保存的问题......
到这里,已经基本做到了DB层面和应用层面的横向扩展了,可以开始关注一些其它方面,例如:站内搜索的精准度,对DB的依赖,开始引入全文索引。
Java领域用的较多的是Lucene、Solr等,而php领域用的比较多的是sphinx/coreseek。
到目前为止,一个能够承载日均百万级访问量的中型网站架构基本介绍完了。当然,每一步扩展里面都会有很多技术实现的细节,后续有时间会写文章单独去剖析那些细节。
在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。
几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已。
还有一招用的比较多的,那就是动静分离。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名
等信息来判断资源类型)。有了单独的静态文件服务器之后,存储也是个问题,也需要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件 系统也派上用场了。
还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN可以有效解决这个问题。
CDN的基本原理并不复杂,可以理解为智能DNS+Squid反向代理缓存
,然后需要有很多机房节点提供访问。
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。
如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?
随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。
应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到
处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。这样,传说中的SOA的价值就得到体现了。
应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利
器出现了
最后,还介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发站和各方面非常迫切,不要轻易走这一步。
因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
相关文章推荐
- 亿级用户下的新浪微博平台架构解析
- 如何计算一个网站需要的带宽?
- 从e租宝被查看P2P网站安全:普遍缺乏安全意识,成钓鱼重灾区
- 从e租宝被查看P2P网站安全:普遍缺乏安全意识,成钓鱼重灾区
- 架构师学习方向
- 爬虫实战(1):直播吧网站的赛程表
- 45种攻入网站后台的方法【安全防护策略】
- 创意来源及网站规划
- 布置网站根目录和项目
- Linux——Linux 系统目录架构
- 谈谈把网站迁移到阿里云的一些感想和其中遇到的一些问题
- JSX架构及注释
- Linux概念架构的理解
- Web Services 指南之:Web Services 的架构
- 好用的网站集锦
- 网站调用dll程序的问题
- Android源码镜像网站
- 虚拟化实现架构(处理器虚拟化)
- CSDN网站系统升级公告
- 网站发布