最开始,因为个别看法,于是在互联网上搭建了一个网站,这个时侯甚至有可能主机都是租借的,但因为这篇文章我们只关注构架的演化历程,因而就假定这个时侯早已是托管了一台主机,而且有一定的带宽了,这个时侯因为网站具备了一定的特色,吸引了部份人访问,逐步你发觉系统的压力越来越高,响应速率越来越慢,而这个时侯比较显著的是数据库和应用相互影响,应用出问题了,数据库也很容易出现问题,而数据库出问题的时侯,应用也容易出问题,于是步入了第一步演化阶段:将应用和数据库从数学上分离,弄成了两台机器,这个时侯技术上没有哪些新的要求,但你发觉确实起到疗效了,系统又恢复到先前的响应速率了,但是支撑住了更高的流量,而且不会由于数据库和应用产生相互的影响。
这一步构架演化对技术上的知识体系基本没有要求。
构架演化第二步:降低页面缓存
好景不长,随着访问的人越来越多,你发觉响应速率又开始变慢了,查找缘由,发觉是访问数据库的操作太多,造成数据联接竞争激烈,所以响应变慢,但数据库联接又不能开太多,否则数据库机器压力会很高,因而考虑采用缓存机制来降低数据库联接资源的竞争和对数据库读的压力,这个时侯首先似乎会选择采用squid等类似的机制来将系统中相对静态的页面(比如一十天才能有更新的页面)进行缓存(其实,也可以采用将页面静态化的方案),这样程序上可以不做更改,就能否挺好的降低对webserver的压力以及降低数据库联接资源的竞争,OK,于是开始采用squid来做相对静态的页面的缓存。
后端页面缓存技术linux web服务器架构,比如squid,如想用好的话还得深入把握下squid的实现方法以及缓存的失效算法等。
构架演化第三步:降低页面片断缓存
降低了squid做缓存后,整体系统的速率确实是提高了,webserver的压力也开始增长了,但随着访问量的降低,发觉系统又开始变的有些慢了,在尝到了squid之类的动态缓存带来的益处后,开始想能不能让现今这些动态页面里相对静态的部份也缓存上去呢,因而考虑采用类似ESI之类的页面片断缓存策略,OK,于是开始采用ESI来做动态页面中相对静态的片断部份的缓存。
这一步涉及到了这种知识体系:
页面片断缓存技术,比如ESI等,想用好的话同样须要把握ESI的实现方法等;
构架演化第四步:数据缓存
在采用ESI之类的技术再度增强了系统的缓存疗效后,系统的压力确实进一步增加了,但同样,随着访问量的降低,系统还是开始变慢,经过查找,可能会发觉系统中存在一些重复获取数据信息的地方,像获取用户信息等,这个时侯开始考虑是不是可以将这种数据信息也缓存上去呢,于是将那些数据缓存到本地显存,改变完毕后,完全符合预期,系统的响应速率又恢复了,数据库的压力也再次增加了不少。
这一步涉及到了这种知识体系:
缓存技术,包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
构架演化第五步:降低webserver
好景不长,发觉随着系统访问量的再次降低,webserver机器的压力在高峰期会上升到比较高,这个时侯开始考虑降低一台webserver,这也是为了同时解决可用性的问题,防止单台的webserverdown机的话就无法使用了,在做了这种考虑后,决定降低一台webserver,降低一台webserver时,会遇到一些问题,典型的有:
1、如何让访问分配到这两台机器上,这个时侯一般会考虑的方案是Apache自带的负载均衡方案,或LVS这类的软件负载均衡方案;
2、如何保持状态信息的同步,比如用户session等,这个时侯会考虑的方案有写入数据库、写入储存、cookie或同步session信息等机制等;
3、如何保持数据缓存信息的同步,比如之前缓存的用户数据等,这个时侯一般会考虑的机制有缓存同步或分布式缓存;
4、如何让上传文件这种类似的功能继续正常,这个时侯一般会考虑的机制是使用共享文件系统或储存等;
在解决了这种问题后,总算是把webserver降低为了两台,系统总算是又恢复到了往年的速率。
这一步涉及到了这种知识体系:
负载均衡技术(包括但不限于硬件负载均衡、软件负载均衡、负载算法、linux转发合同、所选用的技术的实现细节等)、主备技术(包括但不限于ARP误导、linuxheart-beat等)、状态信息或缓存同步技术(包括但不限于Cookie技术、UDP合同、状态信息广播、所选用的缓存同步技术的实现细节等)、共享文件技术(包括但不限于NFS等)、存储技术(包括但不限于储存设备等)。
构架演化第六步:分库
享受了一段时间的系统访问量高速下降的幸福后,发觉系统又开始变慢了,此次又是哪些状况呢,经过查找,发觉数据库写入、更新的这种操作的部份数据库联接的资源竞争十分激烈,造成了系统变慢,这下怎样办呢,此时可选的方案有数据库集群和分库策略,集群方面像有些数据库支持的并不是挺好,因而分库会成为比较普遍的策略,分库也就意味着要对原有程序进行更改,一通更改实现分库后,不错,目标达到了,系统恢复甚至速率比先前还快了。
这一步涉及到了这种知识体系:
这一步更多的是须要从业务上做合理的界定,以实现分库,具体技术细节上没有其他的要求;
但同时随着数据量的减小和分库的进行,在数据库的设计、调优以及维护上须要做的更好,因而对这种方面的技术还是提出了很高的要求的。
构架演化第七步:分表、DAL和分布式缓存
随着系统的不断运行,数据量开始大幅度下降,这个时侯发觉分库后查询一直会有些慢,于是根据分库的思想开始做分表的工作,其实,这不可防止的会须要对程序进行一些更改,其实在这个时侯才会发觉应用自己要关心分库分表的规则等,还是有些复杂的,于是萌生能够降低一个通用的框架来实现分库分表的数据访问,这个在ebay的构架中对应的就是DAL,这个演化的过程相对而言须要耗费较长的时间,其实,也有可能这个通用的框架会等到分表做完后才开始做,同时,在这个阶段可能会发觉之前的缓存同步方案出现问题,由于数据量太大,造成现今不太可能将缓存存在本地,之后同步的方法,须要采用分布式缓存方案了,于是,又是一通考察和摧残,总算是将大量的数据缓存转移到分布式缓存上了。
这一步涉及到了这种知识体系:
分表更多的同样是业务上的界定,技术上涉及到的会有动态hash算法、consistenthash算法等;
DAL涉及到比较多的复杂技术,比如数据库联接的管理(超时、异常)、数据库操作的控制(超时、异常)、分库分表规则的封装等;
构架演化第八步:降低更多的webserver
在做完分库分表这种工作后,数据库上的压力早已降到比较低了,又开始过着每晚看着访问量暴增的幸福生活了,忽然有三天,发觉系统的访问又开始有变慢的趋势了,这个时侯首先查看数据库,压力一切正常,然后查看webserver,发觉apache阻塞了好多的恳求,而应用服务器对每位恳求也是比较快的,看来是恳求数太高造成须要排队等待,响应速率变慢,这还好办,通常来说,这个时侯也会有些钱了,于是添加一些webserver服务器,在这个添加webserver服务器的过程,有可能会出现几种挑战:
1、Apache的软负载或LVS软负载等未能承当巨大的web访问量(恳求联接数、网络流量等)的调度了,这个时侯假如经费容许的话,会采取的方案是订购硬件负载,比如F5、Netsclar、Athelon之类的,如经费不容许的话,会采取的方案是将应用从逻辑上做一定的分类,之后分散到不同的软负载集群中;
2、原有的一些状态信息同步、文件共享等方案可能会出现困局,须要进行改进,其实这个时侯会按照情况编撰符合网站业务需求的分布式文件系统等;
在做完这种工作后,开始步入一个看似完美的无限伸缩的时代,当网站流量降低时,应对的解决方案就是不断的添加webserver。
这一步涉及到了这种知识体系:
到了这一步,随着机器数的不断下降、数据量的不断下降和对系统可用性的要求越来越高,这个时侯要求对所采用的技术都要有更为深入的理解,并须要依照网站的需求来做愈发订制性质的产品。
构架演化第九步:数据读写分离和廉价储存方案
忽然有三天,发觉这个完美的时代也要结束了,数据库的恶梦又一次出现在眼前了,因为添加的webserver太多了,造成数据库联接的资源还是不够用,而这个时侯又早已分库分表了,开始剖析数据库的压力状况,可能会发觉数据库的读写比很高,这个时侯一般会想到数据读写分离的方案,其实,这个方案要实现并不容易,另外,可能会发觉一些数据储存在数据库上有些浪费,或则说过分占用数据库资源,因而在这个阶段可能会产生的构架演化是实现数据读写分离,同时编撰一些更为廉价的储存方案,比如BigTable此类。
这一步涉及到了这种知识体系:
数据读写分离要求对数据库的复制、standby等策略有深入的把握和理解,同时会要求具备自行实现的技术;
廉价储存方案要求对OS的文件储存有深入的把握和理解,同时要求对采用的语言在文件这块的实现有深入的把握。
构架演化第十步:步入小型分布式应用时代和廉价服务器群梦想时代
经过前面这个漫长而苦闷的过程,总算是再次迎来了完美的时代,不断的降低webserver就可以支撑越来越高的访问量了,对于小型网站而言,人气的重要毋庸置疑,随着人气的越来越高,各类各样的功能需求也开始爆发性的下降,这个时侯忽然发觉,原先布署在webserver上的那种web应用早已十分庞大了,当多个团队都开始对其进行改动时,可真是相当的不便捷,复用性也相当糟糕,基本是每位团队都做了或多或少重复的事情,并且布署和维护也是相当的麻烦,由于庞大的应用包在N台机器上复制、启动都须要花费不少的时间,出问题的时侯也不是挺好查,另外一个更糟糕的状况是很有可能会出现某个应用上的bug就引起了全站都不可用,还有其他的像调优不好操作(由于机器上布署的应用哪些都要做,根本就难以进行针对性的调优)等诱因,按照这样的剖析,开始痛下决心,将系统按照职责进行分拆,于是一个小型的分布式应用就诞生了,一般,这个步骤须要花费相当长的时间,由于会遇到好多的挑战:
1、拆成分布式后须要提供一个高性能、稳定的通讯框架,但是须要支持多种不同的通讯和远程调用方法;
2、将一个庞大的应用分拆须要花费很长的时间,须要进行业务的整理和系统依赖关系的控制等;
3、如何运维(依赖管理、运行状况管理、错误追踪、调优、监控和报案等)好这个庞大的分布式应用。
经过这一步,差不多系统的构架步入相对稳定的阶段,同时也能开始采用大量的廉价机器来支撑着巨大的访问量和数据量,结合这套构架以及如此多次变迁过程汲取的经验来采用其他各类各样的方式来支撑着越来越高的访问量。
这一步涉及到了这种知识体系:
这一步涉及的知识体系特别的多,要求对通讯、远程调用、消息机制等有深入的理解和把握linux命令详解词典,要求的都是从理论、硬件级、操作系统级以及所采用的语言的实现都有清楚的理解。
运维这块涉及的知识体系也特别的多,多数情况下须要把握分布式并行估算、报表、监控技术以及规则策略等等。
说上去确实不怎样吃力,整个网站构架的精典演化过程都和里面比较的类似,其实,每步采取的方案,演化的步骤有可能有不同,另外,因为网站的业务不同,会有不同的专业技术的需求,这篇blog更多的是从构架的角度来讲解演化的过程,其实,其中还有好多的技术也未在此提到,像数据库集群、数据挖掘、搜索等,但在真实的演进过程中都会利用像提高硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大的流量,因而在真实的发展过程中都会有好多的不同,另外一个小型网站要做到的远远不仅仅里面那些,还有像安全、运维、运营、服务、存储等,要做好一个小型的网站真的很不容易
倘若本文对你有帮助,别忘掉给我个3连,点赞,转发,评论linux web服务器架构,
linux操作系统好吗,俺们上期见。收藏等于白嫖,点赞才是真情。