大型网站架构体系的演变(下)
2015-06-30 20:16
411 查看
本文转自:http://blog.csdn.net/dinglang_2009/article/details/46399293
接着上篇的继续
在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。
![](https://img-blog.csdn.net/20150607113750042?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已。
还有一招用的比较多的,那就是动静分离。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型)。有了单独的静态文件服务器之后,存储也是个问题,也需要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件系统也派上用场了。
![](https://img-blog.csdn.net/20150607114412875?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN可以有效解决这个问题。
CDN的基本原理并不复杂,可以理解为智能DNS+Squid反向代理缓存 ,然后需要有很多机房节点提供访问。
![](https://img-blog.csdn.net/20150607114916327?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。
如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?
随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。
![](https://img-blog.csdn.net/20150607115500822?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作
![](https://img-blog.csdn.net/20150607115748585?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。这样,传说中的SOA的价值就得到体现了。
![](https://img-blog.csdn.net/20150607120506220?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了
![](https://img-blog.csdn.net/20150607120633611?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvZGluZ2xhbmdfMjAwOQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center)
最后,还介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发站和各方面非常迫切,不要轻易走这一步。
因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
接着上篇的继续
在做扩展满足了基本的性能需求后,我们会逐渐关注“可用性”(也就是我们通常听别人吹牛时说的SLA、几个9)。如何保证真正“高可用”,也是个难题。
几乎主流的大中型互联网公司,都会有用到类似的架构,只是节点数不同而已。
还有一招用的比较多的,那就是动静分离。可以需要开发人员配合(把静态资源放独立站点下),也可以不需要开发人员配合(利用7层反向代理来处理,根据后缀名等信息来判断资源类型)。有了单独的静态文件服务器之后,存储也是个问题,也需要扩展。多台服务器的文件怎么保持一致,买不起共享存储怎么办?分布式文件系统也派上用场了。
还有一项目前国内外用的非常普遍的技术CDN加速。目前该领域竞争激烈,也已经比较便宜了。国内南北互联网问题比较严重,使用CDN可以有效解决这个问题。
CDN的基本原理并不复杂,可以理解为智能DNS+Squid反向代理缓存 ,然后需要有很多机房节点提供访问。
截止目前为止,都没有怎么去改动应用程序的架构,或者说通俗点,都不怎么需要大面积的修改代码。
如果上面那些手段都用光了,还是支撑不住怎么办?不停的加机器也不是办法啊?
随着业务越来越复杂,网站的功能越来越多,虽然部署层面是采用的集群,但是应用程序架构层面还是“集中式”的,这样会导致很多耦合,不便于开发、维护,而且容易“一荣俱损”。所以,通常会把网站拆分出不同的子站点来单独宿主。
应用都拆了,由于单个数据库的连接,QPS,TPS,I/O处理能力都非常有限,DB层面也可以去做垂直分库操作
拆分应用和DB之后,其实还是会有很多问题。不同的站点,里面可能会有相同逻辑和功能的代码。当然,对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用,但是这种强依赖也很容易造成一些问题(版本问题、依赖关系等处理起来非常麻烦)。这样,传说中的SOA的价值就得到体现了。
应用、服务之间还是会出现一些依赖问题,这时候,高吞吐量的解耦利器出现了
最后,还介绍一个大型互联网公司都用的绝技--分库分表。个人经验,不是业务发站和各方面非常迫切,不要轻易走这一步。
因为分库分表谁都会干,关键是拆完之后怎么办。目前,市面上还没有完全开源免费的方案,能让你一劳永逸地解决数据库拆分问题。
相关文章推荐
- 大型网站架构体系的演变(上)
- mediawiki中全局变量$wgLogo用于设置网站的Logo
- IT架构之IT架构标准——思维导图
- Web前端体系架构
- ODPS技术架构及应用实践
- 批处理刷新网站
- 漫谈SOA(面向服务架构)
- 网站链接
- 浅谈大型web系统架构
- 一个优美的架构需要考虑的几个问题
- 给网站编辑MM写的简易代码情书
- Postback回发事件的真实感触
- dubbo学习笔记-关于架构
- DRBD+HeartBeat+NFS:配置NFS的高可用 推荐
- 如何快速开发网站?
- 自然排名,更倾向于哪个要素?
- 微信网站开发需要注意事项(1)
- 如何让虚拟目录里面的webconfig不继承网站的设置
- KVM虚拟化环境高可用方案探讨
- 架构师学习之路1设计模式