本篇博客摘抄自书籍《大型网站系统与Java中间件实践》与《大型网站技术架构核心原理与案例分析》。
1 什么是大型网站
衡量一个网站是否为大型网站，访问量和数据量二者缺一不可。除了海量数据和高并发的访问量，本身业务和系统的复杂度也是考察的方面。大型网站的技术挑战主要来自于庞大的用户，高并发的访问和海量的数据，任何简单的业务一旦需要处理数以P计的数据和面对数以亿计的用户，问题就会变的很棘手。大型网站架构主要就是解决这类问题。
2 大型网站架软件系统的特点
与传统企业应用系统相比，大型互联网应用系统有以下特点。
- （1）高并发，大流量
需要面对高并发用户，大流量访问。Google日均PV数35亿，日均IP访问数3亿；腾讯QQ的最大在线用户数1.4亿（2011年数据）；淘宝2012年“双十一”活动一天交易额超过192亿，活动开始第一分钟独立访问用户达1000万。 - （2）高可用
系统7*24小时不间断服务。大型互联网站的宕机事件通畅会成为新闻焦点。 - （3）海量数据
需要存储、管理海量数据，需要使用大量服务器。Facebook每周上传的照片数据接近10亿，百度收录的网页数目数百亿，Google有近百万台服务器为全球用户提供服务。 - （4）用户分布广泛、网络情况复杂
许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。在国内，还有各个运营商网络互通难的问题。而中美光缆的数次故障，也让一些对国内外用户依赖较大的网站不得不考虑在海外建立数据中心。 - （5）安全环境恶劣
由于互联网的开放性，使得互联网站更容易受到攻击，大型网站几乎每天都会被黑客攻击。2011年国内多个重要网站泄露用户密码，让普通用户也直面一次互联网安全问题。 - （6）需求快速变更，发布频繁
和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率是极高的。Office的产品版本以年为单位发布，而一般大型网站的产品美洲都有新版本发布上线，至于中小型网站的发布就更频繁了。 - （7）渐进式发展
与传统软件产品或企业应用系统已开始就规划好全部的功能和非功能需求不同，几乎所有的大型互联网站都是从一个小网站开始，渐进地发展起来的。好的互联网产品都是满满运营出来的，不是一开始就开发好的，这也正好与网站架构的发展演化过程对应。
3 大型网站架构的演进
3.1 单机网站：初始阶段的网站架构
大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来。小型网站最开始时没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如下图所示：
应用程序、数据库、文件等所有资源都在一台服务器上。通畅服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件及一台廉价服务器就可以开始网站的发展之路了。
3.2 单机负载告警，应用服务与数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足。这时就需要将应用和数据分离。应用和数据分离后整个网站使用三台服务器：应用服务器、文件服务器和数据库服务器，如下图所示。
这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘盒更大的内存；文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘。
应用和数据分离后，不同特性的服务器承担不同的服务角色，网站的并发处理能力和数据存储空间得到了很大改善，支持网站业务进一步发展。但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响。这时需要对网站架构进一步优化。
3.3 数据库压力太大导致访问延迟，使用缓存改善网站性能
网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。既然大部分的业务访问集中在一小部分数据上，那么如果把这一小部分数据缓存在内存中，是不是就可以减少数据库的访问压力，提高整个网站的数据访问速度，改善数据库的写入性能了呢？
网站使用的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况。远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。如下图所示。
使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站访问高峰期，应用服务器称为整个网站的瓶颈。
3.4 应用服务器负载告警，使用应用服务器集群改善网站的并发处理能力
使用集群是网站解决高并发、海量数据问题的常用手段。当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。
对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种，如下图所示：
通过负载均衡调度服务器，可将来自用户浏览器的访问请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再称为整个网站的瓶颈。
应用服务器走向集群后，有两个问题需要解决：
- （1）最终用户对多个应用服务器访问的选择问题，可以通过DNS来解决，也可以通过在应用服务器集群前增加负载均衡设备来解决。上图采用第二种方式；
- （2）Session问题：当一个带有会话标识的HTTP请求到了Web服务器后，需要在HTTP请求的处理过程中找到对应的会话数据（Session）。而问题就在于，会话数据是需要保存在单机上的。如果第一次访问网站时请求落到了某一台服务器上，那么session就创建在该服务器上了，如果不做处理，就不能保证接下来的请求每次都落在该服务器上，这就是Session问题。以下是该问题的四种解决方案。
- a、Session Sticky
负载均衡服务器根据每次请求的会话标识来进行请求转发，保证同一个会话的请求都在同-一个web服务器上处理，那么对这个会话的个体来说，与之前单机的情况是一样的。 - b、Session Replication
Web服务器之间增加会话数据的同步，通过同步就保证了不同Web服务器之间的Session数据的一致。 - c、Session数据集中存储
把Session数据集中存储起来，然后不同Web服务器从同样的地方来获取Session。存储方式，可以使用数据库，也可以使用其他分布式存储系统。 - d、Cookie Based
通过Cookie来传递Session数据。Session数据放在Cookie中，然后再Web服务器上葱Cookie中生成对应的Session数据。
- a、Session Sticky
3.5 数据库压力变大，数据库读写分离
网站在使用缓存后，使觉阿部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。如下图所示：
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通畅在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。
提到读写分离，我们更多的是想到数据库层面。事实上，广义的读写分离可以扩展到更多的场景。我们看一下读写分离的特点。简单来说，就是在原有读写设施的基础上增加了读“库”，更适合的说法应该是增加了读“源”，因为它不一定是数据库，而只是提供读服务的，分担原来的读写库中读的压力。例如搜索引擎其实是一个读库。搜索引擎的技术解决了站内搜索时某些场景下读的问题，提供了更好的查询效率。并且我们看到的站内搜索的结构和使用读库是非常类似的，我们可以把搜索引擎当成一个读库。缓存系统和搜索引擎、读库的定位是很类似的。
3.6 使用反向代理和CDN加速网站响应
随着网站业务不断发展，用户规模越来越大，由于中国复杂的网络环境，不同地区的用户访问网站时，速度差别也极大。为了提供更好的用户体验，留住用户，网站需要加速网站访问速度。主要手段有使用CDN和反向代理。如下图所示。
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，是用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
使用CDN和反向代理的目的都是今早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
3.7 使用分布式文件系统和分布式数据库系统
一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也是一样，需要使用分布式文件系统。如下图所示：
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。有数据垂直拆分和水平拆分两种选择。
垂直拆分的意思是把数据库中不同的业务数据拆分到不同的数据库中。此时，应用需要配置多个数据源，这就增加了所需的配置，不过带来的是每个数据库连接池的隔离。不同业务的数据从原来的一个数据库拆分到了多个数据库中，那么久需要考虑如何处理原来单机中跨业务的事务。一种办法是使用分布式事务，其性能要明显低于之前的单机事务；而另一种办法就是去掉事务活着不去追求强事务支持，则原来在单库中可以使用的表关联查询也就需要改变实现了。对数据进行垂直拆分后，解决了把所有业务数据放在一个数据库中的压力问题。并且也可以根据不同业务的特点进行更多优化。
数据水平拆分就是把同一个表的数据柴刀两个数据库中。产生数据水平拆分的原因是某个业务的数据表的数据量或者更新量达到了单个数据库的瓶颈，这时就可以把这个表拆到两个或者多个数据库中。数据水平拆分与读写分离的区别是，读写分离解决的是读压力大的问题，对于数据量大或者更新量的情况并不起作用。数据进行水平拆分后给业务带来的影响有以下几个方面：
- （1）应用系统需要解决SQL路由的问题，因为现在信息被分在了两个数据库中，需要在进行数据库操作时了解需要操作的数据库在哪里；
- （2）主键的处理也会变的不同。原来依赖单个数据库的一些机制需要变化，例如原来使用Oracle的Sequence或者MySQL表上的自增字段的，现在不能简单的继续使用了。并且在不同的数据库中也不能直接使用一些数据库的限制来保证主键不重复了；
- （3）由于一个业务的数据被拆分到了不同的数据库中，因此一些查询需要从两个数据库中取数据，如果数据量太大而需要分页，就会比较难处理了。
3.8 弥补关系型数据库的不足，使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和肺数据库查询技术和搜索引擎。如下图所示；
NoSQL喝搜索引擎都是源自互联网的技术手段，对可伸缩的分布式特性具有更好的支持。应用服务器则通过一个统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
3.9 业务拆分
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。
具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过一个超链接建立关系（子啊首页上的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据库存储系统来构成一个关联的完整系统。如下图所示：
3.10 分布式服务
随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平房，导致存数据库资源不足，拒绝服务。
既然没一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用公共业务服务完成具体业务操作，如下图所示。
