读书笔记之 大型网站技术架构(核心原理与案例分析)

前言

坚持看了十几天的书，终于完成了毕业后第一次静下心来，利用业务时间看书并做笔记的成就了。废话不多说，这回看的是一直很膜拜的李智慧大神写的大型网站技术架构－核心原理与案例分析。

简短的读后感

极其推荐的一本书，其实我是第二遍读这本书了，第一遍读的时候还没有毕业，读到一半发现很多都没有经历过，便放弃了。正好正在经历着一个大项目的成长中，如今再次读起这本书，多了几分熟悉，多了几分感悟。本书较为易懂，可能是因为很多方案也是当前项目中正在用的，或者正在演变的。通过一个请求的从开始到结束的旅行，讲述了各类丰富的知识。

读书笔记

第一章 大型网站架构演化

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

 高并发、大流量
 高可用
 海量数据
 用户分布广泛、网络情况复杂
 安全环境恶劣
 需求快速变更、发布频繁
 渐进式发展

1.2演化发展历程

1.2.1 初始阶段网站架构：应用程序、数据库、文件均放一台服务器。
1.2.2 应用服务与数据服务的分离
量增大，拆分三台服务器：应用服务器、数据库服务器、文件服务器

      应用服务器:处理大量业务逻辑 -> 更强更快的cpu
      数据库服务器:快速磁盘检索与数据缓存 -> 更快硬盘、更大内存
      文件服务器:存储大量上传文件 -> 更大硬盘

1.2.3 使用缓存改善网站性能
缓存使用分为两种：缓存在应用服务器上的本地缓存、缓存在专门的分布式缓存服务器上的远程缓存

pk:本地缓存受内存大小限制，而远程缓存分布可采用集群的方式，使用较大内存的服务器专门缓存

1.2.4 使用应用服务器集群改善网站的并发处理能力
应用服务器实现集群->应用可伸缩，通过横向扩展服务器解决负载压力问题。
前端增加负载均衡调度服务器，分发请求到不同的应用服务器，实现负载均衡。
1.2.5 数据库读写分离
一主多从，写主读从
1.2.6 使用反向代理和CDN加速网站响应
原理：缓存数据
区别：CDN部署在网络提供商的机房，用户请求可以就近从网络提供商的机房获取数据。反向代理部署在中心机房，请求优先到达机房，存在数据则返回，不存在则转发请求到负载均衡调度服务器。
目的：加快访问速度、减少后端服务器压力
1.2.7 使用分布式文件系统和分布式数据库系统
按业务分库，不同业务部署在不同物理机器上。
1.2.8 使用NoSQL 和搜索引擎
特定场景NoSQL的性能会优于mysql，比如地理位置
应用数据庞大需要搜索时，数据库自带搜索语句已无法满足需求，需借助类似sphinx等搜索引擎优化搜索相关服务
1.2.9 业务拆分
不同业务进行拆分，通过首页超链接或消息队列或通过访问同一数据存储系统来构成一个完整的系统
1.2.10 分布式服务
随着系统业务越来越庞大，所有应用都要连接相同数据库，每个应用系统都需要执行许多相同的业务操作（用户信息获取、商品获取），故将公用业务单独提取出来，独立部署。可复用的业务连接数据库通过业务服务

1.3 大型网站架构演话的价值观

网站的价值在于能为用户提供什么价值，在网站能做什么，而不是它是怎么做的。
1.3.1 大型网站架构技术的核心价值是随网站所需灵活应对
1.3.2 驱动大型网站技术发展的主要力量是网站的业务发展

1.4 网站架设误区

1.4.1 一味追求大公司的解决方案
1.4.2 为了技术而技术
1.4.3 企图用技术解决所有问题
技术是用来解决业务问题的，业务的问题也可以通过业务的手段解决

第二章 大型网站架构模式

2.1 网站架构模式

2.1.1 分层
需合理规划层次边界和接口，遵守分层架构的约束，禁止跨层次调用及逆向调用。
规划软件清晰的逻辑结构便于维护。

2.1.2 分割
不同功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于维护开发，另一方面便于不同模块的分布式部署。

