一张图讲清楚高可用、高性能、可扩展的WEB系统架构

转自：http://labs.chinamobile.com/mblog/466/189076
前言：最近在与广东互联网基地一起进行无线城市集中平台的建设，在系统设计、架构调优上做了很多的探索，也在系统集成测试和性能调优中遭遇了很多的烦恼，心里有一些所得所悟，希望与大家共同学习探讨。

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 的论坛就是采用了这样的架构.

权限： 公开    来自：labs

声明： 本文仅代表作者个人观点。其原创性及文中表达的意见、判断、数据、观点和陈述文字等内容均与中国移动研究院无关。移动Labs博客致力于为ICT领域的研究者及从业者提供技术和业务交流的网络平台，对本文中全部或部分内容的真实性、完整性不作任何保证或承诺，仅供读者参考交流。