互联网时代，怎么构建一个大型网站是不可缺少的技能。当然，本人目前接触的网站都是读远远大于写。因此本文将一步步讲诉，怎么去使用lamp构建完善一个大型网站（读大于写）。
网站架构，我个人认为最为重要的是两方面的考虑：计算和存储。有些是属于计算密集型，有些是IO密集型。所以以下都将围绕计算和存储来讲述问题。
1、最简单的搭建
假设我们自己创业了，那么我们可能需要自己去搭建一个网站。
这个时候，我们需要去租借一个主机（比如阿里云的虚拟主机等）。对于网站来说，数据是最为重要的，所以需要有一个备份。但是每天pv肯定不高，所以理论上只需要一个计算机器即可。因此，我们只需要3台机器就能完整一个完整的架构。
从上图可以看到计算机器上主要部署2部分内容，一部分是webserver(轻量级可以考虑niginx,lighttpd等)，一个是UI逻辑处理部分，lamp架构则使用php语言来搞定这个问题。因为数据是最重要的，所以database则明显需要2台机器，一台主机，一台做冗余备份。lamp使用mysql来存储数据。
2 增加数据缓存
随着我们网站知名度变高，每天pv越来越大，导致的问题是数据库压力越来越大。很明显，绝大部分网站，读流量都远远高于写流量。即使我们开了mysql的query cache，它也只能在一定程度上通过减少DB机器I的操作来减少DB服务器压力。更为靠谱的是，减少对DB服务器的请求。那么这个时候就需要使用cache.
cache为非关系型kv存储，在使用过程中一般为内存操作。下面的架构改进如下。
可以看出ui写数据仍然直接写入到数据库，但是读则先从cache读取，cache读取不到再从database读取。因为很有可能大部分数据都直接访问cache就可以搞定，这样就可以大大减少数据库的压力。
3、增加计算机器集群(计算方向)
随着整个系统pv继续上涨。单台的计算机器已经无法满足要求。这个时候就需要使用增加计算机器来解决问题。为了方便起见，可以把这个机器放入一个集群进行统一管理。
这个时候，我们可能需要考虑2个问题：负载均衡、数据同步。负载均衡系统相对难度较大，但是是必不可少的，最简单的可以通过zookkeeper等对配置文件进行统一管理。对于节点下的若干机器，可以简单通过概率来进行请求分发。数据同步也是一个难点，比如session同步、文件操作等。
需要说明的是，好的架构结果如下：N台机器能撑住的PV为X，那么T*N台机器基本能撑住T*X pv。换句话说，架构必须能支持横向扩展。如果机器加了一倍，但是撑住的峰值pv不能增加（接近）一倍，那个这个架构就是失败的架构，不是可扩展性的架构。
可以看出的是在负载均衡系统下可以挂很多机器。好的扩展是，加入多少倍机器，计算能力就相应提高多少倍（暂时不考虑存储的瓶颈）。
4、搭建简单的数据库集群(存储方向)
流量上升，计算能力提升的同时，也需要提升数据库的能力。这时候，我们可以采用读写分离。也就有了主从之说。主库可以写，当然也肯定能提供写，从库只能提供读，我们目前主从延时在20ms以内。目前这种工具不少，比如mysql proxy等。(下图应该是ui logic访问dbproxy，图有稍许错误，但是不影响理解)。
如上图，dbproxy作用主要有3个：
1、读写分离。读主要读从库，写只能是写主库。我们在实际设计的时候需要考虑主从延时，比如事务读必须读主库，写完若干秒内最好读主库等等。
2、负载均衡。他能自动根据dbproxy下面挂在的db进行负载均衡。
3、dbproxy维持sql连接池，里面存在和db的长连接。请求过来之后，直接从连接池取连接即可。
5、静态页面跨地域缓存
很明显，我们网站有很多静态页面，若干天才会更换一次。但是因为跨地域、跨机房的问题，外地用户可能访问较慢，所以我们可以通过cdn等技术缓存静态页面。这样就可以减少对服务器的请求，同时加快外地、不同机房用户的访问时间。
如上图所示，加入了静态页面缓存
6、跨地域跨机房设计
当我们业务进一步扩大，我们可能需要跨地域进行机器部署，目前我们主要分为华北(北京)和华东机房(杭州、南京)。跨地域部署，可以加快因为区域带来的访问过慢问题。比如广州访问北京机房数据，就不如北京访问北京机房速度快。这个时候，还是主要分为计算和存储两方面进行讲述。
6.1 计算方向
除了该机房的标示以外，各个机房的机器部署应该完全一致。
6.2 存储方向
在我看来，对于读远远大于写的系统而言，最好只有一个主库，若干个从库。所以只需要在其他机房搭建从库，让从库从主库进行数据同步即可。当然，这样的代价是主从时间比比较长。在数据链路不稳定的情况下，主从同步可能在400ms以上，所以设计需要考虑这个。
当然cache等等也需要跨地域跨机房部署。
如图简要勾勒出了跨地域跨机房的一个部署方案。
7、通用服务的使用
随着业务拓宽，我们可能会有一些需要考虑新能的模块或者业务。
如搜索业务，我们不可能直接通过数据库的select like来实现，就需要使用C等编译型语言来搭建其他系统。所以需要我们根据业务进行架构调整来通过http等使用一些通用的高性能计算方向的服务。
同样，出于业务发展等因素的考虑，我们需要使用内存型的数据库，比如redis等，这些属于存储方向的通用服务。
这些服务，有的可以跨机房部署，各个机房无耦合，有的则相互之间有耦合，比如类似于数据库的主库从库。
8、其他考虑
除此以外，我们还需要有其他因素进行考虑。
8.1 网站数据
这个主要是比如uv/pv。这个有几种做法，第一种是借助第三方的统计攻击，比如百度统计、Google统计等。第二种是对我们现有系统的日志进行统计，同时可以进行深一步的数据挖掘。
8.2 安全性
这个需要考虑网站是不是存在sql注入，xss漏洞，csrf漏洞等。这个方面对于网站是非常关键的。一旦有黑客攻入，后果不堪设想。
对于管理员后台，最好不要开通外网权限，只能通过内网访问。
8.3 seo等
搜索引擎优化对于网站作用不言而喻。后续可能会专门针对百度SEO进行一些分析。