2.1.3 分布式
优点：使用更多的计算机完成相同功能，计算机越多cpu内存存储资源也越多，能够处理的并发访问和数据量就越大，进而可以为更多用户提供服务。
带来的问题：
1.分布式调用意味着通过网络访问，对性能有较严重影响
2.服务器越多，宕机的概率越大，一台服务器宕机造成的服务不可用可能会影响其他服务的不可用
3.数据在分布式中保持数据一致性较难，分布式事务也难以保证。
4.分布式导致应用依赖错综复杂，开发维护难度将加大

      常见的分布式方案：
      1.分布式应用和服务
      2.分布式静态资源
           静态资源独立部署，独立域名加快浏览器加载速度
      3.分布式数据和存储
      4.分布式计算
           搜索引擎索引构建、数据仓库、数据分析
      5.分布式配置
      6.分布式锁
      7.分布式文件系统

2.1.4 集群
集群即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务

2.1.5 缓存
1.CDN
2.反向代理（静态资源）
3.本地缓存
4.分布式缓存

使用缓存建议：
      1.访问热点不均匀，某些数据会被更频繁访问
      2.数据在某个时间段内有效，不会很快过期，否则缓存的数据会因为实效而产生脏读。

2.1.6 异步
1.提高系统可用性；数据在消息队列中堆积，即使消费者服务器挂了，待恢复后还可以继续执行
2.加快网站响应速度；无需处理非关键的数据库处理，丢队列后可直接返回
3.消除并发访问高峰；设置阀值，当访问请求数据超过阀值，放入队列处理，则不会产生较大的负载压力

2.1.7 冗余
冷备份：定期备份数据，存档保存
热备份：数据库主从分离
灾备数据中心

2.1.8 自动化
自动化发布：代码推送系统
自动化代码管理：git、svn
自动化测试：jenkins
自动化安全检测
自动化部署：代码推送系统
自动化监控：zabbix
自动化报警：设置阀值异常邮件短信报警
自动化失效转移：失效服务器从集群中隔离出来
自动化失效恢复：重启服务
自动化降级：拒绝请求以及关闭非关键业务以保证核心业务的可用性
自动化分配资源

2.1.9 安全

第三章 大型网站核心架构要素

3.1 性能

      指标：响应时间，TPS，QPS，系统性能计数器

3.2 可用性

      服务器宕机的时候，服务依旧可以使用。
      高可用主要手段是冗余：应用部署在多台服务器，数据存储在多台服务器相互备份，集群中任何一台宕机都不会影响服务和数据丢失。
      应用服务器不能保存请求的会话信息，否则宕机，会话丢失，其他服务器将无法完成用户请求。

3.3 伸缩性

所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断上升的用户并发访问压力和不断增长的数据存储需求

3.4 扩展性

      扩展性好坏指标：新增产品时，是否可以实现对现有产品透明无影响，不需要改动或很少改动既有的业务功能就可以上线新产品
      扩展性主要手段：
      1.事件驱动架构：利用消息队列实现，将用户请求和其他业务事件构造成消息发布到消息队列，消息的处理者作为消费者从消息队列中获取消息进行处理。
      2.分布式服务
      将业务和可服用的业务分离开来，通过分布式服务框架调用。新增产品调用可服用的服务，对现有的产品无影响。

3.5 安全性

第四章 瞬时响应：网站的高性能架构

重新定义网站性能：网站性能上客观指标，可以具体到响应时间，吞吐量等等。用户的感受和工程师的感受是不同的，并非接口响应快，用户就会感觉快。

4.1 网站性能测试

4.1.1 不同视角下的网站性能
1.用户视角的网站性能：计算机和服务器通信时间＋服务器处理时间＋浏览器构造请求解析响应时间
优化方向：html 样式＋利用浏览器端的并发异步特性＋调整浏览器缓存策略＋cdn+反向代理
2.开发人员视角的网站性能：响应延迟＋系统吞吐量＋并发处理能力＋系统稳定性
优化方向：缓存加速数据读取＋使用集群提高吞吐量＋异步消息加快请求响应和实现削峰＋代码优化
3.运维人员视角的网站性能：基础设施性能＋资源利用率(运营商带宽、服务器硬件配置、数据中心网络架构、服务器和网络宽带资源利用率)
优化方向：建设优化骨干网＋使用高性价比定制服务器＋利用虚拟化技术优化资源利用

