总体设计： 系统架构：

突然有一天，发现这个完美的时代也要结束了，数据库的噩梦又一次出现在眼前了，由于添加的 webserver 太多了，导致数据库连接的资源还是不够用，而这个时候又已经分库分表了，开始分析数据库的压力状况，可能会发现数据库的读写比很高，这个时候通常会想到数据读写分离的方案，当然，这个方案要实现并不 容易，另外，可能会发现一些数据存储在数据库上有些浪费，或者说过于占用数据库资源，因此在这个阶段可能会形成的

随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作，当然，这不可避免的会需要对程序 进行一些修改，也许在这个时候就会发现应用自己要关心分库分表的规则等，还是有些复杂的，于是萌生能否增加一个通用的框架来实现分库分表的数据访问，这个在 ebay 的架构中对应的就是 DAL ，这个演变的过程相对而言需要花费较长的时间，当然，也有可能这个通用的

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的 资源竞争非常激烈，导致了系统变慢，这下怎么办呢，此时可选的方案有数据库集群和分库策 略，集群方面像有些数据库支持的并不是很好，因此分库会成为比较普遍的策略，分库也就意味着要对原有程序进行修改，一通修改实现分库后，不错，目标达到 了，系统恢复甚至速度比以前

好景不长，发现随着系统访问量的再度增加， webserver 机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台 webserver ，这也是为了同时解决可用性的问题，避免单台的 webserver down 机的话就没法使用了，在做了这些考虑后，决定增加一台 webserver ，增加一台 webserver 时，会碰到一些问题，典型的有：   1 、如何让访问分配到这两台机器上，这个

在采用 ESI 之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系 统中存在一些重复获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速度又恢复了，数据库的压力也再度降低了不少。 这一步涉及到了这些知识体系：

增加了 squid 做缓存后，整体系统的速度确实是提升了， webserver 的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了 squid 之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似 ESI 之类的页面片段缓存策略， OK ，于是开始采用 ESI 来做动态页面中相对静态的片段部分的缓存。 这一步涉及到了这

好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用 squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的

最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了 部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而 数据库出问题的时候，应用

经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加 webserver 就可以支撑越来越高的访问量了，对于大型网站而言，人气的重要毋 庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在 webserver 上的那个 web 应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多