1 、物理分离 webserver 和资料库
最开始，由于某些想法，于是在网际互联网上搭建了一个网站，这个时候甚至有可能 WordPress 主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是 WordPress 托管了一台 WordPress 主机，并且有一定的频宽了。
这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是资料库和应用互相影响，应用出问题了，资料库也很容易出现问题，而资料库出问题的时候，应用也容易出问题。
于是进入了第一步演变阶段：将应用和资料库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为资料库和应用形成互相的影响。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：这一步架构演变对技术上的知识体系基本没有要求。
2 、增加页面 WordPress 加速缓存
好景不长，随著访问的人越来越多，你发现响应速度又开始变慢了，查询原因，发现是访问资料库的操作太多，导致资料连线竞争激烈，所以响应变慢，但资料库连线又不能开太多，否则资料库机器压力会很高，因此，马海祥建议你可以考虑采用 WordPress 加速缓存机制来减少资料库连线资源的竞争和对资料库读的压力。
这个时候首先也许会选择采用 squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行 WordPress 加速缓存（当然，也可以采用将页面静态化的方案），这样程式上可以不做修改，就能够很好的减少对 webserver 的压力以及减少资料库连线资源的竞争。
OK，于是开始采用 squid 来做相对静态的页面的 WordPress 加速缓存。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：前端页面 WordPress 加速缓存技术，例如 squid，如想用好的话还得深入掌握下 squid 的实现方式以及 WordPress 加速缓存的失效演算法等。
3 、增加页面片段 WordPress 加速缓存
增加了 squid 做 WordPress 加速缓存后，整体系统的速度确实是提升了，webserver 的压力也开始下降了，但随著访问量的增加，发现系统又开始变的有些慢了。
在尝到了 squid 之类的动态 WordPress 加速缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也 WordPress 加速缓存起来呢，因此考虑采用类似 ESI 之类的页面片段 WordPress 加速缓存策略。
OK，于是开始采用 ESI 来做动态页面中相对静态的片段部分的 WordPress 加速缓存。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：页面片段 WordPress 加速缓存技术，例如 ESI 等，想用好的话同样需要掌握 ESI 的实现方式等。
4 、资料 WordPress 加速缓存
在采用 ESI 之类的技术再次提高了系统的 WordPress 加速缓存效果后，系统的压力确实进一步降低了，但同样，随著访问量的增加，系统还是开始变慢，经过查询，可能会发现系统中存在一些重复获取资料资讯的地方，像获取使用者资讯等。
这个时候开始考虑是不是可以将这些资料资讯也 WordPress 加速缓存起来呢，于是将这些资料 WordPress 加速缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，资料库的压力也再度降低了不少。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：WordPress 加速缓存技术，包括像 Map 资料结构、 WordPress 加速缓存演算法、所选用的框架本身的实现机制等。
5 、增加 webserver
好景不长，发现随著系统访问量的再度增加，webserver 机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台 webserver，这也是为了同时解决可用性的问题，避免单台的 webserver down 机的话就没法使用了。
在做了这些考虑后，决定增加一台 webserver，增加一台 webserver 时，会碰到一些问题，典型的有：
（1）、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是 Apache 自带的负载均衡方案，或 LVS 这类的站群软件负载均衡方案。
（2）、如何保持状态资讯的同步，例如使用者 session 等，这个时候会考虑的方案有写入资料库、写入储存、 cookie 或同步 session 资讯等机制等。
（3）、如何保持资料 WordPress 加速缓存资讯的同步，例如之前 WordPress 加速缓存的使用者资料等，这个时候通常会考虑的机制有 WordPress 加速缓存同步或分散式 WordPress 加速缓存。
（4）、如何让上传档案这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享档案系统或储存等。在解决了这些问题后，终于是把 webserver 增加为了两台，系统终于是又恢复到了以往的速度。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：负载均衡技术（包括但不限于硬体负载均衡、站群软件负载均衡、负载演算法、 linux 转发协议、所选用的技术的实现细节等）、主备技术（包括但不限于 ARP 欺骗、 linux heart-beat 等）、状态资讯或 WordPress 加速缓存同步技术（包括但不限于 Cookie 技术、 UDP 协议、状态资讯广播、所选用的 WordPress 加速缓存同步技术的实现细节等）、共享档案技术（包括但不限于 NFS 等）、储存技术（包括但不限于储存装置等）。
6 、分库
享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢？
经过查询，发现资料库写入、更新的这些操作的部分资料库连线的资源竞争非常激烈，导致了系统变慢，这下怎么办呢？
此时可选的方案有资料库丛集和分库策略，丛集方面像有些资料库支援的并不是很好，因此分库会成为比较普遍的策略，分库也就意味著要对原有程式进行修改，一通修改实现分库后，不错，目标达到了，系统恢复甚至速度比以前还快了。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：这一步更多的是需要从业务上做合理的划分，以实现分库，具体技术细节上没有其他的要求；但同时随著资料量的增大和分库的进行，在资料库的设计、调优以及维护上需要做的更好，因此对这些方面的技术还是提出了很高的要求的。
7 、分表、 DAL 和分散式 WordPress 加速缓存
随著系统的不断执行，资料量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程式进行一些修改。
也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的资料访问，这个在 ebay 的架构中对应的就是 DAL，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的框架会等到分表做完后才开始做。
同时，在这个阶段可 能会发现之前的 WordPress 加速缓存同步方案出现问题，因为资料量太大，导致现在不太可能将 WordPress 加速缓存存在本地，然后同步的方式，需要采用分散式 WordPress 加速缓存方案了，于是，又是一通考察和折磨，终于是将大量的资料 WordPress 加速缓存转移到分散式 WordPress 加速缓存上了。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：分表更多的同样是业务上的划分，技术上涉及到的会有动态 hash 演算法、 consistent hash 演算法等；DAL 涉及到比较多的复杂技术，例如资料库连线的管理（超时、异常）、资料库操作的控制（超时、异常）、分库分表规则的封装等。
8 、增加更多的 webserver
在做完分库分表这些工作后，资料库上的压力已经降到比较低了，又开始过著每天看著访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了。
这个时候首先检视资料库，压力一切正常，之后检视 webserver，发现 apache 阻塞了很多的请求，而应用站群服务器对每个请求也是比较快的，看来是请求数太高导致需要排队等待，响应速度变慢，这还好办。
一般来说，这个时候也会有些钱了，于是新增一些 webserver 站群服务器，在这个新增 webserver 站群服务器的过程，有可能会出现几种挑战：
（1）、 Apache 的软负载或 LVS 软负载等无法承担巨大的 web 访问量（请求连线数、互联网流量等）的排程了，这个时候如果经费允许的话，会采取的方案是购买硬体负载，例如 F5 、 Netsclar 、 Athelon 之类的，如经费不允许的话，会采取的方案是将应用从逻辑上做一定的分类，然后分散到不同的软负载丛集中。
（2）、原有的一些状态资讯同步、档案共享等方案可能会出现瓶颈，需要进行改进，也许这个时候会根据情况编写符合网站业务需求的分散式档案系统等；在做完这些工作后，开始进入一个看似完美的无限伸缩的时代，当网站流量增加时，应对的站群解决方案就是不断的新增 webserver 。
看看这一步完成后系统的图示：

这一步涉及到的知识体系：到了这一步，随著机器数的不断增长、资料量的不断增长和对系统可用性的要求越来越高，这个时候要求对所采用的技术都要有更为深入的理解，并需要根据网站的需求来做更加定制性质的产品。
马海祥博客网站点评：
大型网站都有复杂的应用，这些应用必须使用资料库，那么在面对大量访问的时候，资料库的瓶颈很快就能显现出来，这时一台资料库将很快无法满足应用，于是我们需要使用资料库丛集或者库表杂凑。
在资料库丛集方面，很多资料库都有自己的站群解决方案，Oracle 、 Sybase 等都有很好的方案，常用的 MySQL 提供的 Master/Slave 也是类似的方案，您使用了什么样的 DB，就参考相应的站群解决方案来实施即可。
 
 
 
文章来自互联网博客网站，原文出自：http://www.mahaixiang.cn/wzch/806.html