4.1.2 性能测试指标(响应时长、并发数、吞吐量、性能计数器)
1.响应时长：执行一个操作的时长
2.并发数：同时处理的请求数目
3.吞吐量：单位时间内系统处理的请求量
TPS（每秒事务数） HPS（每秒http请求数） QPS（每秒查询数）
4.性能计数器：描述服务器或者操作性能的一些数据指标（top命令）

4.1.3 性能测试方法
1.性能测试
2.负载测试
3.压力测试
4.稳定性测试
性能测试是一个不断对系统增加访问压力，以获得系统性能指标、最大负载能力、最大压力承受能的的过程。所谓增加访问压力就是增加程序并发的请求数。

4.1.4 性能测试报告

4.1.5 性能优化策略
1.性能分析
检查请求处理的各个环节的日志，分析哪个环节响应时间不合理、超过预期；然后坚持监控数据，分析影响性能的主要因素是内存、磁盘、网络还是cpu，是代码问题还是架构设计不合理，或者系统资源不足
2.性能优化
web前端性能优化、应用服务器优化、存储服务器优化

4.2 web前端性能优化

一般来说web前端指网站业务逻辑之前的部分，包括：浏览器加载、网站视图模型、图片服务、cdn服务等。主要优化手段：浏览器访问、使用反向代理、cdn

4.2.1 浏览器访问
1.减少http请求
原因:http无状态，每次http请求都需要建立通信链路进行数据传输，服务端也需要独立线程处理
措施:合并css、合并js、合并图片
2.使用浏览器缓存
原因:css、js、图片都属于静态资源文件更新频率低，每次请求又都是http请求，故可缓存浏览器
措施:通过设置HTTP头中Cache-Control和Expires的属性
注意:可通过改变文件版本的形式进行更新，但需逐量更新，并存在一定时间间隔，防止大量缓存实效，集中更新缓存，造成服务器负责骤增和网络堵塞。
3.启用压缩
压缩文件，减少通信传输的数据量
4.css放在页面最上面，js放在最下面
css渲染页面放开头，js放开头立马执行会阻塞页面显示
5.减少cookie传输
原因:cookie包含在每次的请求中，太多cookie会影响数据传输。对于css、js这些文件传cookie是没用的，考虑静态资源使用独立资源，减少cookie传输次数

4.2.2 CDN加速
CDN能够缓存的一般是静态资源，如图片、文件、css、js、静态网页等。访问频次高的文件加上cdn缓存可极大提高打开速度

4.2.3 反向代理
反向代理服务器配置缓存功能缓存静态资源，则可直接返回，无需到达应用服务器。反向代理服务器也可起到负载均衡的作用

4.3 应用服务器性能优化

应用服务器就是处理网站业务的服务器，代码都部署在这里。优化手段：缓存、集群、异步

4.3.1 分布式缓存
1.缓存基本原理：存在访问速度较高的存储介质中(加快访问速度、减少数据计算时间)
2.合理使用缓存
频繁修改的数据
没有热点访问的数据
数据不一致和脏读
缓存可用性(避免缓存雪崩、视情况使用分布式缓存)
缓存预热
缓存穿透（业务使用不恰当或者恶意攻击持续高并发的请求某一不存在数据，由于缓存不存在，则所有请求打到数据库上，会造成压力甚至雪崩’一个简单的策略是将不存在的数据也缓存起来,设为null）
3.分布式缓存架构
分布式缓存指缓存部署在多个服务器组成的集群中，以集群的方式提供缓存服务
a.JBoss Cache分布式缓存，要求每台服务器数据都必须一致，故会相互同步，缺点是缓存容量受限于单一的服务器。更多见于企业应用系统中，大型网站较少见
b.Memcache分布式缓存，不互相通信。通过一致性hash等路由算法选择缓存的服务器远程访问数据，缓存集群的规模可以很好的实现扩容，具有良好的可伸缩性
4.Memcache
a.简单的通信协议
远程通信设计需要考虑的点：
.通信的协议：tcp/udp/http
.通信序列化协议：xml/json等文本序列化协议、google的protobuffer等二进制序列化协议
b.丰富的客户端程序
c.高性能的网络通信(基于libevent,支持事件触发的网络通信程序库)
d.高效的内存管理
e.互不通信的服务器集群架构

4.3.2 异步操作
增加消息队列服务器

4.3.3 使用集群
在高并发场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将高并发的请求分发到多台服务器上，避免单一服务器负载过高。

