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

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

想学习更多系统架构知识，可进入e良师益友网咨询。