《大型网站技术架构：核心原理与案例分析》读书笔记 - 第2篇 架构

第2篇 架构

4 瞬时响应：网站的高性能架构 34

4.1 网站性能测试 35

性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。

4.1.1 不一样视角下的网站性能 35

1. 用户：直观感觉到的快慢
2. 开发：应用程序自己
3. 运维：基础设施性能和资源利用率

4.1.2 性能测试指标 36

1.响应时间：发出请求-->接收响应

2.并发数：同时处理请求的数目，反映了网站的负载特性。多线程模拟并发，线程间增长随机等待时间（思考时间）

3.吞吐量：单位时间内系统处理的请求数，体现总体处理能力。TPS（每秒事物数）、HPS（每秒HTTP请求数）、QPS（每秒查询数）等

4.性能计数器：System Load(系统负载：正在被CPU执行和等待执行的进程数目总和)、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。

   对这些指标设置报警阈值。

4.1.3 性能测试方法 39

1.性能测试：以系统设计初期的性能指标为预期目标，不断施压验证

2.负载测试：不断增长并发请求，直到达到临界值

3.压力测试：超过安全负载状况下，继续施压，直至系统崩溃或不能处理任何请求，以此得到系统最大压力承受能力

4.稳定性测试：长时间、不均匀的对系统施压

4.1.4 性能测试报告 41

4.1.5 性能优化策略 41

寻找瓶颈，分而治之，逐步优化

1.性能分析：内存、CPU、磁盘、网络、代码、架构设计、资源不足等。

2.性能优化：WEB、服务器、存储，3大类

4.2 Web前端性能优化 42

4.2.1 浏览器访问优化 42

1.减小HTTP请求：HTTP请求是无状态的应用层协议，每次请求都须要创建通讯链路，服务区端都须要独立启动新线程。

  手段：合并css、合并js、合并图片

2.使用浏览器缓存：静态资源文件（CSS、js、Logo、图标等）缓存。

  手段：设置HTTP投中的Cache-Control和Expires属性，数天甚至几个月。

  注意：文件变化需及时通知浏览器，

3.启用压缩：使用GZip在服务器端对文件压缩，浏览器解压。

  注意：压缩会有必定的压力，在通讯带宽良好，服务器资源不足状况下要权衡考虑。

4.CSS放在页面最上边，JS放在页面最下边

CSS放在页面最上边：浏览器会在下载彻底部CSS后对页面渲染

JS放在页面最下边：浏览器加载JS后当即执行，有可能阻塞整个页面，形成页面显示缓慢（除非页面解析时用到JS）

5.减小Cookie传递Cookie包含在每次请求和响应中，太大的Cookie会严重影响数据传输。

4.2.2 CDN加速 43

CDN（Content Distribute Network，内容分发网络），本质是缓存，并且是数据缓存在距用户最近的地方，部署在网络运营商的机房。

4.2.3 反向代理 44

位于网站机房一侧，

1.保护网络安全：增长一层

2.加速Web请求：第一次用户访问加载静态资源缓存，其它用户访问直接从反向代理服务器返回

3.负载均衡：构建应用集群提升系统总处理能力

 

 

4.3 应用服务器性能优化 45

4.3.1 分布式缓存 45

网站性能优化第必定律：优先考虑使用缓存优化性能

1.缓存的基本原理

定义：缓存是指将数据存储在相对较高访问速度的存储介质中，以供系统处理。

做用：减小访问时间，减小计算时间

原理：内存Hash表

2.合理使用缓存

a.频繁修改的数据：写入一次缓存，至少读两次以上，缓存才有意义

b.没有热点的访问：大部分数据访问集中在小部分数据上

c.数据不一致与脏读：应用要容忍必定时间的数据不一致

d.缓存可用性：分布式缓存服务器集群

e.缓存预热：系统启动时把热点数据加载好

f.缓存穿透:不恰当的业务或恶意攻击持续高并发的请求某个不存在的缓存，全部请求落到数据库上，形成很大压力甚至雪崩。

  对策：不存在的数据也缓存起来，value值为null。

3.分布式缓存架构

缓存部署在多个服务器组成的急群中，以集群方式提供服务。JBoss Cache：同步更新的分布式缓存

4.Memcached

简单的通讯协议：TCP（UDP也支持）协议通讯

丰富的客户端程序：几乎支持全部主流的网站编程语言