4.3.4 代码优化

4.4 存储性能优化

4.4.1 机械硬盘 vs 固态硬盘
机械硬盘连续访问数据，需要移动磁头臂来读取，移动的次数和性能表现也相差较大
固态硬盘将数据存储在可持久记忆的硅晶体上，像内存一样快速访问

4.4.2 B+树 vs LSM树
目前数据库(mysql)多采用两级索引的B+树，树的层次最多三层，因此需要5次磁盘访问才可以更新一条数据(三次磁盘访问获得索引以及id，再进行一次数据文件读操作以及一次写操作)
nosql多采用LSM树最为数据结构，n阶合并树，进行数据更新不需要访问磁盘，内存中即可完成。

4.4.3 RAID vs HDFS
插入多块磁盘，通过RAID技术实现多块磁盘上的并发读写和数据备份

第五章 万无一失：网站的高可用架构

5.1 网站可用性的度量和考核

5.1.1 网站可用性度量
qq可用性4个9，即99.99%，一年<=53分钟不可用
2个9是基本可用，一年<=88小时
3个9是较高可用，一年<=9小时
5个9是极高可用，一年<=5分钟

5.1.2 网站可用性考核

5.2 高可用的网站架构

网站高可用的架构设计的目的是保证服务器硬件故障时服务依然可用，数据依然可以被正常访问
手段是数据和服务冗余备份以及实效转移

应用层：负载均衡设备通过心跳检测，发现服务器不可用则从集群列表中移除
服务层：分布式服务调用框架会在应用层客户端程序中实现软件负载均衡，并通过服务注册中心进行心跳检测，发现服务不可用立即通知客户端程序修改访问列表
数据层：在数据写入时就冗余备份，发现数据服务器宕机，则切至备份服务器

5.3 高可用的应用

5.3.1 通过负载均衡进行无状态服务的失效转移(应用逻辑层)

5.3.2 应用服务器集群的session管理
1.session复制
服务器之间session相互备份，仅适用于小型的网站，不适用于大型网站，当集群较大并在线人数多的时候，将会出现内存不够存放session的情况
2.session绑定
通过负载均衡的源地址通过hash(或者cookie信息)，将同一ip的请求总分发到一台服务器上，但这不符合高可用的需求，一旦宕机则session就不存在了。
3.利用cookie记录session
cookie简单易用，可用性高，支持应用服务器的线性伸缩，而大部分需要记录在session的信息比较少时可使用，缺点是受cookie大小限制，每次请求都要传cookie，影响性能，用户要是关闭了cookie则访问会不正常，并且存在一定的安全问题。
4.session服务器
使用session服务器，独立部署session服务，达到共享session的效果，一般做法是利用分布式缓存、数据库等，记录session。（memcache记录session）

####5.4 高可用的服务

1.分级管理：区分核心与非核心服务用的服务器
2.超时设置：防止宕机或者线程死锁导致长时间大量占内存
3.异步调用：避免连串的服务请求，某一个失败而导致全部失败
4.服务降级
a.拒绝服务：拒绝低优先级服务的调用，减少服务并发数，以保证核心集群的可用性。或者随机拒绝部分请求，节约资源，让一部分人请求成功。
b.关闭服务：关闭不重要的服务。比如双十一，系统繁忙时会关闭掉评论和确认收货等非关键服务
5.幂等性设计
定义：调用一次或者多次产生一样的结果
防止明明请求成功了，由于网络故障没收到响应导致进行重试。(尤其付款时候)

####5.5 高可用的数据

5.5.1 CAP原理
1.数据持久性：写入时写到持久性存储，进行备份，并放在不同的物理存储设备上
2.数据可访问性：用户无感知情况下，进行数据服务器的切换，切换数据存储设备
3.数据一致性
CAP原理认为一个提供数据服务的存储系统无法同时满足数据一致性(所以应用程序都能访问得到相同的数据)、数据可用性(任何时刻任何应用程序都可以写)、分区耐受性(系统可以跨网络分区线性伸缩)
大型网站一般选择高可用和伸缩性，某种程度上放弃一致性。
数据不一致情况：高并发写入、集群状态不稳定、故障恢复、集群扩容
数据一致性分类：数据强一致性(物理存储中一致)、数据用户一致性(物理存储不一定一致，但通过校验等机制，返回给用户的是一致的)、数据最终一致性(物理存储中不一致，返回给用户也是不一致，但会进行自我修复，数据最终一致)

