大型网站的演变过程

前⾔随着互联⽹的不断发展，以及⽹站负载的不断增⾼，⼀个成熟⽹站的架构需要满⾜下⾯的⼏点，才能为⽤户提供稳定可⽤的服务⾼并发、⼤流量：PV 量巨⼤；⾼可⽤：7*24 ⼩时不间断服务；海量数据：⽂件数⽬分分钟 xxTB；

⽤户分布⼴泛，⽹络情况复杂：⽹络运营商；安全环境恶劣：⿊客的攻击；

需求快速变更，发布频繁：快速适应市场，满⾜⽤户需求；渐进式发展：慢慢地运营出⼤型⽹站；⽬标解决了上述问题之后，我们需要达到⼀个什么样的⽬标和⽬的呢？

每个⽬标背后⾯临着技术、设计、维护等诸多⽅⾯的挑战； ⽽⽬标本⾝的期望值也会根据实际情况进⾏调整，这也意味着⽹站架构建设是个不断调整的过程。

有了问题，也定了伟⼤的⽬标，那么⽹站在不同阶段⾯对不同的问题，是如何解决的？⼜是如何⼀步步成长为⼤型⽹站架构，实现这些伟⼤的⽬标呢？架构体系演进1. 单机时代

草根时期，快速开发⽹站并上线。当然，通常只是先试⽔，⽤户规模也没有形成，经济能⼒和投⼊也⾮常有限。应⽤程序、数据库、⽂件等所有资源都集中在⼀台 Server上，典型案例：基于 LAMP 架构的 PHP ⽹站；

优点：简单、快速迭代达成业务⽬标；缺点：存在单点、谈不上⾼可⽤；技术点：应⽤设计要保证可扩展；

2. 缓存出场

当⽹站发展到有⼀定的业务量和⽤户规模，⽹站的访问速度变慢，主要瓶颈是在数据库上，所以此时再⽤草根时代的架构显然已经不能满⾜我们业务的需求了，那想提升⽹站速度，就需要解决数据库上的瓶颈，于是，缓存出场了。

单机时代+缓存

优点：简单有效、⽅便维护；

缺点：存在单点、谈不上⾼可⽤；

技术点：客户端（浏览器）缓存、前端页⾯缓存、页⾯⽚段缓存、本地数据缓存/数据库缓存、远程缓存；缓存分类：

页⾯缓存：客户端缓存，减少对⽹站的访问；

本地缓存：访问速度快，但数据量有限，减少对DB查询；远程缓存：远程访问，可以集群，因此容量不受限制；

3. 数据库和应⽤逻辑分离

市场反响还不错，⽤户量每天在增长，数据库疯狂读写，逐渐发现⼀台服务器快撑不住了。于是，决定把数据服务和应⽤逻辑业务做分离。

数据库和应⽤逻辑分离

优点：简单有效、⽅便维护、提⾼不同Server对硬件资源的利⽤率；缺点：存在单点、谈不上⾼可⽤；

技术点：⽂件服务器部署、数据库服务器，扩展数据访问模块；

分离后三台 Server 对硬件资源的需求各不相同：

应⽤服务器：需要更快更强⼤的 CPU；

数据库服务器：需要更快的硬盘和更⼤的内存；⽂件服务器：需要更⼤的硬盘；

4. 单台数据库也感觉快撑不住了，⼀般都会尝试做“读写分离”。由于⼤部分互联⽹“读多写少”的特性所决定的。Salve的台数，取决于按业务评估的读写⽐例

数据库读写分离

优点：简单有效、降低数据库单台压⼒；

缺点：读写分离，增加程序难度，架构变复杂，维护难度增加；

技术点：数据库主从同步部署，扩展数据访问模块，实现读写分离；

5. 应⽤服务集群

数据库层⾯是缓解了，但是应⽤程序层⾯也出现了瓶颈，由于访问量增⼤，加上早期程序员⽔平有限写的代码也很烂，⼈员流动性也⼤，很难去维护和优化。所以，很常⽤的办法还是“堆机器”。

应⽤出现瓶颈 负载均衡集群

优点：增加服务器和HA机制，系统性能及可⽤性得到保证；缺点：应⽤之间缓存、Session⼀致性问题；技术点：负载均衡；

通过集群解决⾼并发、海量数据问题的常⽤⼿段，实现系统的可伸缩性。通过负载均衡调度器，可将⽤户访问分发到集群中的某台 Server上，应⽤服务器的负载压⼒不再成为整个⽹站的瓶颈

6. 集中式缓存、Session集中存储

加机器谁都会加，关键是加完之后得有效果，加完之后可能会引发⼀些问题。例如⾮常常见的：集群应⽤之间页⾯输出缓存和本地缓存⼀致性的问题，Session保存的问题……

集中式缓存 Session集中存储

优点：应⽤之间缓存、Session⼀致，存储⽆限制，可以扩展；

缺点：不如本地缓存访问快，缓存服务器、Session服务器等仍存在单点问题；技术点：缓存服务器部署、Session集中存储⽅案；

7. 动静分离

动静分离也是提⾼⽹站响应速度的⼀种常⽤⽅式。将动态请求与静态请求分离开，尽量减少对应⽤服务器的压⼒。同时，可以再进⼀步对静态请求，进⾏缓存，以加快响应速度。可以需要开发⼈员配合（把静态资源放独⽴站点下），也可以不需要开发⼈员配合（利⽤7层反向代理来处理，根据后缀名等信息来判断资源类型）