高性能的网络通讯：服务端通讯模块基于Libevent，是一个支持事件触发的网络通讯库。稳定的长链接

高效的内存管理：固定空间分配

 

互不通讯的服务器集群架构：几乎无限制的线性伸缩

4.3.2 异步操做 52

 使用消息队列将消息异步化，可改善网站的扩展性，还可改善网站的性能，起到削峰做用。

4.3.3 使用集群 53

 

4.3.4 代码优化 54

1.多线程：最大限度的使用CPU。

解决线程安全的主要手段：

将对象设计为无状态对象：对象自己不存储状态信息（对象无成员变量）

使用局部对象：方法内部建立对象，只会被进入该方法的线程建立

并发访问资源时使用锁：可能影响性能

2.资源复用：减小开销大的系统资源的建立与销毁，如数据库链接、网络通讯链接、线程、复杂对象等。

编程角度有两种模式：单利（Singleton）和对象池（Object Pool）

3.数据结构：灵活组合各类数据结构改善数据读写和计算

4.垃圾回收

4.4 存储性能优化 58

4.4.1 机械硬盘vs. 固态硬盘 58

机械硬盘：最经常使用，快速顺序读写，慢速随机读写。经过马达驱动磁头臂，带动磁头到指定的磁盘位置访问数据

 

固态硬盘：又称SSD或Flash硬盘；数据存储再可持久记忆的硅晶体上。能够快速随机访问。

 

4.4.2 B+树vs. LSM树 59

B+树：专门针对磁盘存储而优化的N叉排序树

LSM树：N阶合并树。

4.4.3 RAID vs. HDFS 61

RAID：廉价磁盘冗余阵列，改善磁盘访问延迟，增长磁盘可用性和容错能力。

HDFS：Hadoop分布式文件系统，对数据存储空间的管理以块（Block）为单位，默认64M，

4.5 小结 64

性能优化的最终目的是改善用户体验，使他们感受网站很快。

5 万无一失：网站的高可用架构 66

5.1 网站可用性的度量与考核 67

5.1.1 网站可用性度量 67

业界一般用多少个9来衡量网站的可用性，如QQ是99.99%

2个9是基本可用：网站年度不可用时间小于88小时

3个9是较高可用：网站年度不可用时间小于9小时

4个9是高可用性：网站年度不可用时间小于53分钟

5个9是极高可用：网站年度不可用时间小于5分钟

5.1.2 网站可用性考核 67

可用性指标是网站设计的重要指标，对外是服务承诺，对内是考核指标

故障分 = 故障时间（分钟）* 故障权重

5.2 高可用的网站架构 69

目的：保证服务器硬件故障时服务器依然可用，数据依然保存并可以被访问。

手段：数据和服务的冗余备份及失效转移。

注意：升级发布引发的宕机

5.3 高可用的应用 71

业务逻辑层，无状态的

5.3.1 经过负载均衡进行无状态服务的失效转移 72

心跳机制检测机器是否可用。

5.3.2 应用服务器集群的Session管理 73

Session（会话）：屡次请求修改使用的上下文对象。如购物车

集群环境下，管理Session的手段

1.Session复制：只适用于小规模集群，占用大量资源

 

2.Session绑定：会话黏滞，Session绑定在特定机器上，一旦宕机Session不存在了。

3.利用Cookie记录Session：受Cookie大小限制，影响性能，用户能够关闭Cookie

 

 

4.Session服务器：利用分布式缓存，数据库等。

 

5.4 高可用的服务 76

也是无状态的，也可使用负载均衡失效转移策略实现高可用的服务。

此外，还有如下几种：

1. 分级管理：核心应用和服务使用更好的硬件，部署隔离，低优先级部署在虚拟机上，高优先级不一样物理机上。
2. 超时设置：调用超时重试或者请求转移其余机器上
3. 异步调用：消息队列，不须要确认服务调用成功才能进行下一步操做的调用。
4. 服务降级：拒绝低优先级服务及关闭部分服务不重要服务，确保核心应用和功能正常运行
5. 幂等性设计：服务层保证服务从新调用和第一次调用产生的结果相同。

5.5 高可用的数据 78

5.5.1 CAP原理 79

数据高可用有如下几个层面的含义：数据持久性、数据可访问性、数据一致性。

CAP原理认为，一个提供数据服务的存储系统没法同时知足数据一致性（Consistency）、数据可用性（Availability）、分区耐受性（Patition Tolerance，系统具备跨网络分区的特性）这三个条件。