5.5.2 数据备份
1.数据冷备
定期将数据备份到某种存储介质中。
优点：操作简单、廉价
缺点：不能保证数据最终一致，未备份数据将永久丢失，不满足高可用，从冷备中恢复数据需要比较长的时间
2.数据热备
a.异步热备方式：只写主服务器，通过线程异步写到从服务器
b.同步热备方式：同时写到多台服务器，无主从之分，但要是返回失败存在可能某一台写入成功了。

5.5.3 实效转移
1.实效确认：心跳检测、应用程序访问失败报告
2.访问转移：重现计算访问路由
3.数据恢复：

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

5.6.1 网站发布
分批次更新集群中的服务器代码

5.6.2 自动化测试

5.6.3 预发布验证
需要安排一台类似beta环境的机器，与线上环境不同的是，这个机器用户无法访问，不在负载均衡服务器上，但是用的是和线上一样的环境，一样的数据。

5.6.4 代码控制
gitlab、svn

5.6.5 自动化发布

5.6.6 灰度发布

5.7 网站运行监控

5.7.1 监控数据采集
1.用户日志行为收集
服务端日志收集：缺点是收集到的ip可能是代理服务器的ip
客户的浏览器日志收集：缺点是要专门写javascript脚本进行请求
2.服务端性能监控：开源工具Ganglia
3.运行数据报告

5.7.2监控管理
1.系统报警
2.失效转移
3.自动优雅降级：为了应付突然爆发的访问高峰，主动关闭部分功能

第六章 永无止境:网站的伸缩性架构

所谓的网站伸缩性指的是不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数据就可以扩大活着缩小网站的服务处理能力。

6.1 网站架构的伸缩性

伸缩性分两类：一类是根据功能进行物理分离实现伸缩性，一类是单一功能通过集群实现伸缩性。前者是不同的服务器部署不同服务，提供不同功能；后者是集群内的多台服务器部署相同的服务，提供相同功能。

6.1.1 不同功能实现物理分离实现伸缩
1.单一服务器处理所有服务->数据库从应用服务器分离->缓存从应用服务器分离->静态资源从应用服务器分离
2.纵向分离：网站具体产品、可服用的业务服务、基础技术服务、数据库
3.横向分离：网站前台、卖家后台、买家后台、交易论坛

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

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

应用服务器首先是无状态的。不保存上下文。主要通过负载均衡进行伸缩性的设计

6.2.1 HTTP重定向负载均衡
http重定向服务器是一台普通的应用服务器，其唯一功能是根据用的http请求计算一台真实的web服务器地址，并将web服务器地址写入http重定向响应中返回给用户。
优点：比较简单
缺点：需请求两次才能完成请求，性能较差；重定向服务本身可能成为瓶颈就使整个集群伸缩性有限；使用http302响应码重定向，可能被seo判断为作弊

6.2.2 DNS域名解析负载均衡
DNS服务器配置中配置多个A记录，每次域名解析会根据负载均衡算法计算一个不同的ip地址返回，这样A记录中多个服务器就形成了一个集群。
优点：将负载均衡的工作转交给了DNS，省掉了维护负载均衡服务器的麻烦，同时DNS还支持基于地理位置的域名解析，返回离用户最近的服务器地址。
缺点：DNS是多级解析，每一级都可能缓存A记录,当某台服务器由于故障下线后，即使修改了A记录，DNS依旧可能解析到这台服务器导致访问失败。还有就是控制权在域名服务商，无法做更多更好的改善。

6.2.3 反向代理负载均衡
在所有应用服务器前面加一层反向代理服务器，接受用户请求，根据负载均衡算法分发到某一应用服务器，处理好后，返回给反向代理服务器，在返回给用户。web服务器不需要外网ip,反向代理服务器需要配置双网卡和内外部两套ip地址
优点：转发请求在HTTP协议层面，也叫应用层负载均衡。部署简单
缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈

