一张图讲清楚高可用、高性能、可扩展的WEB系统架构
2014-01-19 23:22
543 查看
前言:最近在与广东互联网基地一起进行无线城市集中平台的建设,在系统设计、架构调优上做了很多的探索,也在系统集成测试和性能调优中遭遇了很多的烦恼,心里有一些所得所悟,希望与大家共同学习探讨。
WEB系统最容易出现性能故障的点在哪里? 有很多人对此不知其然,或知其然而不知其所以然。
下面这张图,是在一个大型的WEB系统设计中,经典的架构设计和分层模式。
1) 前端负载均衡: 有钱的用硬件四层交换(想当年雅虎中国2000台服务器,只用了四台Alteon就搞定了),没钱的用软件负载均衡(LVS、Nginx)
2) 多级缓存:首先要充分利用浏览器的缓存能力,也就是Cookie,然后要在服务端利用页面缓存机制,前些年大家喜欢用Squid,现在Varnish更流行起来了,有一个牛逼的故事是挪威的最大的在线报纸
Verdens Gang(vg.no) 使用 3 台 Varnish
代替了原来的 12 台 Squid,性能比以前更好,这是 Varnish
最成功的应用案例。 最后一个缓存点是在数据库前方设置,让那些经常需要被查询,但是实时性要求不那么高的数据缓存起来,避免对数据库的频繁查询。三级缓存可以有效的提升整个系统的性能。
3)应用服务器层面:先考虑一下你的静态页面与动态页面的占比,然后考虑一下如何尽量实现动态页面静态化,把静态的部署到Apache上,动态的部署到Tomcat上吧。如果你是一个像Flicker那样的图片共享网站,必须考虑设置单独的图片服务器,这是淘宝血泪史告诉我们的真理。
4)现在要考虑数据库的选型问题了:采用关系型数据库还是非关系型数据库完全取决于你的业务场景,如果你要实现实时要求高,数据一致性要求高的场景,关系型数据库;如果你要实现海量数据的查询和高并发,非关系型数据库(考虑Facebook一张表有一亿用户,如果用关系型数据库查询。磁盘IO也快撑不住了,而非关系型数据库则完全没有这个问题);
5)数据库性能问题之外务必考虑清楚数据库的并发性能:通常会采用生产数据库与查询数据库分离的方式,也就是著名的MySQL的单主多从服务方式。为了实现高可用性HA,有的网站比如淘宝网,在Master之间也会实现集群部署。
6)数据库集群和库表散列:
上面提到的数据库集群由于在架构,成本,扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案,在应用程序中将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户
ID 进行表散列,这样就能够低成本的提升系统的性能并.且有很好的扩展性,sohu
的论坛就是采用了这样的架构.
WEB系统最容易出现性能故障的点在哪里? 有很多人对此不知其然,或知其然而不知其所以然。
下面这张图,是在一个大型的WEB系统设计中,经典的架构设计和分层模式。
1) 前端负载均衡: 有钱的用硬件四层交换(想当年雅虎中国2000台服务器,只用了四台Alteon就搞定了),没钱的用软件负载均衡(LVS、Nginx)
2) 多级缓存:首先要充分利用浏览器的缓存能力,也就是Cookie,然后要在服务端利用页面缓存机制,前些年大家喜欢用Squid,现在Varnish更流行起来了,有一个牛逼的故事是挪威的最大的在线报纸
Verdens Gang(vg.no) 使用 3 台 Varnish
代替了原来的 12 台 Squid,性能比以前更好,这是 Varnish
最成功的应用案例。 最后一个缓存点是在数据库前方设置,让那些经常需要被查询,但是实时性要求不那么高的数据缓存起来,避免对数据库的频繁查询。三级缓存可以有效的提升整个系统的性能。
3)应用服务器层面:先考虑一下你的静态页面与动态页面的占比,然后考虑一下如何尽量实现动态页面静态化,把静态的部署到Apache上,动态的部署到Tomcat上吧。如果你是一个像Flicker那样的图片共享网站,必须考虑设置单独的图片服务器,这是淘宝血泪史告诉我们的真理。
4)现在要考虑数据库的选型问题了:采用关系型数据库还是非关系型数据库完全取决于你的业务场景,如果你要实现实时要求高,数据一致性要求高的场景,关系型数据库;如果你要实现海量数据的查询和高并发,非关系型数据库(考虑Facebook一张表有一亿用户,如果用关系型数据库查询。磁盘IO也快撑不住了,而非关系型数据库则完全没有这个问题);
5)数据库性能问题之外务必考虑清楚数据库的并发性能:通常会采用生产数据库与查询数据库分离的方式,也就是著名的MySQL的单主多从服务方式。为了实现高可用性HA,有的网站比如淘宝网,在Master之间也会实现集群部署。
6)数据库集群和库表散列:
上面提到的数据库集群由于在架构,成本,扩张性方面都会受到所采用DB类型的限制,于是我们需要从应用程序的角度来考虑改善系统架构,库表散列是常用并且最有效的解决方案,在应用程序中将数据库进行分离,不同的模块对应不同的数据库或者表,再按照一定的策略对某个页面或者功能进行更小的数据库散列,比如用户表,按照用户
ID 进行表散列,这样就能够低成本的提升系统的性能并.且有很好的扩展性,sohu
的论坛就是采用了这样的架构.
相关文章推荐
- 一张图讲清楚高可用、高性能、可扩展的WEB系统架构
- 一张图讲清楚高可用、高性能、可扩展的WEB系统架构
- 一张图讲清楚高可用、高性能、可扩展的WEB系统架构
- 高性能、高可用、高扩展、分布式微信牌九源码搭建系统架构设计
- 可扩展Web架构与分布式系统
- 高可用、高性能、可扩展、可伸缩网站架构--数据存储和数据流通
- 开源软件架构:可扩展的Web架构与分布式系统
- 高性能web系统的架构和系统优化
- 可扩展Web架构与分布式系统(转)
- 高性能web系统的架构和系统优化
- 一种高可用、易扩展的GB28181接入系统架构
- 高性能web系统的架构和系统优化
- 可扩展Web架构与分布式系统(转)
- 如何构建日请求数十亿次高性能高可用广告系统:微博广告架构解密
- 高性能web系统的架构和系统优化
- 可扩展Web架构与分布式系统
- dubbo 01.第一套:高并发大型电商详情页系统的大型高性能与高可用缓存架构实战视频教程
- 可扩展Web架构与分布式系统
- 搭建ORACLE高可用 高性能 高扩展的 MMM_APE 架构
- 大型网站系统架构实践(三)如何提高网站的高可用和高性能