看完了有一本书，就应该有所收获，有所总结，最近把《大型网站技术架构》一书给看完了，给人的印象实在深刻，再加上之前也搞过书本上讲的反向代理和负载均衡以及session独立存储和缓存，因此书本看起来还是挺通俗易懂的，而且作者李智慧给人的印象（书本）也挺深刻的，我从这本书中也学到了许多，了解的许多，但是理解还是比较抽象的，写出来才是真正的理解，因此准备写一系列的博客来介绍和加深理解大型网站技术架构。
说道大型网站，就的先说大型网站的特点：高并发，大流量，高可用，海量数据等。下面就说说大型网站的架构演化过程吧。
1、初始阶段的网站架构
初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图。
2、应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图。
3、使用缓存改善网站性能
毫无疑问，现在的网站基本上都会使用缓存，即：80%的业务访问都会集中在20%的数据上。
4、使用应用服务器集群改善网站的并发处理能力
因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。因此使用负载均衡处理器势在必然。通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。
5、数据库读写分离
当用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。而目前主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库的数据更新同步到另一台服务器上。网站利用数据库这一功能实现数据库读写分离，从而改善数据库负载压力。
6、使用反向代理和CDN加上网站相应
提高网站的访问速度，主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理是部署在网站的中心机房，当用户请求到达中心机房后，首先访问的反向代理，如果反向代理缓存着用户请求的资源，则直接返回给用户。
7、使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。
分布式数据库时网站数据库拆分的最后手段，只用在单表数据规模非常大的时候才使用。不到不得已时，网站更常用的数据库拆分手段是业务拆分，将不同业务的数据部署在不同的物理服务器上。
8、使用NoSQL和搜索引擎
搜素引擎也基本已经形成现在大型网站必须提供的功能了，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。
9、业务拆分
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将真个网站业务拆分成不同的产品线。
具体到技术上，也会根据产品线话费，将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间可以通过超链接建立管理，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
10、分布式服务
由于每一个应用系统都需要执行许多相同的业务操作，比如用户管理，session管理，那么可以将这些公用的业务提取出来，独立部署。
所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行灯一系列问题与挑战。为此，在实践中提出了许多解决方案，以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。
1、分层
分词是企业应用系统中最常见的一种架构牧师，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。
在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。应用层具体负责业务和视图的展示；服务层为应用层提供服务支持；数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。
2、分隔
如果说分层是将软件在横向方面进行切分，那么分隔就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分隔的粒度可能会很小。比如在应用层，将不同业务进行分隔，例如将购物、论坛、搜索、广告分隔成不同的应用，有对立的团队负责，部署在不同的服务器上。
3、分布式
对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
在网站应用中，常用的分布式方案有一下几种.
分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
4、集群
对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可；另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
5、缓存
缓存目的就是减轻服务器的计算，使数据直接返回给用户。在现在的软件设计中，缓存已经无处不在。具体实现有CDN、反向代理、本地缓存、分布式缓存等。
使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中；数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。
6、异步
使用异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步执行进行协作。
具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。
异步架构的典型就是生产者消费者方式，两者不存在直接调用。
7、冗余
网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。数据库除了定期备份还需要实现冷热备份。甚至可以在全球范围内部署灾备数据中心。
8、自动化
具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。
9、安全
网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证；登录、交易需要对网络通信进行加密；为了防止机器人程序滥用资源，需要使用验证码进行识别；对常见的XSS攻击、SQL注入需要编码转换；垃圾信息需要过滤等。
所谓架构，一种通俗的说法就是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。
而软件架构即“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各方面的设计”。一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。
1、性能
性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题。也正因为性能问题几乎无处不在，所以优化网站性能的手段也非常多：
浏览器端：可以通过浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输等手段，甚至可以使用CDN加速功能。
应用服务器端：可以使用服务器本地缓存和分布式缓存，也可以通过异步操作方式来加快响应，在高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。
数据库服务器端：可用使用索引、缓存、SQL性能优化等手段，还可以使用NoSQL数据库来优化数据模型、存储结构等。
衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过这些指标以确定系统设计是否达到目标。
2、可用性
可用性即能够不间断提供服务的时间。几乎所有网站都承诺7×24小时可用，但事实上任何网站都不可能达到完全的7×24，总会有一些故障时间，扣除这些故障时间，就是网站的可用时间。一些大型网站可以做到4个9以上的可用性，也就是99.99%。
网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份，任何一台服务器都不会影响应用的整体可以，通常的实现手段即把多台服务器通过负载均衡设备组成一个集群。
衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。
3、伸缩性
大型网站需要面对大量用户的高并发访问和存储海量数据，网站通过集群的方式将多台服务器组成一个整体共同提供服务。所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断整体上市用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可用多台服务器构建集群，是否容易向集群中添加新的服务器。加入新的服务器后是否可以提供和原来的服务器无差别的服务。集群中可容纳的总服务器数量是否有限制。
4、扩展性
不同于其他架构要素主要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目标。
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不同产品之间是否很少耦合等。
网站可扩展架构的主要手段是事件驱动架构和分布式服务。
事件驱动通常利用消息队列实现，通过这种方式将消息生产和处理逻辑分隔开。
服务器服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。新增加产品可用通过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。
5、安全性
互联网是开发的，任何人在任何地方都可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击和窃密手段，是否有可靠的应对策略。
网站性能是客观的指标，可以具体体现到响应时间、吞吐量、并发数、性能计数器等技术指标。
1、性能测试指标
1.1 响应时间
指应用执行一个操作需要的时间，指从发出请求到最后收到响应数据所需要的时间。如下列出了系统常用的操作响应时间表.
| 操作 |
响应时间 |
| 打开一个网站 |
几秒 |
| 数据库查询一条记录（有索引） |
十几毫秒 |
| 机械磁盘一次寻址定位 |
4毫秒 |
| 从机械磁盘顺序读取1M数据 |
2毫秒 |
| 从SSD磁盘顺序读取1M数据 |
0.3毫秒 |
| 从远程分布式换成Redis读取一个数据 |
0.5毫秒 |
| 从内存读取1M数据 |
十几微妙 |
| Java程序本地方法调用 |
几微妙 |
| 网络传输2Kb数据 |
1微妙 |
实践中计算响应时间通常是通过平均时间计算的平均值。
1.2并发数
指系统能够同时处理的请求的数目，这个数字也反映了系统的负载性能。对于网站而言，并发数指网站用户同时提交请求的用户数目。
网站系统用户数>网站在线用户数>网站并发用户数
1.3吞吐量
指单位时间内系统处理的请求数量，体现系统的整体处理能力。对于网站，可用“请求数/秒”或“页面数/秒”或“访问人数/天”或“处理业务数/小时”等来衡量。
TPS(每秒事物数)是吞吐量的一个常用量化指标。刺猬还有HPS（每秒HTTP请求数）、QPS(每秒查询数)。
1.4性能计数器
指操作系统的一些数据指标如System load(系统负载)，CPU使用率、内存使用率、磁盘等使用情况。
2、性能优化策略
根据网站分层架构，可分为Web前端性能优化、应用服务器性能优化、存储服务器性能优化。
2.1 Web前端优化
2.1.1 浏览器访问优化
- 减少HTTP请求数,主要可通过合并CSS，JavaScript、图片。
- 使用浏览器端缓存。在某些时候，静态资源文件编写需要及时应用到客户端浏览器，这种情况下，可通过改变文件名来实现。
- 启用页面压缩，文本文件的压缩效率可达80%以上。
- CSS放在页面最上面，JavaScript放在页面最下面
- 减少Cookie传输。可以考虑使用独立域名来发送Cookie等。
2.1.2 CDN加速
CDN的本质仍然是一个缓存，只是部署在离用户最近的服务器上，一般缓存的都是静态资源。
2.1.3 反向代理
除了能够保护网站安全的作用以及负载均衡的作用外，反向代理还能够提供缓存作用(动态资源)。
2.2 应用服务器性能优化
应用服务器就是处理网站业务的服务器，网站的业务代码都部署在这里，主要优化手段有缓存、集群、异步等。
2.2.1 分布式缓存
缓存主要用来存放哪些读写比很高、很少变化的数据。
分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其具体架构有两种，一种是以JBoss Cache伪代码的需要更新同步的分布式缓存， 一种是以Memcached为代表的不互相通信的分布式缓存。
Jboss Cache 的分布式缓存在集群中的所有服务器中保存相同的缓存数据，当某台服务器有缓存更新的时候，会通知集群中其他机器跟新缓存数据。优点是应用程序可以 从本地快速的获取缓存数据，但当集群规模较大的时候，缓存更新信息需要通过到集群所有机器，其代价可想而知。
大型网站需要的缓存数据一般都很大，可能会有TB的内存占用，这时候就的使用Memcached，是一中互不通信的架构，每台存储的缓存数据可以不一样。
2.2.2 异步操作
为了改善网站的扩展性，可以使用消息队列将调用异步化。
2.2.3 使用集群
在网站高并发访问的情况下，使用负载均衡技术为一个应用构建一个由多台服务器组成的集群，将并发访问请求分发到多台服务器上处理。
2.2.4 代码优化
代码优化主要涉及多线程、资源复用（对象池或单例）、数据结构和垃圾回收。
2.3 存储性能优化
可以考虑使用分布式存储、openfiler、磁盘阵列、HDFS（Hadoop）。
网站的可用性（Avaliability）描述网站可有效访问的特性。
1、网站可用性的度量与考核
网站不可用时间（故障时间）=故障修复时间点-故障发现（报告）时间点
网站年度不可用时间=（1-网站不可用时间/年度时间）× 100%
可用性指标时网站架构设计的重要指标，对外是服务承诺，对内是考核指标，具体到每个工程师，更多的是使用故障分。
所谓故障分是指对网站故障进行分类加权计算故障责任的方法。如下是个案例：
| 分类 |
描述 |
权重 |
| 事故级故障 |
严重故障，网站整体不可用 |
100 |
| A类故障 |
网站访问不顺畅或核心功能不可用 |
20 |
| B类故障 |
非核心功能不可用，或核心功能少数用户不能访问 |
5 |
| C类故障 |
其他故障 |
1 |
故障分的计算公式为：
故障分=故障时间（分钟）* 故障权重
2、网站的高可用架构
一个典型的网站设计通常遵循如下图所示的基本分层模型。
在负载的大型网站架构中，划分的粒度会更小，更详细，但通常还是能够把这些服务器划分到这三层中。
对于应用层的服务器通常为了应对高并发的访问请求，会通过负载均衡设备将一组服务器组成一个集群共同 对外提供服务，当负载均衡设备通过心跳检测到某台服务器不可用时，就将其从集群列表中提出，并将请求分发到集群中其他 可用的服务器上，是整个集群保存可用，从而实现应用高可用。
位于服务层的服务器情况和应用层类似，也是通过集群方式实现高可用，只是这些服务器被应用层通过分布式服务调用框架访问， 分布式服务调度框架会在应用层客户端中实现负载均衡功能。
位于数据层的服务器情况比较特殊，数据服务器上存储着数据，为了保证数据不丢失，数据访问服务不中断，需要在数据写入时进行数据同步复制，将数据写入多台服务器上，实现数据冗余备份。
网站升级的频率一般都非常高，每次网站发布都需要关闭服务，重新启动系统，相当于服务器宕机。因此网站的可用性架构还需要考虑到网站升级 发布引起的宕机。
3、高可用的应用
应用层主要处理网站应用的业务逻辑，也称为业务逻辑层，应用的一个显著特点就是应用的无状态行，因此实现负载均衡相对简单一点。
Web应用中将这些多次请求的上下文称为回话（Session），在单机情况下，session可部署在服务器上的Web容器上管理。在使用负载均衡 的集群环境中，由于负载均衡服务器可能会将请求分发到集群任何一台应用服务器上，所以保证每次请求依然能够获得正确的session比单机 时要复杂的多。在集群环境下，session管理主要有 以下手段。
1、Session复制
Session复制是早期企业应用系统使用较多的一种服务器集群Session管理机制。应用服务器开启Web容器的Session复制功能，在集群中几台服务器之间同步Session对象，是每台服务器上都保存所有用户的Session信息。
这种方案虽然简单，从本机读取Session信息也很快，但当集群规模比较大的时候会占用服务器和网站的大量资源，在大量用户访问的情况下，甚至会出现内存不够Session使用的情况。
2、Session绑定
Session绑定可以利用负载均衡的源地址Hash算法实现，负载均衡服务器总是将来源于同一IP的请求分发到同一台服务器上。这样在整个回话期间，用户所有的请求都在同一天服务器上处理，即Session绑定到某台特定的服务器上，保证Session总能在这台服务器上获取，这种方法有成为回话粘滞。
3、利用Cookie记录Session
一种管理Session的方式是将Session记录在客户端，每次请求服务器的时候，将Session放在请求中发送给服务器，服务器处理完请求后再将修改后的Session响应给客户端。
4、Session服务器
Session服务器，即把session的管理独立部署在某一台机器上，Web服务器不保存用户Session信息，每次都去Session服务器取数据。
这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器。对于有状态的Session服务器，一种比较简单的方式是利用分布式缓存、数据库等。
4、高可用的服务
5、高可用的数据
6、高可用的网站质量保证
7、网站运行监控
1、用户行为日志收集（服务器端和浏览器端）