6.2.4 IP负载均衡
用户请求到达负载均衡服务器后，通过操作系统内核进程获取网络数据包，将目的IP修改为负载均衡算法计算得到的一台服务器，处理完成后，在返回给负载均衡服务器，再将源地址修改为自身的IP地址，返回给用户。
真实的web服务器，如何将响应数据包返回给负载均衡服务器？
a.将负载均衡服务器设为应用服务器集群的网关服务器，这样所有响应都会到达这里。
b.负载均衡服务器在修改目的IP地址的同时将自身IP设置为源地址，即源地址转换(SNAT)。这样请求也会再回来
优点：IP负载均衡在内核进程完成数据分发，较反向代理服务器（在应用程序中奋发数据），性能更好
缺点：集群最大响应数据吞吐量受限于负载均衡服务器网卡带宽。对于下载服务或者视频服务等需要大量数据的网站不适合。

6.2.5 数据链路层负载均衡
在通信协议的数据链路层修改请求数据目的mac地址进行负载均衡。又称三角传输模式
负载均衡分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，达到不用修改数据包源地址和目的地址就可以进行数据的分发，由于实际处理请求的物理服务器IP和请求数据目的IP一致，所以不需要通过负载均衡服务器，可以直接返回给用户，避免了负载均衡服务器网卡带宽瓶颈的问题，又称为直接路由方式(DR).
在linux平台最好的链路层负载均衡开源产品是LVS(Linux Virtual Server)

6.2.6 负载均衡算法
a.轮询：一次分发到每台服务器，每台服务器处理的请求数目一样。
b.加权轮询：根据硬件的性能情况，在轮询基础上按照权重进行分发请求。
c.随机
d.最少连接：记录每个服务器在处理的连接数，新的请求分发到连接数最少的服务器。同时存在加权最少连接。
e.源地址散列：根据请求IP地址进行hash计算，得到对应服务器。这样同一个ip会到相同服务器处理，存储请求的上下文信息。

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

6.3.1 Memcached分布式缓存集群的访问模型
通过路由算法从服务器列表中计算出对应的memcache服务器，然后进行连接操作。

6.3.2 Memcached分布式缓存集群的伸缩性挑战
通过hash对总服务器数目取余的方法来决定选择哪一台服务器。
挑战：当需要增加服务器的时候，会出现大量缓存没命中，直接穿透到数据库层。
临时的解决办法：在业务低谷期进行服务器增加，并通过模拟请求的方式，预热数据，使缓存服务器均匀分布缓存。

6.3.3 分布式缓存的一致性Hash算法
一致性hash算法，构造一个长度为2^32的整数环，将缓存服务器节点均匀的分布在这上面，根据key值进行hash，在环上顺时针寻找最近的节点，即为选中的服务器。
当需要再增加一台服务器的时候，选择任两节点中间插入一台，则另外两段缓存的不受影响，只有其中一个节点一般的数据受到影响。
问题来了：那么这很明显另外两个不受到影响的节点的负载肯定比受到影响以及新加入的服务器的负载高，这不是愿意看到的。
名言：计算机的任何问题都可以通过增加一个虚拟层来解决
办法：新加入的服务器通过构造多个虚拟节点(这里是3个)，来合理的安插在环中，这样只要命中虚拟节点就会到新增服务器，并且影响数据和未使用虚拟节点的一致性hash是一致的。
虚拟节点多了也不是好事，会影响性能，太少会影响负载均衡，经验值是150个。

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

6.4.1 关系数据库集群的伸缩性设计
分片：将一张表拆分开分别存储在多个数据库中
支持数据分片的分布式关系数据库产品：Amoeba\Cobar
通过在应用服务器和分布式存储服务器之间加一层类似路由转接层的服务器。来代理数据库的访问。
通过构造schema为单位的数据块，当新服务器增加时候，通过mysql的同步机制同步schema，当新旧服务器数据一直时候，修改Cobar的路由规则，再去除掉旧服务器重复部分。

6.4.2 NoSQL数据库的伸缩性设计
放弃以关系代数为基础的结构化sql语句和事务一致性保证。更关注高可用和可伸缩性。

第七章 随机应变：网站的可扩展架构

伸缩性：指系统通过增减自身资源规模的方式增减自己计算处理事务的能力，这种增减是成比例的，成为线性伸缩性。
通常指增减服务器数量提高整体的事务吞吐能力。