动静分离好处

优点：减轻应⽤负载压⼒，针对静态⽂件缓存；缺点：静态⽂件缓存更新失效问题；

技术点：动静分离、静态⽂件缓存⽅案；

8. 反向代理和CDN加速⽹站响应

使⽤反向代理和CDN加速⽹站响应：CDN和反向代理的基本原理都是缓存，区别在于：CDN部署在⽹络提供商的机房；反向代理则部署在⽹站的中⼼机房；

使⽤ CDN 和反向代理的⽬的都是尽早返回数据给⽤户，⼀⽅⾯加快⽤户访问速度，另⼀⽅⾯也减轻后端服务器的负载压⼒

使⽤CDN和反向代理加速⽹站响应

优点：减轻应⽤负载压⼒，异地缓存有效解决不同地⽅⽤户访问过慢的问题；

缺点：成本⼤幅增加，架构进⼀步复杂化，也维护难度进⼀步增⼤，静态⽂件缓存更新失效问题；技术点：CDN、反向代理⽅案；

9. 使⽤NoSQL到这⾥，已经基本做到了DB层⾯和应⽤层⾯的横向扩展了，可以开始关注⼀些其它⽅⾯，例如：站内搜索的精准度，对DB的依赖，开始引⼊全⽂索引、NoSQL

NoSQL和搜索引擎都是源⾃互联⽹的技术⼿段，对可伸缩的分布式特性具有更好的⽀持。应⽤服务器则通过⼀个统⼀数据访问模块访问各种数据，减轻应⽤程序管理诸多数据源的⿇烦

优缺点

优点：降低DB依赖；

缺点：单点问题，谈不上⾼可⽤；

技术点：NoSQL、搜索引擎、分布式；

到⽬前为⽌，⼀个能够承载⽇均百万级访问量的中型⽹站架构基本介绍完了如何保证⾼可⽤在做扩展满⾜了基本的性能需求后，我们会逐渐关注“可⽤性”（也就是我们通常听别⼈吹⽜时说的SLA、⼏个9）。如何保证真正“⾼可⽤”，也是个难题。

对关键应⽤/服务，做集群冗余负载，这也是保证⾼可⽤⽐较常⽤的⼿段⽂件系统、数据库系统集群；静态内容服务器集群；CDN服务器集群；反向代理服务器集群；负载均衡调度器集群；

分布式NoSQL服务器集群；搜索引擎服务器集群；分布式缓存服务器集群；分布式Session服务器集群

集群保证⾼可⽤

优点：集群负载，保证⾼可⽤；

缺点：数据⼀致性、数据有状态问题；技术点：负载调度器、集群⽅案；

截⽌⽬前为⽌，都没有怎么去改动应⽤程序的架构，或者说通俗点，都不怎么需要⼤⾯积的修改代码。如果上⾯那些⼿段都⽤光了，还是⽀撑不住怎么办？不停的加机器也不是办法啊？应⽤垂直拆分

随着业务越来越复杂，⽹站的功能越来越多，虽然部署层⾯是采⽤的集群，但是应⽤程序架构层⾯还是“集中式”的，这样会导致很多耦合，不便于开发、维护，⽽且容易“⼀荣俱损”。所以，通常会把⽹站拆分出不同的⼦站点来单独宿主

通过分⽽治之的⼿段将整个⽹站业务分成不同的产品线，如⾸页、商铺、订单、卖家、买家等拆分成不同的产品线，分归不同的业务团队负责。各个应⽤之间可以通过建⽴⼀个超链接建⽴关系，也可以通过消息队列进⾏数据分发

应⽤垂直拆分优点：降低耦合、分压；缺点：应⽤架构复杂；技术点：业务抽取拆分

消息队列应⽤、服务之间还是会出现⼀些依赖问题，这时候，⾼吞吐量的解耦利器出现了

消息队列（服务间异步解耦 ⾼吞吐量）

优点：提⾼吞吐量、应⽤、服务之间解耦；缺点：存在消息消费延迟问题；技术点：消息队列技术⽅案；分库分表最后，再介绍⼀个⼤型互联⽹公司都⽤的绝技–分库分表。个⼈经验，不是业务发展和各⽅⾯⾮常迫切，不要轻易⾛这⼀步。因为分库分表谁都会⼲，关键是拆完之后怎么办。⽬前，市⾯上还没有完全开源免费的⽅案，能让你⼀劳永逸地解决数据库拆分问题。分库分表：

横向拆分；纵向拆分；

分布式数据库访问层；数据库中间件（代理）；总结上⾯讲述了在⽹站业务发展的不同阶段，会⾯临不同的问题，针对不同的问题，会选择不同的架构。⼤型⽹站架构就是在不同阶段时解决不同问题的过程中慢慢演进来的。最后⼏句话，送给有缘的你：

⼀切以解决业务⽬标为⾸要任务；

没有以业务为⽬标的任何架构、技术，都是毫⽆意义的耍流氓；

再⽜逼的架构、再⽜逼的技术，不能够解决业务的问题，你也只能算是会架构、会技术的⼯匠，⽽不能算是真正意义上的架构师；业务成就了技术，平台成就了⼈，事业成就了⼈，⽽不是相反