分布式Web服务器架构演变形成

开始由于某些想法于互联网上搭建了网站时候甚至有能主机都租借由于篇文章我们只关注架构演变历程因此假设时候已经托管了台主机并且有定带宽了时候由于网站具备了定特色吸引了部分人访问逐渐发现系统压力越来越高响应速度越来越慢而时候比较明显数据库和应用互相影响应用出问题了数据库也容易出现问题而数据库出问题时候应用也容易出问题于进入了第步演变阶段：应用和数据库从物理上分离变成了两台机器时候技术上没有新要求发现确实起效了系统又恢复前响应速度了并且支撑住了更高流量并且会因数据库和应用形成互相影响

步架构演变对技术上知识体系基本没有要求

架构演变第二步：增加页面缓存

   好景长随着访问人越来越多发现响应速度又开始变慢了查找原因发现访问数据库操作太多导致数据连接竞争激烈所响应变慢数据库连接又能开太多否则数据库机器压力会高因此考虑采用缓存机制来减少数据库连接资源竞争和对数据库读压力时候首先也许会选择采用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类软件负载均衡方案；
2、何保持状态信息同步例用户session等时候会考虑方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、何保持数据缓存信息同步例之前缓存用户数据等时候通常会考虑机制有缓存同步或分布式缓存；
4、何让上传文件些类似功能继续正常时候通常会考虑机制使用共享文件系统或存储等；
解决了些问题终于把webserver增加了两台系统终于又恢复了往速度

步涉及了些知识体系：

负载均衡技术（包括限于硬件负载均衡、软件负载均衡、负载算法、linux转发协议、所选用技术实现细节等）、主备技术（包括限于 ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（包括限于Cookie技术、UDP协议、状态信息广播、所选用缓存同步技术实现细节等）、共享文件技术（包括限于NFS等）、存储技术（包括限于存储设备等）

架构演变第六步：分库

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

步更多需要从业务上做合理划分实现分库具体技术细节上没有其要求；

同时随着数据量增大和分库进行数据库设计、调优及维护上需要做更好因此对些方面技术还提出了高要求

架构演变第七步：分表、DAL和分布式缓存
随着系统断运行数据量开始大幅度增长时候发现分库查询仍会有些慢于按照分库思想开始做分表工作当避免会需要对程序进行些修改也许时候会发现应用自己要关心分库分表规则等还有些复杂于萌生能否增加通用框架来实现分库分表数据访问ebay架构对应DAL演变过程相对而言需要花费较长时间当也有能通用框架会等分表做完才开始做同时阶段能会发现之前缓存同步方案出现问题因数据量太大导致现太能缓存存本地同步方式需要采用分布式缓存方案了于又通考察和折磨终于大量数据缓存转移分布式缓存上了
步涉及了些知识体系：
分表更多同样业务上划分技术上涉及会有动态hash算法、consistent hash算法等；

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、何运维（依赖管理、运行状况管理、错误追踪、调优、监控和报警等）好庞大分布式应用
经过步差多系统架构进入相对稳定阶段同时也能开始采用大量廉价机器来支撑着巨大访问量和数据量结合套架构及多次演变过程吸取经验来采用其各种各样方法来支撑着越来越高访问量
步涉及了些知识体系：

步涉及知识体系非常多要求对通信、远程调用、消息机制等有深入理解和掌握要求都从理论、硬件级、操作系统级及所采用语言实现都有清楚理解
运维块涉及知识体系也非常多多数情况下需要掌握分布式并行计算、报表、监控技术及规则策略等等
     说起来确实费力整网站架构经典演变过程都和上面比较类似当每步采取方案演变步骤有能有同另外由于网站业务同会有同专业技术需求篇blog更多从架构角度来讲解演变过程当其还有多技术也未此提及像数据库集群、数据挖掘、搜索等真实演变过程还会借助像提升硬件配置、网络环境、改造操作系统、CDN镜像等来支撑更大流量因此真实发展过程还会有多同另外大型网站要做远远仅仅上面些还有像安全、运维、运营、服务、存储等要做好大型网站真容易