扩展性：对现有的系统影响最小的情况下，系统功能可持续扩展或提升的能力。
表现在系统基础设施稳定不需要经常变更，应用之间很少耦合，对需求变更可以更加敏捷响应。
是架构设计层面的开闭原则，增加新功能时候，不需要对现有的代码或结构进行更改。

7.1 构建可扩展的网站架构

7.2 利用分布式消息队列降低系统藕合度

7.2.1 事件架构驱动
通过在低耦合的模块之间传输事件消息，以保持模块的松散耦合，并借助事件消息的通信完成模块间的合作。

7.2.2 分布式消息队列
伸缩性方面，可以通过加服务器的手段，来对新的业务单独起一个队列进行消费。
可用性方向，当消息队列太多的时候，直至内存满了，则会讲数据写入磁盘，当处理完后，在从磁盘取出继续处理（redis queu）

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

 纵向拆分：将一个大应用拆分成多个小应用，如果新增业务较为独立，则直接设计部署一个独立的web系统
 横向拆分：将复用的业务独立拆分出来，独立部署成分布式服务，新增业务只需要调用这些分布式服务，不需要依赖具体代码块。

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

7.3.2 大型网站分布式服务的需求与特点
1.负载均衡
2.实效转移
3.高效的远程通信
4.整合异构系统
5.对应用最少侵入
6.版本管理
7.实时监控

7.3.3 分布式服务框架设计
阿里巴巴的Dubbo

7.4 可扩展的数据结构

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

 1.API接口：开放平台暴露给开发者的接口，其形式可以是RESTful/WebService/RPC
 2.协议转换：将各种api输入转换成内部服务可以识别的形式，并将内部服务的返回封装成api的格式
 3.安全：身份识别、权限控制、访问带宽限制。
 4.审计：记录第三方的访问情况，并进行监控和计费。
 5.路由：将各种访问映射到具体的服务
 6.流程：隐藏服务细节，提供统一服务接口

第八章 固若金汤：网站的安全架构

8.1 道高一尺魔高一丈得网站应用攻击与防御

8.1.1 XSS攻击
即跨站点脚本攻击(cross site script)，指黑客通过串改网页，恶意注入html脚本，在用户浏览网站页面时候，控制用户浏览器进行恶意操作的一种攻击方式。
一种是反射型：恶意诱导点击某嵌入恶意脚本的链接，达到攻击的目的。
另一种是持久型：黑客提交含有恶意脚本的请求，保存在被攻击的web站点的数据库中，用户浏览网页时，恶意脚本被包含在政策页面中，达到攻击的目的。

 针对手段：
 1.消毒：敏感字符转义
 2.HttpOnly：浏览器禁止js访问带有HttpOnly属性的Cookie，HttpOnly并不是直接对抗XSS攻击的，
 而是防止XSS攻击者盗取Cookie（有敏感信息如用户认证信息）。

8.1.2 注入攻击
主要是SQL注入和OS注入

 针对手段
 1.消毒：过滤敏感字符
 2.参数绑定：采用预编译手段，PDO。

8.1.3 CSRF攻击
跨站点请求伪造(Cross Site Request Forgery)，攻击者通过跨网站请求以合法的身份进行非法的操作。其核心是利用了浏览器的Cookie或服务器的Session，盗取用户身份。

 针对手段：
 1.表单Token：每次都返回一个随机数当Token，阻止攻击者获取所有信息。
 2.验证码
 3.Referer check：HTTP请求头的Referer域中记录着请求来源，可通过检查来源，验证是否合法。
 很多网站使用这个功能让图片防盗链，如果访问图片的网站发现不是自己的网站则拒绝。

8.1.4 其他攻击和漏洞
1.Error Code：错误回显。看错误信息得到可攻击的信息。防御：通过配置500错误跳转页面到专门错误页即可。
2.HTML注释
3.文件上传：上传可执行程序进行攻击。防御：上传时候除了检测文件名还需要检测文件属性，并且文件存储服务器禁止执行操作。
4.路径遍历：攻击者在请求的url中使用相对路径，遍历系统未开放的目录和文件。防御：将js、css等资源文件部署在独立的服务器、使用独立域名，其他文件不使用静态url访问，动态参数不包含文件路径信息。

8.1.5 Web应用防火墙
ModSecurity：开源的web应用防火墙，支持nginx、apache等。

8.1.6 网站安全漏洞扫描

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

