提高web软件工作效率的方法.pdfVIP

大型网站架构演变 来源： BlueDavy 之技术 Blog 整理: 软体疯子专栏 之前也有一些介绍大型网站架构演变的文章，例如 LiveJournal 的、ebay 的，都是非常值得 参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样 的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是 有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一 种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点 初步的概念，:-)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。 架构演变第一步：物理分离webserver 和数据库 最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租 借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已 经是托管了一 台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问， 逐渐你发现系统的压力越来越高，响应速度越来越慢，而这 个时候比较明显的是数据库和 应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也 容易出问题，于是进入了第一步演变阶段： 将应用和数据库从物理上分离，变成了两台机 器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响 应速度了，并且支撑住了更 高的流量，并且不会因为数据库和应用形成互相的影响。 看看这一步完成后系统的图示： 这一步涉及到了这些知识体系： 这一步架构演变对技术上的知识体系基本没有要求。 架构演变第二步：增加页面缓存 好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问 数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连 接又不能开太多， 否则数据库机器压力会很高，因此考虑 用缓存机制来减少数据库连接资源的竞争和对数据 库读的压力，这个时候首先也许会选择 用 squid 等类似的机制来将系统中相对静态的页面 （例如一两天才会有更新的页面）进行缓存（当然，也可以 用将页面静态化的方案），这 样程序上可以不做修改，就能够 很好的减少对webserver 的压力以及减少数据库连接资源的 竞争，OK，于是开始 用 squid 来做相对静态的页面的缓存。 看看这一步完成后系统的图示： 这一步涉及到了这些知识体系： 前端页面缓存技术，例如 squid，如想用好的话还得深入掌握下squid 的实现方式以及缓存的 失效算法等。 架构演变第三步：增加页面片段缓存 增加了 squid 做缓存后，整体系统的速度确实是提升了，webserver 的压力也开始下降了，但 随着访问量的增加，发现系统又开始变的有些慢了，在尝 到了 squid 之类的动态缓存带来的 好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑 用 类似ESI 之类的页面片段缓存策略，OK，于是开始 用 ESI 来做动态页面中相对静态的片 段部分的缓存。 看看这一步完成后系统的图示： 这一步涉及到了这些知识体系： 页面片段缓存技术，例如 ESI 等，想用好的话同样需要掌握ESI 的实现方式等； 架构演变第四步：数据缓存 在 用 ESI 之类的技术再次提高了系统的缓存效果后，系统的压力确实进一步降低了，但同 样，随着访问量的增加，系统还是开始变慢，经过查找，可能会发现系 统中存在一些重复 获取数据信息的地方，像获取用户信息等，这个时候开始考虑是不是可以将这些数据信息也 缓存起来呢，于是将这些数据缓存到本地内存，改变完毕后，完全符合预期，系统的响应速 度又恢复了，数据库的压力也再度降低了不少。 看看这一步完成后系统的图示： 这一步涉及到了这些知识体系： 缓存技术，包括像Map 数据结构、缓存算法、所选用的框架本身的实现机制等。 架构演变第五步： 增加webserver 好景不长，发现随着系统访问量的再度增加，webserver 机器的压力在高峰期会上升到比较 高，这个时候开始考虑增加一台webserver ，这也是为了同时解决可用性的问题，避免单台 的webserver down 机的话就没法使用了，在做了这些考虑后，决定增加一台webserver ，增 加一台webserver 时，会碰到一些问题，典