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