强化分布式系统的可用性（A）和伸缩性（P）,某种程度上放弃一致性（C）

一致性又可分为：

数据强一致：各个副本的数据在物理存储中老是一致的。（难以知足）

数据用户一致：数据在物理存储中可能不一致，用户访问时经过纠错校验保证一致。（能够达到）

数据最终一致：数据在物理存储中可能不一致，用户访问时可能不一致，通过一段时间修复，达到一致。

5.5.2 数据备份 82

数据冷备：按期将数据复制到某种存储介质上，优势：简单廉价、技术成本低，缺点：不能保证数据最终一致。

数据热备：异步热备方式&同步热备方式，Master-Slave同步机制，实现读写分离

5.5.3 失效转移 84

由三部分组成：

1.失效确认：确认服务器是否宕机由两种手段：心跳检测和应用程序访问失效报告（需心跳检测确认）

2.访问转移：数据读写访问到其余服务其上。

3.数据恢复：数据存储的副本恢复经过从健康的服务区复制数据恢复到设定值，防止再次宕机没法转移。

5.6 高可用网站的软件质量保证 85

网站为了保证线上系统的可用性而采起的一些与传统软件开发不一样的质量保证手段。

5.6.1 网站发布 85

每次关闭的服务器都是集群中的一小部分，并在发布当即能够访问，整个发布过程不影响用户使用。

5.6.2 自动化测试 86

Thoughts Works开发的Selenium[səˈli:niəm]，运行在浏览器中，模拟用户操做，能够完成功能测试和兼容性测试。

5.6.3 预发布验证 87

跟正式服务器惟一的区别是不在配置负载均衡服务区上。注意：全部操做都是真实的。

5.6.4 代码控制 88

SVN&GIT

5.6.5 自动化发布 90

Jenkins

5.6.6 灰度发布 91

 

5.7 网站运行监控 91

不容许没有监控的系统上线。

5.7.1 监控数据采集 92

1.用户行为日志收集：用户全部操做及操做环境、页面访问路径、页面访问时间等，对统计网站PV/UV，分析用户行为、个性化营销、推荐等很是重要。

手段：服务器端日志收集（log4j）、浏览器日志收集（页面嵌入JS脚本）

注意：服务器端收集IP可能用户使用代理，无浏览器端准确，可是相对简单。

考虑使用Storm进行日志统计分析

2.服务器性能监控：系统负载、内存占用、磁盘IO、网络IO等，作到防患于未然，合理安排集群规模，改善性能

工具：Ganglia

3.运行数据报告：具体业务场景相关的指标，如待处理任务总数、每分钟发邮件数等。

5.7.2 监控管理 93

系统报警：超过阈值短信邮件报警

失效转移：

自动优雅降级：为了应付忽然爆发的访问高峰，主动关闭部分功能

5.8 小结 94

先求生存，再求发展。

6 永无止境：网站的伸缩性架构 95

不需改变网站的软硬件设计，仅经过改变部署的服务器的数量就能够扩大或缩小网站的服务处理能力。

6.1 网站架构的伸缩性设计 97

6.1.1 不一样功能进行物理分离实现伸缩 97

6.1.2 单一功能经过集群规模实现伸缩 98

相同服务部署在多台服务器上构成集群。

集群伸缩性分为：应用服务器集群的伸缩性、数据服务集群的伸缩性。

数据服务集群的伸缩性分为：分布式缓存集群、数据存储服务器集群。

6.2 应用服务器集群的伸缩性设计 99

6.2.1 HTTP重定向负载均衡 100

请求两次完成一次访问，性能较差，不建议使用。

6.2.2 DNS域名解析负载均衡 101

DNS域名解析获得内部提供负载均衡的服务器。与下图有出入。

6.2.3 反向代理负载均衡 102

优势：经过缓存提升性能、负载均衡；缺点：代理服务器是全部请求响应中转站，可能有性能瓶颈。

6.2.4 IP负载均衡 103

 性能优于反向代理，可是对于提供视频、下载服务的网站，吞吐量受限于网络带宽，难以知足。

6.2.5 数据链路层负载均衡 104

 修改mac地址，不需修改IP，称三角传输模式。避免网卡带宽成为服务器瓶颈，也称直接路由方式（DR），使用最广。

LVS（Linux Virtual Server）：Linux平台最好的开源产品。

