1.0 版本 hello world

1.0 版本最简单的网站，浏览客户端以及移动端，通过DNS解析域名，然后访问网站。网站可以通过java web构建，部署到tomcat里面启动，后端就是一个单点的Mysql 数据库。这个网站已经简单到不能再简单了。

这个网站每秒处理两三百个请求应该是没有问题的。但是有无论是webserver还是数据库都是单点，任何一个挂了，整个网站就挂了。

2.0 版本 负载均衡

为了解决业务的单点故障，以及提升并发性能。我们还需要在 webserver前面加一个负载均衡器（load balancer），这个负载均衡器可以是一个nginx或者haproxy。这个负载均衡器本身也是需要保障高可用的。客户端请求先打到负载均衡，然后负载均衡会根据负载算法（轮训、最少连接数、权重、iphash等）将流量分配到后端 webserver中。

可以配合健康检查，如果有一个后端server 宕机了，负载均衡会自动将流量摘除，请求会转发到其他的server上面，保障业务高可用。

3.0 版本 DB主从

在2.0 版本里面虽然解决了业务单点和并发，但是当业务流量增大时，数据库往往成为性能的瓶颈。这时候第一步通常是把数据库搞成集群，最简单的集群就是 一主多从，譬如mysql主从之间通常通过binlog复制数据。主节点负责读写，而从节点只负责读。

这里就开始需要借助各种JDBC框架帮我们做读写分离。由于上面的主节点只有一个，宕机的时候还需要临时将从节点提升为主节点，也可以部署多主多从结构，多master 都允许写入。

3.1版本 DB分库分表

3.0 版本的所有表都集中在一个数据库（database）里面，那么这个请求集中在一个数据库上。3.1 版本我们开始分库分表，将表打散到不同的数据库里面。

如上图，我们将product表、forums表以及users表 分别放到三个database里面.

3.2 版本 DB分片

3.1 版本虽然实现了分库，但请求都还是集中在一个物理的DB 服务器上，如果数据量非常大，我们还可以采用分片的方式，我们可以部署多套DB服务集群，将一张表分配到不同的DB服务器存储，譬如通过用户ID做水平拆分。这个动作被称为sharding。

当然我们也可以做垂直拆分，譬如将不同的表分配到不同的数据库中。

4.0 缓存

这里的缓存分别两部分，一部分是webserver里面添加缓存。很多数据先从cache server中，如果缓存中没有，再去 database 中获取。这里需要保障缓存和database数据的一致性。

缓存如果被击穿是非常危险的，很容易导致所有流量达到DB，直接干崩数据库。除了给数据库增加缓存，还可以给整个网站加缓存。客户端通过域名解析，先访问CDN，如果CDN没有则会回源。

CDN通常只缓存静态数据，譬如静态网页、视频或者图片。

5.0 汇总

好了，我们将上面的所有的东西都汇总一下画到一个图中。这里面主要涉及到负载均衡、数据库分片、缓存和CDN。有些特别大的网站还会分地域部署，譬如在北美、欧洲会单独部署一套服务，然后有一个中心节点，地域的数据会定时同步到中心。