本文转载自【网站架构13/100】一步步带你，如何网站架构及《大型网站技术架构：核心原理与案例分析》
大型网站软件系统的特点
与传统企业应用系统相比，大型互联网应用具有以下的特点。
- 高并发、大流量：PV量巨大
- 高可用：系统7*24小时不间断服务
- 海量数据：存储管理海量数据，需大量服务器
- 用户分布广泛、网络情况复杂：运营商网络互通难
- 安全环境恶劣：黑客攻击
- 需求快速变更，发布频繁：快速适应市场，满足需求
- 渐进式发展：从小网站慢慢运营成大网站
架构体系的演进
大型网站的挑战主要来自庞大的用户、高并发的访问和海量的数据。任何简单的业务一旦要处理数以P计的数据和面对数以亿计的用户，就会变得很棘手。
大型网站架构就是为了解决这类问题。
单机时代
初始阶段，用户规模很小，一台服务器绰绰有余。应用程序、数据库、文件等所有的资源都部署在一台服务器上。典型案例 LAMP（Linux+Apache+Mysql+PHP）架构。
缺点：存在单点、谈不上可用性
技术点：应用设计要保证可扩展
使用缓存改善性能
有一定的业务量和用户规模了，想提升网站速度，可以考虑使用缓存。
网站访问特点遵循二八定律：80%的业务访问集中在20%的数据上。因此将这小部分数据缓存在内存中，就可以减轻数据库访问压力，提高整个网站的数据访问速度，改善数据库写入性能。
缓存可以分为三种：
- 页面缓存：客户端缓存。减少对网站的访问；
- 本地缓存：缓存在应用服务器上。访问速度快，但受内存限制，且会与应用程序争用内存；
- 远程缓存：缓存在专门的分布式缓存服务器上。远程访问，可以集群，容量不受限制；
缺点：单点，谈不上高可用
技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存
应用服务和数据服务分离
随着业务的发展，一台服务器逐渐不能满足需求：越来越多的访问导致性能变差，越来越多的数据导致存储空间不足。这时就需要将应用和数据分离，使用不同特性的服务器承担不同的服务角色。
- 应用服务器：更快更强大的CPU，处理大量的业务逻辑
- 数据库服务器：更快的硬盘和更大的内存，快速磁盘检索和数据缓存
- 文件服务器：更大的硬盘，存储大量用户上传的文件。
缺点：存在单点、谈不上高可用；
技术点：文件服务器部署、数据库服务器部署
数据库读写分离
虽然加入缓存可以使大部分数据访问不通过数据库就能完成，但仍有部分读操作（缓存访问不命中、缓存过期）和所有写操作需要访问数据库。当用户量达到一定规模，数据库因负载压力过高成为网站的瓶颈。
可以使用数据库读写分离来改善数据库负载压力。目前大部分主流数据库都提供主从热备功能，通过配置两台数据库的主从关系，可以将一台数据库上的数据更新同步到另一台上。 应用服务器写数据时，访问主数据库，主数据库通过主从复制机制将数据同步到从
数据库，之后读数据时，访问从数据库。
缺点：读写分离，增加程序难度，架构变复杂，维护难度增加；
技术点：数据库主从同步部署，实现读写分离
应用服务集群
当应用服务器不足以支撑日益增长的业务需求时，可以通过增加服务器来分担原有服务器的访问及存储压力。使用集群能够解决网站的高并发、海量数据的问题，同时实现系统的可伸缩性。
负载均衡调度器可将来自浏览器的访问请求分发到集群中的任何一台服务器上。
缺点：应用之间缓存、Session一致性问题；
技术点：负载均衡；
集中式缓存、Session集中存储
增加服务器构成集群后可能会出现一些问题。如集群应用之间页面输出缓存和本地缓存一致性的问题，Session保存的问题...。
缺点：不如本地缓存访问快，缓存服务器、Session服务器等仍存在单点问题；
技术点：缓存服务器部署、Session集中存储方案；
动静分离
动静分离也是提高网站相应速度的常用方式。将动态请求与静态请求分离开，减少对应服务器的压力。
另外，可以进一步对静态请求进行缓存。可以需要开发人员配合（把静态资源放独立站点下），也可以不需要开发人员配合（利用7层反向代理来处理，根据后缀名等信息来判断资源类型）。
缺点：静态文件缓存更新失效问题；
技术点：动静分离、静态文件缓存方案；
反向代理和CDN加速网站响应
由于网络环境的复杂性，不同地区的用户访问网站时的速度差别也大。为了提供更好的用户体验，需要加速网站访问速度。主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是缓存。区别在于：
- CDN部署在网络提供商的机房。用户在请求网站服务时，可以从最近的网络提供商机房获取数据。
- 反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的是反向代理服务器，如缓存了用户请求的资源，就直接返回给用户。
缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，静态文件缓存更新失效问题；
技术点：CDN、反向代理方案；
使用NoSQL和搜索引擎
到这里，已经基本做到了DB层面和应用层面的横向扩展了。这时可以采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎来提高数据存储和检索的速度。 NoSQL和搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。
缺点：单点问题，谈不上高可用；
技术点：NoSQL、搜索引擎、分布式；
到目前为止，一个能够承载日均百万级访问量的中型网站架构基本介绍完了。
保证高可用
通过扩展满足了基本的性能需求后，我们会逐渐关注“可用性”（SLA、几个9）。
对关键应用/服务，做集群冗余负载，是保证高可用比较常用的手段：
- 文件系统、数据库系统集群；
- 静态内容服务器集群；
- CDN服务器集群；
- 反向代理服务器集群；
- 负载均衡调度器集群；
- 分布式NoSQL服务器集群；
- 搜索引擎服务器集群；
- 分布式缓存服务器集群；
- 分布式Session服务器集群；
优点：集群负载，保证高可用；
缺点：数据一致性、数据有状态问题；
技术点：负载调度器、集群方案；
目前为止，都没有怎么去改动应用程序的架构，或者说通俗点，都不怎么需要大面积的修改代码。如果上面那些手段都用光了，还是支撑不住怎么办
应用垂直拆分
在业务场景日益复杂的场景下，集中式的应用程序架构逐渐暴露来很多问题，耦合度高，不便开发和维护。因此大型网站使用分而治之的手段将这个网站业务分成不同的产品线，如将首页、商铺、订单、买家、卖家等拆分成不同的产品线，归不同的业务团队负责。 拆分出的每个应用独立部署维护，应用之间可以通过超链接建立关系（首页上的导航连接指向不同的应用地址），也可以通过消息队列进行数据分发，最常用的是访问同一个数据存储系统来构成一个关联的完整系统。
优点：降低耦合、分压；
缺点：应用架构复杂；
技术点：业务抽取拆分；
业务垂直分库
应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作。
优点：降低DB耦合、分压DB；
缺点：数据访问模块复杂；
技术点：业务抽取拆分；
分布式服务化
随着业务越来越小，存储系统越来越庞大，应用系统的整体复杂度成指数级别增加。部署维护越来越困难。由于所有应用要和所有数据库相连，在数万台服务器规模的网站中，连接的树木是服务器规模的平方，导致数据库连接不足，拒绝服务。 既然每一个应用系统都需要执行许多相通的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署，提供共用业务服务，由这些业务连接数据库。这样，传说中的SOA的价值就得到体现了
缺点：应用架构更复杂；
技术点：业务抽取拆分、服务化技术方案；
消息队列
应用、服务之间还是会出现一些依赖问题，这时候，高吞吐量的解耦利器出现了
缺点：存在消息消费延迟问题；
技术点：消息队列技术方案；
分库分表
最后，再介绍一个大型互联网公司都用的绝技--分库分表。个人经验，不是业务发展和各方面非常迫切，不要轻易走这一步。
因为分库分表谁都会干，关键是拆完之后怎么办。目前，市面上还没有完全开源免费的方案，能让你一劳永逸地解决数据库拆分问题。
分库分表：
- 横向拆分；
- 纵向拆分；
- 分布式数据库访问层；
- 数据库中间件（代理）；
大型网站架构演化的价值观
- 核心价值：随网站所需灵活应对；大型网站不是从无到有一步就搭建好一个大型网站，而是能够伴随小型网站业务的渐进发展，慢慢地演化成一个大型网站；
- 驱动力量：网站的业务发展— 业务成就了技术，事业成就了人，而不是相反；
网站架构设计误区
- 一味追随大公司的解决方案
- 为了技术而技术：在技术选型和架构设计中，脱离实际业务，一味追寻时髦的新技术，会进入崎岖小道
- 企图用技术解决所有问题：技术是用来解决业务问题的，而业务的问题，也可以通过业务的手段去解决；
总结
时至今日，大型网站的架构演化方案已经非常成熟，各种技术方案也逐渐产品化。许多小型网站慢慢的不需要再经历大型网站历经的演化之路就可以逐步发展壮大，因为现在很多网站在建立之初就搭建在大型网站提供的云计算服务基础上，所需的一切技术资源都可以按需购买、线性伸缩。
能够亲身经历一个网站逐渐演化成大型网站的架构师越来越少，网站技术架构演化的过程难以重现，因此网站架构师更因该对这个过程深刻了解，理解已成熟的网站架构技术方案的来龙去脉和历史渊源，在技术选型和架构决策时才能有的放矢、直击要害。