6.2.6 负载均衡算法 105

负载均衡服务器实现能够分为两部分：

1.根据负载均衡算法和Web服务器列表计算获得集群中一台Web服务器的地址。

2.将请求数据发送到该地址对应的Web服务器上。

负载均衡算法一般有如下一种：

轮询（Round Robin，RR）：全部请求依次发送到每台服务器上，适用于每台服务器硬件相同的场景。

加权轮询（Round Robin，RR）：高性能的服务器分配更多请求。

随机（Random）：简单，好的随机数自己就很均衡，也能够加权。

最少链接（Least Connections）：计算每一个服务器处理的链接数，请求发送到链接数最少的机器上。

源地址散列（Source Hashing）：根据IP进行Hash计算，来自同一IP的请求老是落在同一服务器上。

6.3 分布式缓存集群的伸缩性设计 106

新上线的缓存服务器对整个分布式集群的影响最小。

6.3.1 Memcached分布式缓存集群的访问模型 107

6.3.2 Memcached分布式缓存集群的伸缩性挑战 107

 余数Hash：扩容致使命中率下降，好比3台扩容至4台，约有3/4的数据不能命中，只能访问量小的时候预热，晚上加班。比较流行的办法是一致性Hash算法。

6.3.3 分布式缓存的一致性Hash算法 109

 经过一个叫作一致性Hash环的数据结构实现Key到缓存服务器的Hash映射。顺时针查找离整个Key的Hash值最近的缓存服务器节点，新增节点只影响一小段

问题：新增NODE3节点后支队NODE1有影响，NODE0、NODE2负载压力是NODE一、NODE3的2倍。

解决：虚拟节点加入环中，分摊负载，经验是一个物理服务器虚拟150个节点。

6.4 数据存储服务器集群的伸缩性设计 112

6.4.1 关系数据库集群的伸缩性设计 113

分库、读写分离外，还可使用地方放组件，如Sharding-JDBC

6.4.2 NoSQL数据库的伸缩性设计 117

 NoSQL：非关系的，分布式的设计模式，应用最普遍的是Apache 的HBase。

6.5 小结 119

 必备能力。

7 随需应变：网站的可扩展架构 121

对现有系统影响最小的状况下，系统功能可持续扩展或提高的能力。开闭原则。

7.1 构建可扩展的网站架构 122

架构师最大的价值：将一个大系统切分红N个低耦合的子模块的能力，包括横向的业务模块（分层），也包括纵向的基础技术模块（分割）。

网站可扩展架构设计的核心思想：模块化，并下降模块间的耦合性，提升模块的复用性。以消息队列及依赖调用的方式聚合成一个完整的系统。

模块分布式部署主要分为：分布式消息队列（消息）、分布式服务（接口）。

7.2 利用分布式消息队列下降系统耦合性 123

7.2.1 事件驱动架构 123

事件驱动架构（Event Driven Architecture，EDA）：经过在低耦合的模块之间传递消息，以保证模块的松散耦合，并借助事件消息的通讯完成模块间合做，生产者消费者模式。

好处：发送者不需等待接收者返回，更好的延迟；网站访问高峰，接收者能够能够根据自身负载处理能力控制消息处理速度，减轻数据库等后端存储的负载压力。

7.2.2 分布式消息队列 124

 

AvtiveMQ、kafaka

7.3 利用分布式服务打造可复用的业务平台 126

7.3.1 Web Service与企业级分布式服务 128

缺点：

1.臃肿的注册和发现机制

2.低效的XML序列化手段

3.开销相对较高的HTTP通讯

4.复杂的部署和维护手段。

7.3.2 大型网站分布式服务的需求与特色 129

负载均衡、失效转移、高效的远程通讯、整合异构系统、对应用最少侵入、版本管理、实时监控。

7.3.3 分布式服务框架设计 130

Dubbo：是一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分布式框架。

Spring Cloud：基于 Spring Boot，为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。

Spring Boot：是 Spring 的一套快速配置脚手架，使用默认大于配置的理念，用于快速开发单个微服务。

Dubbo 和 Spring Cloud 对比

7.4 可扩展的数据结构 131

HBase，列族（ColumnFamily），解决关系型数据库数据结构难以面对需求变动带来的挑战。

7.5 利用开放平台建设网站生态圈 132

 

7.6 小结 134

8 固若金汤：网站的安全架构 135

