第一篇：概述

传统的企业应用系统主要面对的技术挑战是处理复杂凌乱、千变万化的所谓业务逻辑，而大型网站主要面对的技术挑战是处理超大量的用户访问和海量的数据处理；前者的挑战来自功能性需求，后者的挑战来自非功能性需求；功能性需求也许还有“人月神话”聊以自慰，通过增加人手解决问题，而非功能需求大多是实实在在的技术难题，无论有多少工程师，做不到就是做不到。

“好的设计绝对不是模仿、不是生搬硬套某个模式，而是在对问题深刻理解之上的创造与创新，即使是‘微创新’，也是让人耳目一新的似曾相识。

京东促销不能购买的例子：

能够正常访问购物车，却不能成功购买，问题应该是出在订单系统，B 2C网站生成一个订单需要经历扣减库存、扣减促销资源、更新用户账户等一系列操作，这些操作大多是数据库事务操作，没有办法通过缓存等手段来减轻数据库服务器负载压力，如果事前没有设计好数据库伸缩性架构，那么京东的技术团队将遇到一个大麻烦。

1.大型网站架构演化

如何打造一个高可用、高性能、易扩展、可伸缩且安全的网站？如何让网站随应用所需灵活变动，即使是山寨他人的产品，也可以山寨的更高、更快、更强，一年时间用户数从零过亿呢？

1.1大型网站软件系统的特点

有以下特点：

1.高并发，大流量
2.高可用：系统24小时不间断服务
3.海量数据
4.用户分布广泛，网络情况复杂
5.安全环境恶劣
6.需求快速变更，发布频繁
7.渐进式发展

1.2大型网站架构演化发展历程

1.初始阶段的网站架构

应用程序，数据库，文件等所有的资源都在一台服务器上。

2.应用服务和数据服务分离

应用和数据分离后整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器。如下图所示：

这三台服务器对硬件资源的要求各不相同：

1.应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU
2.数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存
3.文件服务器需要存储大量用户上传的文件，因此需要更大的磁盘

随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响。

3.访问缓存改善网站性能

网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。

网站使用的缓存可以分为两种：缓存在1.应用服务器上的本地缓存和缓存在专门的2.分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务，如图：

使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站高峰期，应用服务器成为整个网站的瓶颈。

4.使用应用服务器集群改善网站的并发处理能力

使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。架构如图：

5.数据库读写分离

目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。如图：

6.使用反向代理和CDN加速网站响应

CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。架构如图：

使用CDN和反向代理的目的是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻了后端服务器的负载压力。

7.使用分布式文件系统和分布式数据库系统

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。

8.使用NoSQL和搜索引擎

9.业务拆分

10.分布式服务

既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作，如图：

1.4网站架构设计误区

误区：

1.一味追随大公司的解决方案
2.为了技术而技术
3.企图用技术解决所有问题

比如说12306网站：

12306真正的问题其实不在于它的技术架构，而在于它的业务架构：12306根本就不应该在几亿中国人一票难求的情况下以窗口售票的模式在网上售票(零点开始出售若干天后的车票)。12306需要重构的不仅是它的技术架构，更重要的是它的业务架构：调整业务需求，换一种方式卖票，而不要去搞促销秒杀这种噱头式的游戏。

后来证明12306确实是朝这个方向发展的：在售票方式上引入了排队机制、整点售票调整为分时段售票。其实如果能控制住并发访问的量，很多棘手的技术问题也就不是什么问题了。

2.大型网站架构模式

关于什么是模式，这个来自建筑学的词汇是这样定义的：“每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作”。模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。

2.1网站架构模式

1.分层

分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。

分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件、操作系统、应用软件也可以看作是一种分层结构。在大型网站架构中也采用分层结构，将网站软件系统分为1.应用层、2.服务层、3.数据层，如表：

但是分层架构也有一些挑战，就是必须合理规划层次边界和接口，在开发过程中，严格遵循分层架构的约束，禁止跨层次的调用(应用层直接调用数据层)及逆向调用(数据层调用服务层，或者服务层调用应用层)。

2.分割

对软件进行纵向切分。

3.分布式

对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

在网站应用中，常用的分布式方案有如下几种：

1.分布式应用和服务

将分层和分割后的应用和服务模块分布式部署，除了可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗外；还可以使不同应用复用共同的服务，便于业务功能扩展。

2.分布式静态资源

网站的静态资源如JS， CSS， Logo图片等资源独立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度；由负责用户体验的团队进行开发维护有利于网站分工合作，使不同技术工种术业有专攻。

3.分布式数据和存储

大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据需要分布式存储。除了对传统的关系数据库进行分布式部署外，为网站应用而生的各种NoSQL产品几乎都是分布式的。

4.分布式计算

目前网站普遍使用Hadoop及其M apR educe分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

4.集群

5.缓存

缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。

使用缓存的例子：CDN，反向代理，本地缓存，分布式缓存。

使用缓存有两个前提条件：

1.数据访问热点不均衡。
2.数据在某个时间段内有效，不会很快过期，否则缓存的数据就会因已经失效而产生脏读，影响了结果的正确性。

6.异步

7.冗余

8.自动化

9.安全

2.2架构模式在新浪微博中的应用

新浪微博的架构在较短的时间内几经重构，最终形成了现在的架构：

系统分为三个层次，最下层是基础服务层，提供数据库，缓存，存储，搜索等数据服务，以及其他一些基础技术服务，这些服务支撑了整个新浪微博的海量数据和高并发访问，是整个系统的技术基础。

中间层是平台服务和应用服务层，新浪微博的核心服务是微博、关系和用户，它们是新浪微博业务大厦的支