何为大型网站
大型网站架构目标
每个目标背后面临着技术、设计、维护等诸多方面的挑战； 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。
有了问题，也定了伟大的目标，那么网站在不同阶段面对不同的问题，是如何解决的？又是如何一步步成长为大型网站架构，实现这些伟大的目标呢？
如何网站架构
首先，什么是大型网站架构呢？
还有，大型网站架构演进必须避免的几个误区：
- 一味追随大公司的解决方案；
- 为了技术而技术–>常见问题；
- 企图用技术解决所有问题： 技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决；
架构体系演进
单机时代
草根时期，快速开发网站并上线。当然，通常只是先试水，用户规模也没有形成，经济能力和投入也非常有限 。 应用程序、数据库、文件等所有资源都集中在一台 Server上 ，典型案例：基于 LAMP 架构的 PHP 网站；
单机时代（纯依赖RDBMS）
优点：简单、快速迭代达成业务目标；
缺点：存在单点、谈不上高可用；
技术点：应用设计要保证可扩展；
缓存出场
有一定的业务量和用户规模了， 想提升网站速度，于是，缓存出场了 。
数据服务与应用分离
优点：简单有效、方便维护、提高不同Server对硬件资源的利用率；
缺点：存在单点、谈不上高可用；
技术点：文件服务器部署、数据库服务器，扩展数据访问模块；
分离后三台 Server 对硬件资源的需求各不相同：
- 应用服务器： 需要更快更强大的 CPU；
- 数据库服务器： 需要更快的硬盘和更大的内存；
- 文件服务器： 需要更大的硬盘；
数据库读写分离
单台数据库也感觉快撑不住了，一般都会尝试做“读写分离”。由于大部分互联网“读多写少”的特性所决定的。 Salve的台数，取决于按业务评估的读写比例。
数据库读写分离
优点：简单有效、降低数据库单台压力；
缺点：读写分离，增加程序难度，架构变复杂，维护难度增加；
技术点：数据库主从同步部署，扩展数据访问模块，实现读写分离；
应用服务集群
数据库层面是缓解了，但是 应用程序层面也出现了瓶颈，由于访问量增大 ，加上早期程序员水平有限写的代码也很烂，人员流动性也大，很难去维护和优化。所以，很常用的办法还是“堆机器”。
应用出现瓶颈 负载均衡集群
优点：增加服务器和HA机制，系统性能及可用性得到保证；
缺点：应用之间缓存、Session一致性问题；
技术点：负载均衡；
通过 集群 解决高并发、海量数据问题的常用手段，实现系统的可伸缩性。通过负载均衡调度器，可将用户访问分发到集群中的某台 Server 上，应用服务器的负载压力不再成为整个网站的瓶颈。
集中式缓存、Session集中存储
加机器谁都会加，关键是加完之后得有效果， 加完之后可能会引发一些问题。 例如非常常见的： 集群应用之间页面输出缓存和本地缓存一致性的问题，Session保存的问题…… 。
集中式缓存 Session集中存储
优点：应用之间缓存、Session一致，存储无限制，可以扩展；
缺点：不如本地缓存访问快，缓存服务器、Session服务器等仍存在单点问题；
技术点：缓存服务器部署、Session集中存储方案；
动静分离
动静分离也是提高网站响应速度的一种常用方式。 将动态请求与静态请求分离开，尽量减少对应用服务器的压力。同时，可以再进一步对静态请求，进行缓存，以加快响应速度。 可以需要开发人员配合（把静态资源放独立站点下），也可以不需要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。
使用动静分离
优点：减轻应用负载压力，针对静态文件缓存；
缺点：静态文件缓存更新失效问题；
技术点：动静分离、静态文件缓存方案；
反向代理和CDN加速网站响应
使用反向代理和CDN加速网站响应： CDN 和反向代理的基本原理都是缓存 ，区别在于：
- CDN部署在网络提供商的机房；
- 反向代理则部署在网站的中心机房；
使用 CDN 和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
使用反向代理和 CDN 加速网站响应
优点：减轻应用负载压力，异地缓存有效解决不同地方用户访问过慢的问题；
缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，静态文件缓存更新失效问题；
技术点：CDN、反向代理方案；
使用NoSQL和搜索引擎
到这里，已经基本做到了DB层面和应用层面的横向扩展了，可以开始关注一些其它方面，例如： 站内搜索的精准度，对DB的依赖，开始引入全文索引、NoSQL 。
NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。 应用服务器则通过一个统一数据访问模块访问各种数据 ，减轻应用程序管理诸多数据源的麻烦。
使用NoSQL和搜索引擎
优点：降低DB依赖；
缺点：单点问题，谈不上高可用；
技术点：NoSQL、搜索引擎、分布式；
到目前为止，一个能够承载日均百万级访问量的中型网站架构基本介绍完了。
如何保证高可用
在做扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（也就是我们通常听别人吹牛时说的SLA、几个9）。 如何保证真正“高可用”，也是个难题。
对关键应用/服务，做集群冗余负载，这也是保证高可用比较常用的手段：
- 文件系统、数据库系统集群；
- 静态内容服务器集群；
- CDN服务器集群；
- 反向代理服务器集群；
- 负载均衡调度器集群；
- 分布式NoSQL服务器集群；
- 搜索引擎服务器集群；
- 分布式缓存服务器集群；
- 分布式Session服务器集群；
使用集群冗余负载 保证高可用
优点：集群负载，保证高可用；
缺点：数据一致性、数据有状态问题；
技术点：负载调度器、集群方案；
截止目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么需要大面积的修改代码。
如果上面那些手段都用光了，还是支撑不住怎么办？不停的加机器也不是办法啊？
应用垂直拆分
随着业务越来越复杂，网站的功能越来越多，虽然部署层面是采用的集群， 但是应用程序架构层面还是“集中式”的 ，这样会导致很多耦合， 不便于开发、维护，而且容易“一荣俱损” 。所以， 通常会把网站拆分出不同的子站点来单独宿主。
通过分而治之的手段将整个网站业务分成不同的产品线，如首页、商铺、订单、卖家、买家等 拆分成不同的产品线，分归不同的业务团队负责 。各个应用之间可以通过建立一个超链接建立关系，也可以通过消息队列进行数据分发。
应用垂直拆分（分压，解耦）
优点：降低耦合、分压；
缺点：应用架构复杂；
技术点：业务抽取拆分；
业务垂直分库
应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作。
业务垂直分库 分压 解耦
优点：降低DB耦合、分压DB；
缺点：数据访问模块复杂；
技术点：业务抽取拆分；
分布式服务化
拆分应用和DB之后，其实还是会有很多问题。 不同的站点，里面可能会有相同逻辑和功能的代码。 当然，对于一些基础的功能我们可以封装DLL或者Jar包去到处提供引用，但是这种强依赖也很容易造成一些问题（版本问题、依赖关系等处理起来非常麻烦）。
既然每一个应用系统都需要执行许多相通的业务操作，比如用户管理、商品管理等， 那么可以将这些共用的业务提取出来，独立部署 。这样，传说中的SOA的价值就得到体现了。
分布式服务化（解耦，去重复）
优点：服务统一管理，提供重用度；
缺点：应用架构更复杂；
技术点：业务抽取拆分、服务化技术方案；
消息队列
应用、服务之间还是会出现一些依赖问题，这时候， 高吞吐量的解耦利器出现了 。
消息队列（服务间异步解耦 高吞吐量）
优点：提高吞吐量、应用、服务之间解耦；
缺点：存在消息消费延迟问题；
技术点：消息队列技术方案；
分库分表
最后，再介绍一个大型互联网公司都用的绝技– 分库分表 。个人经验， 不是业务发展和各方面非常迫切，不要轻易走这一步 。
因为分库分表谁都会干，关键是拆完之后怎么办。目前，市面上还没有完全开源免费的方案，能让你一劳永逸地解决数据库拆分问题。
本文思维导图
欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，只聊架构，不聊其他！打造最有价值的架构师圈子和社区。
长按下方的二维码可以快速关注我们
