第1篇
1. 大型网站架构演化
大型网站系统的特点
- 高并发，大流量：
- 高可用：7×24小时不间断服务。
- 海量数据：使用大量服务器存储、管理海量数据。
- 用户分布广泛，网络情况复杂：
- 安全环境恶劣：
- 需求快速变更，发布频繁：
- 渐进式发展：
大型网站架构演化发展历程
- 初始阶段：应用程序、数据库、文件等所有资源部署在一台服务器上。
- 应用服务和数据服务分离：网站使用多台服务器，应用服务器、数据库服务器和文件服务器。
- 引入缓存：二八定律。可以使用两种：本地缓存（缓存在应用服务器上）和远程缓存（缓存在分布式缓存服务器上）。
- 应用服务器集群化：前端使用负载均衡服务器分发用户请求到应用服务器集群中任意一台。
- DB读写分离：此时会在应用服务器端引入专门的数据访问模块，使数据读写分离对应用透明。
- 使用反向代理和CDN：两者的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理部署在网站的中心机房。目的：加快用户访问速度、减轻后端服务器压力。
- 使用分布式文件系统和分布式数据库系统：
- 使用NOSQL和搜索引擎：
- 业务拆分：将整个网站业务拆分成多个产品线，分归不同的业务团队负责。技术上会将整个网站应用拆分成多个独立部署的子应用。
- 分布式服务：当单个网站应用拆分成多个独立部署的子应用后，可能每个子应用都会有一些相同的业务操作，将这些共同的业务操作提取出来独立部署，以服务的形式供各个应用共享。
2. 大型网站架构模式
模式的个人理解：解决问题的套路，是可重复性的。
网站架构模式（大型网站的架构的一般思路和解决方案）
- 分层：对系统进行横向切分，形成上下层调用和依赖关系（如应用层→ 服务层 → 数据层）。层内可继续分层。分层架构是逻辑上的，物理上可部署在同一台物理机上，随着网站发展，也可以部署在不同机器上。
- 分割：对系统进行纵向划分，将不同的功能和服务分开，包装成高内聚低耦合的模块，便于维护和分布式部署。
- 分布式：分层和分割的目的是便于分布式部署（不同模块部署在不同的机器上），通过远程调用协作。分布式在解决网站高并发的同时也会带来其他问题（如性能、可用性、一致性等问题）。在网站中常用的分布式方案有：集群：多台机器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。目的是为了提高系统的可用性。
- 分布式应用和服务：将分层和分割后的应用和服务分布式部署。
- 分布式静态资源：将静态资源分布式部署。
- 分布式数据和存储：
- 分布式计算：
- 分布式配置、分布式锁、分布式文件系统等。
- 缓存：CND、反向代理；本地缓存、远程缓存。使用缓存的两个前提：
- 数据访问热点不均匀。
- 数据在某个时间段内有效，不会很快过期。
- 异步：解耦，生产者消费者模式。单一服务器中通过共享内存队列的方式实现异步，分布式系统中公共分布式消息队列实现异步。异步消息队列的特性：冗余：服务器冗余备份，数据冗余备份。
- 提高系统可用性：消费者发生故障，生产者可继续处理业务请求。
- 加快网站响应速度
- 消除并发访问高峰：请求排队，减轻负载。
- 自动化：自动化代码管理、自动化测试、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复、自动化降级、自动化资源分配等。
- 安全：加密、验证码、过滤、风险控制。
3. 大型网站核心架构要素
要素：性能、可用性、伸缩性、扩展性、安全性。
性能
- 性能指标：响应时间、TPS等。
- 性能优化手段（从浏览器到数据库的所有环节都可以优化）：
- 浏览器端：浏览器缓存、页面压缩、合理布局页面、减少cookie传输。
- 使用CDN、反向代理
- 应用服务器端使用本地缓存或者分布式缓存
- 通过异步操作快递响应用户请求
- 数据库层面的优化：索引，SQL优化等
- 代码层面的优化
可用性
目标是当服务器宕机的时候，应用或者服务仍然可用。主要手段是冗余。对应用服务器而言，不能保存请求的会话信息，否则即使切换到另一台应用服务器上，也无法完成业务处理。
伸缩性
通过不断向集群中加入服务器的来缓解并发访问压力和数据存储需求。
对应用服务器集群而言：只要服务器上不保存数据，所有服务器都是对等的，通过使用合适的负载均衡设备可以向集群中不断加入服务器。
对于缓存服务器集群：需要在缓存路由算法上下功夫，以保证不会因为新加入服务器导致既有的缓存路由无效，尤其是对于严重依赖缓存的网站应用，可能导致网站崩溃。
对于关系数据库服务器集群：在数据库之外通过路由分区等手段来实现。
扩展性
和伸缩性不同，这里是指新增业务产品时，是否可以实现对现有产品透明无影响。
主要手段是事件驱动架构和分布式服务。
事件驱动架构利用消息队列来实现。
分布式服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。
安全性
对各种可能的攻击提供可靠的应对策略。
第2篇
4. 网站的高性能架构
性能测试指标
响应时间：发请求 到 收到影响 所需的时间。《Latency Numbers Every Programmer Should Know》
并发数：系统能够同时处理请求的数目。对网站而言就是网站并发用户数，网站系统用户数>网站在线用户数>网站并发用户数。
吞吐量：单位时间内系统处理的请求数量。常用量化指标有TPS（每秒事务数）、QPS（每秒查询数）、HPS（每秒HTTP请求数）。三者关系类比：系统吞吐量（每天通过收费站的车辆数目）、系统并发数（高速路上正在行驶的车辆数目）和响应时间（车速）。
性能计数器：反映服务器或者OS的一些数据指标。如系统负载System Load（当前正在被CPU执行和等待被CPU执行的进程数目总和）、内存使用、网络与磁盘IO等指标。
性能测试方法
性能测试是一个总称，具体可细分为性能测试、负载测试、压力测试、稳定性测试。
性能分析
如何排查一个网站的性能瓶颈？检查请求处理的各个环节的日志，分析哪个环节响应时间不合理；检查监控数，分析影响性能的主要因素是内存，磁盘，网络还是CPU，是代码问题还是架构设计不合理，或是系统资源确实不足。
性能优化
分为三大类：web前端性能优化、应用服务器性能优化、存储服务器性能优化。
1. web前端性能优化
- 浏览器访问优化：减少http请求（如多个js放在同一文件）；使用浏览器缓存；启用压缩；CSS放在最前面，JS放在页面最后面；减少cookie传输。
- CDN加速
- 反向代理
2. 应用服务器性能优化
- 分布式缓存：注意合理使用缓存。分布式缓存有两种架构方式：一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Memcached为代表的不互相通信的分布式缓存。
- 异步操作： 使用消息队列将调用异步化。
- 使用集群：通过服务器集群+负载均衡服务器可以分发高并发请求，提高响应。
- 代码优化：
- 多线程：解决线程安全的手段：无状态对象，使用局部对象，锁。
- 资源复用：资源复用主要有两种模式：单例（Singleton）和对象池（Object Pool）。连接池和线程池本质上都是对象池。
- 数据结构：
- 垃圾回收：
3. 存储服务器性能优化
机械硬盘 VS. 固态硬盘
B+树 VS. LSM树
RAID VS. HDFS
5. 网站的高可用架构
网站可用性度量
| 指标 | 年度不可用时间 |
| 2个9 | <88小时 |
| 3个9 | <9小时 |
| 4个9 | <53分钟 |
| 5个9 | <5分钟 |
网站可用性考核
根据故障等级和故障持续时间计算故障分，进行绩效考核。
故障分=故障时间（分钟）×故障权重
高可用网站架构
典型的分层模型是三层，即应用层，服务层和数据层；应用层负责业务逻辑处理，服务层提供可复用的服务，数据层负责数据的存储和访问。
大型网站的分层架构以及物理服务器的分布式部署使得位于不同层次的服务器具有不同的可用性特点，宕机时产生的影响也不同，对应的解决方案也不同。
实现高可用的手段就是冗余，集群化部署，所以会涉及到负载均衡。
应用层的服务器：负载均衡会和应用服务器保持心跳，删除不可用的。
服务层的服务器：一般会使用分布式服务调用框架，分布式服务调用框架的客户端会实现软件负载均衡。
高可用的应用
应用层的显著特点是应用的无状态性。即应用服务器不保存业务的上下文信息，使得多个服务实例之间完全对等，请求提交到任意服务器，处理结果完全一样。
- 通过负载均衡实现无状态服务的失效转移。
- 应用服务器集群的session管理：应用服务器的高可用架构设计主要基于服务无状态这一特性。遇到有状态的情况怎么办呢？将这些状态信息称为Session，集群环境下，Session的管理手段有：
- Session复制：集群中个服务器之间同步session对象，每台机器都保存所有的session信息。
- Session绑定：利用负载均衡的源地址Hash算法，将来源于同一IP的请求分发到同一台服务器上。即Session绑定在某台特定的服务器上，又称作会话黏滞。
- 利用cookie记录Session：大小受限、不安全
- Session服务器：利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。本质是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session服务器，然后针对这两种服务器的不同特性分别设计其架构。
高可用的服务
可复用的服务和应用一样，也是无状态的服务，可以使用类似负载均衡的失效转移策略。实践中的一些好的策略：
- 分级管理：核心应用和服务使用好的硬件
- 超时设置：
- 异步调用：
- 服务降级：避免高并发使得性能下降乃至宕机。降级有两种手段：拒绝服务及关闭服务。
- 幂等性设计：
高可用的数据
保证数据存储高可用的手段主要是数据备份和失效转移机制。
CAP理论《参考》
为了保证数据的高可用，网站通常会牺牲另一个也很重要的指标：数据一致性。
高可用数据的几层含义：数据持久性、数据可访问性、数据一致性。
数据备份
- 数据冷备：定期将数据复制到某种存储介质（磁带、光盘...）上并物理存档保存。优点是简单和廉价，缺点是不能保证数据最终一致，也不能保证数据可用性。
- 数据热备：分为两种：异步热备方式和同步热备方式。
- 异步热备：多份数据副本的写入操作异步完成，应用收到写入成功的响应时，只写成功了一份，存储系统会异步地写其他副本。异步方式下，存储服务器分为Master和Slave。当写入Master成功后，立即返回写入成功，然后由Master异步写入到Slave。
- 同步热备：多份数据副本的写入操作同步完成，当收到写入成功的消息时，多份数据都已经写操作成功。当应用收到写入失败的消息时，可能部分或者全部副本都已写入成功了。存储服务器无主从之分，完全对等。
失效转移
失效转移操作由三部分组成：失效确认、访问转移、数据恢复。
判断一台服务器是否宕机的手段有两种：心跳检测和应用程序访问失败报告。
6. 网站的伸缩性架构
网站架构的伸缩性设计
可以分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。前者是不同的服务器部署不同的服务，提供不同的功能；后者是集群内的多台服务器部署相同的服务，提供相同的功能。
不同功能进行物理分离实现伸缩
具体可以分为纵向分离（分层）和横向分离（业务分割）。
单一功能通过集群规模实现伸缩
即使拆分到最小粒度进行独立部署，单一服务器也有可能无法满足业务发展。此时需要使用服务器集群。将相同的服务部署在多台服务器上构成一个整体对外提供服务。
应用服务器集群的伸缩性设计
核心关键点：应用服务器设计成无状态的；加上负载均衡服务器。
实现负载均衡的基础技术有：
- HTTP重定向负载均衡：优点是简单，缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差。
- DNS域名解析负载均衡：
- 反向代理负载均衡：
- IP负载均衡：
- 数据链路层负载均衡：三角传输模式、直接路由（DR），产品有LVS等。
负载均衡算法有：
- 轮询（Round Robin，RR）：所有请求被依次分发到每台应用服务器上。
- 加权轮询（Weighted Round Robin，WRR）：
- 随机（Random）：
- 最少连接（Least Connections）：记录每个应用服务器正在处理的连接数（请求数），将请求分发到最少的那个。
- 源地址散列（Source Hashing）：计算请求来源IP地址的hash值来得到应用服务器，同一IP分配到同一应用服务器。
分布式缓存集群的伸缩性设计
如何避免如下问题：加入新的服务器 → 路由的结果改变（比如Hash后求模）→ 缓存失效→ 大量请求走DB → 数据库宕机。
解决方案：改进路由算法，比如一致性Hash算法。
数据存储服务器集群的伸缩性设计
关注点：如何保证数据的持久性和可用性。必须保证数据的可靠存储，任何情况下都必须保证数据的可用性和正确性。
具体分为两类来分析，关系型的和NOSQL。
关系数据库集群的伸缩性设计
多台服务器部署MySQL实例，有主从之分，写在主服务器，读在从服务器。
根据业务分库，不同业务的数据库表部署在不同的数据库集群上。
单表过大就分表。
关键词：主从复制、分库、分表。
NoSQL数据库集群的伸缩性设计
作为读关系数据库的补充，NoSQL放弃了关系数据库的两大基础：SQL和事务。而强化了大型网站更关注的一些特性：伸缩性和高可用性。
7. 网站的可扩展架构
概念澄清
- 扩展性（Extensibility）：对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。表现在系统基础设施稳定不需要经常变更，应用之间较少依赖和耦合，对需求变更可以敏捷响应。
- 伸缩性（Scalability）：系统能够通过增加（减少）自身资源规模的方式增强（减少）自己计算处理事务的能力。如果这种增减是成比例的，就被称作线性伸缩性。在网络架构中，通常利用集群的方式增加服务器数量、提高系统的整体事务吞吐能力。
设计网站可拓展架构的核心思想是模块化，并在此基础之上，降低模块间的耦合性，提高模块的复用性。
主要手段是分层和分割为若干个低耦合的独立的模块，这些组件模块以消息传递及依赖调用的方式聚合成一个完整的系统。
模块分布式部署后具体聚合方式主要有分布式消息队列和分布式服务。
利用分布式消息队列降低系统耦合性
事件驱动架构
通过在低耦合的模块之间传输事件消息完成模块间合作。具体实现手段很多，典型的是分布式消息队列。
利用分布式服务打造可复用的业务平台
大型网站分布式服务的需求和特点：服务注册和发现、负载均衡、失效转移、高效的远程通信、整合异构系统、对应用最少侵入、版本管理、实时监控。
利用开放平台建设网站生态圈
开放平台的一些功能点：API接口、协议转换、安全、审计、路由、流程。
8. 网站的安全架构
常见的网站应用攻击
XSS攻击
跨站点脚本攻击。常见的XSS攻击类型有两种，一种是反射型的，一种是持久型的。
防御手段：消毒（将“<”转义为“<”等）、HttpOnly（浏览器禁止页面js访问带有HttpOnly属性的Cookie）
注入攻击
主要有两种形式，SQL注入攻击和OS注入攻击。
防御手段：避免表结构泄露、消毒、参数绑定等。
CSRF攻击
跨站点请求伪造。利用跨站请求，在用户不知情的情况下，以用户的身份伪造请求。核心是利用了浏览器Cookie或服务器Session策略，盗取用户身份。
防御手段：主要是识别请求者身份。主要有下面几种方法。
- 表单Token：CSRF是一个伪造用户请求的操作，所以需要构造用户请求的所有参数才行。此方法是在请求参数中增加随机数的办法来阻止攻击者获得所有的请求参数。
- 验证码：用户体验不太好，仅限必要时使用。
- Referer check：Http请求的Referer域中记录着请求来源，可检测请求来源验证是否合法。如图片防盗链。
其他攻击和漏洞
Error Code、HTML注释、文件上传、路径遍历等。
信息加密
信息加密技术可分为三类：单项散列加密、对称加密和非对称加密。
单项散列加密
过程：不同长度的信息 → 散列计算 → 固定长度输出。
该过程是单向的，从左到右可以，反之不行，即不能根据固定长度的输出得到原始信息。
应用：密码加密保存。
为了增加安全性，还会给散列算法加点盐（salt），salt相当于加密的密钥，增加破解的难度。
常用的单向散列算法：MD5、SHA等。
单向散列算法的特性：输入的任何微小变化都会导致输出的完全不同。
对称加密
对称加密：加密和解密使用同一个密钥。
应用：对称加密通常用在信息需要安全交换或存储的场合，如Cookie加密、通信加密等。
优缺点：算法简单、效率高、开销小、适合对大量数据加密；如何安全交换密钥是个难题。
常用的对称加密算法：DES算法、RC算法。
非对称加密
非对称加密：加密和解密使用不同的密钥。公钥加密后的信息必须用私钥才能解开，私钥加密后的信息必须用公钥才能解开。
应用：信息安全传输、数字签名
常用的非对称加密算法：RSA算法。
密钥的安全管理
不管是单向散列加密用到的salt、对称加密的密钥、还是非对称加密的私钥，一旦这些密钥泄露，则所有基于这些密钥加密的信息就失去了私密性。
信息的安全性是靠密钥保证的。实际开发中，有的将密钥写在源代码中，有的放在配置文件中，可以将密钥和算法放在独立的服务器上。