读《大型网站技术架构》(一)

今天,终于又拿起了放置了一段时间的《大型网站技术架构》,为了回忆并加深前段时间看的内容,就决定写一篇笔记吧。

书中第一章让我知道,大型网站通常是从小型网站发展而成的,那小型网站在发展扩张的过程中,该对架构进行哪些升级呢?

通常,一个小型网站最初只有一台服务器,那么升级的第一步便是将应用服务与数据服务进行分离,也就是说,应用程序、文件、数据库各一个服务器,这样可以很大的改善网站的并发处理能力。

第二步,便是使用缓存,通常,一个网站的访问特点是大量的访问集中在小部分数据上,于是我们便可以对这部分数据进行缓存,这样就可以大量缓解数据库访问压力。缓存分为本地缓存(缓存于应用服务器内)和远程分布式缓存两种,本地缓存虽然具有响应快速的特点,但是具有与应用程序争夺计算资源的缺点,故只缓存重要内容,其他使用远程分布式缓存,且远程分布式缓存服务器可以使用集群,这样便可在理论上做到无限容量的缓存服务。

现在,我们有了四个服务器,分别是应用服务器、缓存服务器(可采用集群)、文件服务器、数据库服务器,数据访问已经不再是网站的瓶颈了。但是,大量增长的数据请求使得单一的应用服务器压力剧增,是时候增加应用服务器了。我们可以采用增加一台应用服务器的方式来缓解压力,同时增加一台负载均衡调度服务器,来为两台应用服务器分发请求。这样,我们可以在需要的时候再增加应用服务器了,并且,当一台应用服务器宕机的时候,网站不至于无法访问,这种同一个业务部署在多个服务器上的方式叫集群。

这样一番扩张下来,我们的大部分读数据、网站请求的接受已经可以不再担心了,是时候考虑一下部分读数据(缓存过期、无缓存)、写数据时,数据库服务器应负载压力过大而产生问题了,毕竟现在只有一台数据库服务器。我们可以对服务器进行读写分离,,其中主数据库服务器用于写操作,从数据库服务器用于读数据,应用服务器写数据时,访问主数据库,主数据库在写操作完成后,将数据同步更新到从数据库中。这样,应用服务器便可从从数据库读数据了。

至此,我们可以开始优化响应速度了(当然也可以先对文件服务器、数据库服务器进行集群)。中国大陆幅员辽阔、网络环境复杂,不同地区访问同一个服务器时,响应速度也不尽相同,我们可以采用CDN和反向代理,两者的基本原理都是缓存。CDN是部署在不同的地理位置的网络提供商的机房,用户可以从距离自己最近的机房获取数据,而反向代理则是部署在网站的中心机房中,用户请求到达中心机房时,如果反向代理服务器缓存着用户请求的资源,就将其直接返回。

这般扩张下来,网站只剩下文件服务器、数据库服务器未进行集群了,当网站遇到对应的问题时,便可将对应服务器进行集群,不过,通常对于数据库,优先采用业务分库来提高负载,分布式数据库只是作为备选方案。

接下来还有几个网站扩张的技术,不过对我来说有点过于深入了,有点不会总结,便不在此叙述了。

以及,网站架构应避免以下几个误区:

1. 一味追随大公司的解决方案,直接采用大公司的经验与成功模式很简单,但也需要思考这种模式是否适合自身网站的情况。

1. 为了技术而技术,脱了网站业务发展的实际,使网站技术发展之路越走越窄

2. 企图用技术解决所有问题:在书中的这个误区中,作者提到了12306在2012年年初的故障事件,该事件的问题在于,12306对售票采用了秒杀机制,极大的提高了短时间的请求并发量,需要修改购票机制。之后12306确实是如此做的,在售票方式上加入了排队机制、整点售票调整未分时段售票。如此便极大的降低了短时间的并发数。

猜你喜欢

转载自www.cnblogs.com/FreezeNow/p/12142081.html
今日推荐