敏感数据的数据加密分为三类：单向散列加密、对称加密、非对称加密。

8.2.1 单向散列加密
不同的输入长度得到固定的输出长度：MD5、SHA
通常还会加上盐值增加破解难度

8.2.2 对称加密
加密和解密使用的秘钥是一样的，可以互推。
加密算法：DES算法、RC算法

8.2.3 非对称加密
加密和解密使用的秘钥是不同的，对外公开的叫公钥，另一个只有所有者知道叫做私钥。
RSA算法。HTTPS传输中浏览器使用的数字证书实质上是经过权威机构认证的非对称加密的公钥。

8.2.4 密钥的管理
1.把密钥和算法放在一个独立的服务器上，甚至做成一个专用的硬件设施，对外提供加密和解密服务。
缺点：一方面是维护成本较高，另一方面可能成为性能瓶颈，每次加密解密都需要远程调用，系统开销也大
2.将加密算法放在应用程序中，密钥则放在独立的服务器中，为了提高密钥的安全性，实际存储时，密钥被切分成数片，加密后分别存在不同的存储介质中。

8.3 信息过滤与反垃圾

8.3.1 文本匹配
8.3.2分类算法
8.3.3黑名单

8.4 电子商务风险控制

8.4.1风险
账户风险、买家风险、卖家风险、交易风险

8.4.2风控
规则引擎、统计模型

第九章 淘宝网的架构演化案例分析

第十章 维基百科的高性能架构设计分析

第十一章 海量分布式存储系统Doris的高可用架构设计分析

故障分类：
1.瞬时故障
原因：网络通信瞬时中断、服务器内存垃圾回收或后台线程繁忙停止数据访问操作响应。
解决办法：多次尝试
失效访问模型：访问->再次访问->存储服务器实效仲裁(存储服务器心跳检测、实效仲裁检测)

2.临时故障
原因：交换机宕机、网卡松动等导致的网络中断；系统升级、停机维护等一般韵味活动引起的服务关闭；内存损坏、cpu过热等硬件原因引起的服务器宕机
解决办法：专门部署一个备用服务器集群，正常情况下是空闲的，当异常时候才会有数据写入。
实效访问模型：当临时故障时候，首先先将读和写的路由列表中将故障服务器去除，同时补上备用服务器。当故障恢复，再将备份服务器的数据同步回来，同时撤掉备用服务器换上故障恢复的服务器。

3.永久故障
原因：硬盘损坏、数据丢失
解决办法：只能人工检测，因为无法区分是临时还是永久
失效访问模型：同临时故障

第十二章 网购秒杀系统架构设计案例分析

 如何控制秒杀的按钮在规定时间可以促发？
 将秒杀商品的js放在设好的定时任务的服务器中，当时间到达的时候，将js文件推送到js的服务器集群，
 以供秒杀的用户进行客户端获取（每次用户刷新一回商品页面、就请求加载一次js文件直至有了为止。）。

第十三章 大型网站典型故障案例分析

13.1 写日志也会引发故障

 1.应用服务器硬盘小的时候不进行日志的存储
 2.需要区分自己程序的输出日志和第三方程序输出的日志
 3.检查log配置文件，输出级别至少为warn
 4.有些开源第三方组件会自己记录很多日志，适当关闭

13.2 高并发访问数据库引发的故障

 接口数据必须尽量都缓存，防止直接穿透到数据库

13.3 高并发情况下锁引发的故障

13.4 缓存引发的故障

 缓存非常重要，已经不仅仅是缓存数据，更是抗住高并发的重要因素

13.5 应用启动不同步引发的故障

 启动顺序需谨慎，防止前端可访问了，而供后端的支持仍然处于开启中。

13.6 大文件读写独占硬盘引发的故障

 需区分大小文件，小文件不能和大文件一起存储

13.7 滥用生产环境引发的故障

 防止直接对线上进行压力测试等会占据大量资源的操作。

13.8 不规范的流程引发的故障

 加强代码的review，防止因为图方便而备注掉缓存，直接读数据库的代码传到线上。

13.9 不好的变成习惯引发的故障

第十四章 架构师领导艺术

第十五章 网站架构师职场之路

第十六章 漫话网站架构师

如果你觉得有收获～可以关注我的公众号【咖啡色的羊驼】～第一时间收到我的分享和知识梳理～