8.1 道高一尺魔高一丈的网站应用攻击与防护 136

全球约70%的Web应用攻击都来自XSS攻击和SQL注入攻击。

8.1.1 XSS攻击 136

XSS攻击（Cross Site Script）：跨站点脚本攻击，指黑客经过篡改网页，注入恶意HTML脚本，在用户浏览完网页时，控制用户浏览器进行恶意操做的一种攻击方式。

XSS攻击类型有两种：反射型、持久型。

防攻击手段：

消毒：对危险html转义，如">"转义"&gt"，"<"转义"&lt"等

HttpOnly：防止XSS攻击窃取用户Cookie，对Cookie添加HttpOnly属性。

8.1.2 注入攻击 138

 主要有两种形式：SQL注入攻击、OS注入攻击。

攻击者获取表结果手段：

开源：网站才用开源软件搭建。

错误回显：错误回显到浏览器上。（重点）

盲注：根据页面变化判断SQL执行状况。

防止SQL注入方式：

消毒：简单粗暴，经过正则过滤请求中可能的SQL注入。

参数绑定：最好方式，经过预编译，攻击者的SQL当作参数而不是SQL。

8.1.3 CSRF攻击 139

 CSRF攻击（Cross Site Request Forgery）：跨站点请求伪造，

CSRF攻击防护手段主要是识别用户身份

表单Tonken：页面参数中增长一个随机数做为token，每次响应页面的token都不相同。

验证码：体验糟糕，如支付页面可使用。

Referer check：图片防盗链。

String referer = request.getHeader("Referer");
if(referer == null || !referer.startsWith("http://localhost:8080/fancy")) {
    Response.sendRedirect("/servletPro/Error");//转到错误页面
    return;
}

8.1.4 其余攻击和漏洞 140

Error Code：500（服务器内部错误）配置错误页面。

HTML注释：JSP、HTML注释会显示在客户端浏览器。

文件上传：只容许上传可靠类型的文件。

路径遍历：JS、CSS等资源文件部署在独立服务器，使用独立域名。

8.1.5 Web应用防火墙 141

Model Security：开源Web应用防火墙，探测攻击并保护Web应用程序。

 

8.1.6 网站安全漏洞扫描 142

 模拟攻击行为，发现网站安全漏洞

8.2 信息加密技术及密钥安全管理 142

信息加密技术分类：单向散列加密、对称加密、非对称加密。

8.2.1 单向散列加密 143

单向散列加密：对不一样长度的信心进行散列加密，获得固定长度得输出，单向的，如MD五、SHA等。

8.2.2 对称加密 144

对称加密：加密解密使用的密钥是同一个（或者能够相互推算），用在信息交互的场合。如DES算法、RC算法等。

8.2.3 非对称加密 144

非对称加密：加密解密使用的密钥不是同一个，在用信息安全传输、数字签名等场合。如RSA算法。

8.2.4 密钥安全管理 145

密钥切分，分别管理。

8.3 信息过滤与反垃圾 146

8.3.1 文本匹配 147

文本匹配：解决敏感词过滤的问题，正则效率较差，

双数组Trie[t'ri:]算法：优化了Trie算法，利用两个稀疏数组存储树结构，base数据存储Trie树的节点，check数组进行状态检查。

构造多级Hash表：更简单，逐字顺序在过滤树中匹配，浪费部份内存空间

注意：须要对信息降噪预处理，如”阿_富_汗“。

8.3.2 分类算法 148

垃圾邮件识别：贝叶斯分类算法，能够用sklean实现。

8.3.3 黑名单 149

也是垃圾邮件识别手段，加入黑名单过滤。

8.4 电子商务风险控制 150

电子商务具备多种形式：B2B、B2C、C2C.

8.4.1 风险 151

帐户风险：盗用，恶意注册等。

买家风险：恶意下单占用库存、利用促销抢购低价商品、欺诈退款等。

卖家风险：虚假发货、炒做新用、出售围巾商品等。

交易风险：信用卡盗刷、支付欺诈、洗钱套现等。

8.4.2 风控 151

风控手段有自动、人工两种。机器识别高风险交易信息发送给人工审核，机器自动风控的技术也经过人工发现新风险类型逐步完善。

机器自动风控的手段主要有规则引擎（简单，规则越多性能越差）和统计模型（机器学习）。

8.5 小结 153

没有绝对的安全，就像没有绝对的自由。