网站技术架构与性能优化(读书笔记)

一. 概述

1.大型软件系统的特点

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

2.大型网站架构发展历程

1.应用服务和数据服务分离
2.大量使用缓存改善网站性能(CDN加速、反向代理)
3.使用服务器集群改善网站并发能力
4.数据库读写分离
5.分布式文件(数据库)系统
6.NoSql与非数据查询技术(搜索引擎)
7.业务拆分(横向、纵向)

3.大型网站架构的价值观

1.核心价值: 渐进式
2.主要动力: 业务发展
3.设计误区: 
   1.一味追求大公司的解决方案
   2.为了技术而技术(不管是否适用，追求时髦，什么新用什么)
   3。企图用技术解决所有问题(有时候好的业务架构要比技术架构更加重要)

二. 大型网站架构的主要模式

1.技术架构要实现的目标(核心要素):

1.高性能

1.性能问题是网站优化升级的触发器
2.前端常用优化方法:
    浏览器缓存
    页面压缩
    合理布局
    减少cookie传输
    CDN
    反向代理
3.后台常用优化方法:
    服务器本地缓存
    分布式缓存
    消息队列
    集群
    数据库优化手段(索引、缓存、sql优化)
    NoSql

2.可用性

1.主要问题:
    服务器宕机
2.解决手段:
    冗余备份

3.伸缩性

1.大型网站面临的问题:
    高并发访问
    海量数据存储
2.解决手段:
    构建集群: 应用服务器集群、缓存服务器集群、数据库服务器集群

4.扩展性

1.事件驱动架构
    消息队列(观察者模式)
2.分布式服务
    业务与可复用服务相分离(模块化)

5.安全性

防范各种攻击窃密手段

2.网站架构主要的几种模式

1.分层

2.分割

3.分布式

4.集群

5.缓存

6.异步

7.冗余

8.自动化

9.安全

三. 高性能架构

1.开发人员和用户看待性能的角度不同

2.性能测试指标

1.响应时间

送发出请求到收到响应所经过的时间

2.并发数

单位时间同时处理请求数

3.吞吐量

单位时间处理请求数

4.性能计数器

描述服务器或操作系统性能的一系列数据指标

3.性能测试方法

1.性能测试

处理能力与并发数成正比

2.负载测试

处理能力增长缓慢，达到最大负载点

3.压力测试

处理能力反而下降，达到崩溃点

4.稳定性测试

长时间不均匀地对系统施加压力

4.前端性能优化

1.减少http请求

2.使用浏览器缓存

3.启用压缩

4.使用正确的文件加载方式

5.减少cookie传输

6.CDN加速(缓存）

部署在网络运营商机房(网路第一跳)

7.反向代理(缓存)

5.应用服务器性能优化

1.分布式缓存(网站性能优化第一定律:优先考虑使用缓存)

1.缓存的基本原理:

    1.将数据存储在较高访问速度的存储介质中
    2.本质是一个 内存(读取速度快吗不是)Hash表(查询速度快吗不是)

2.合理使用缓存：

    1.不要缓存频繁修改的数据
    2.要遵循二八定律，不要缓存低命中的数据
    3.要注意 缓存的时效性 引起的问题

3.缓存可用性:

    1.通过将缓存数据分布在集群中，当一台缓存服务器宕机时，从而防止全面更新缓存引起的性能消耗
    2.对于已知的热点数据直接加载好(缓存预热)，而不需使用LRU不断筛选预热
    3.预防缓存穿透(攻击者不断请求某个不存在的数据，从而穿透缓存服务器，对数据库服务器造成极大的压力)

4.分布式缓存架构(分为两类):

    1.数据相同，同步更新(JBoss Cache)
    2.Memcached:
        简单的通讯协议(缓存客户端与缓存服务器)
        丰富的客服端(支持多种语言)
        高性能网络通信(支持事件触发)
        高效内存管理(固定空间分配)
        互不通信的服务器集群架构(客户端路由算法: 一致性Hash算法)(无限制线性伸缩)

2.异步操作

使用 消息队列 将 调用 异步化

    1.用户的数据在发送给消息队列服务器后 立即返回
    2.消息队列服务器 中的消费者进程从消协队列中获取数据异步写入数据库
    3.达到了削峰作用(削平高峰时期的并发任务)
    4.无法在返回时告知用户成功信息

3.使用集群

在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多太服务器组成的服务器集群，将并发请求分发的多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户具有更好的响应延迟特性

4.代码优化

1.多线程

利用多线程io阻塞与执行，可最大限度地利用cpu资源

注意:

    1.将对象设计为无状态对象
    2.使用局部对象
    3.并发访问资源时使用锁

2.资源复用

    1.单例模式
    2.对象池(减少对象创建删除引起的资源消耗)

3.合适的数据结构

4.合理的GC

6.存储性能优化

1.硬件技术
2.存储结构技术
3.磁盘读写技术

四. 高可用架构

1.网站可用性度量

网站可用时间占比(4个9)

2.高可用架构

实现高可用架构的主要手段:

数据服务的冗余备份和失效转移

高可用架构的基本分层模型(与解决方案):

应用层 => 负载均衡
服务层 => 负载均衡
数据层 => 冗余备份

3.高可靠的应用(应用服务器集群)

1.使用负载均衡对无状态服务进行失效转移(心跳检测识别宕机服务器)
2.session管理
    解决方案:
    1.复制
    2.绑定->原地址hash算法),一个客户端只会访问同一台服务器(session绑定技术)
    3.cookie记录session(扯犊子)
    4.session服务器:
    利用独立部署的session服务器统一管理session

4.高可靠的服务(分布式部署可复用的公共服务模块)

1.分级管理

核心服务(功能)使用好的硬件，部署备份

2.超时设置

负载均衡实现失败转移

3.异步调用

异步消息队列

4.服务降级

拒绝服务及关闭服务

5.幂等性设计

对于特殊的业务场景设置其幂等

5.高可用的数据

1.高可用数据的三层含义:

持久性: 不会丢失
可访问性: 失效转移
数据一致性: 所有副本一模一样

2.数据备份

冷备份: 恢复到上一个保存点，啥也保证不了
热备份: 
    异步 => 主同从异
    同步 => 主从同写

3.失效转移

失效确认: 
    心跳检测
    应用程序访问失败报告 => 收到报告后还需进行一次心跳检测，以免误报
访问转移:
    重新路由
数据恢复:
    宕机恢复后恢复数据

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

1.网站发布 => 部分宕机发布
2.自动化测试 => 自动化测试工具
3.预发布验证 => 预发布服务器(不接入负载均衡，外网无法访问)
4.代码管理 => git
5.自动化发布 => 火车发布模型
6.灰度发布 => 渐进式发布

五. 网站的伸缩性架构

1.伸缩性设计模式

1.不同功能进行物理分离实现伸缩
    应用服务器 => 数据库分离 => 缓存分离 => 静态资源分离
    还分为两种情况:
    纵向: 从高级逻辑 到 底层调用
    横向: 不同功能的横向解偶
2.单一功能通过集群实现伸缩

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

核心:http请求分发

分类：

1.http重定向

302 location 不利于SEO

2.DNS域名解析

多重负载均衡

3.反向代理

请求转发

4.IP负载均衡

修改ip地址

5.数据链路层负载均衡

不修改ip地址

6.负载均衡算法：

轮询 加权轮询 随机 最少连接 源地址散列

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

就是一个 一致性hash算法

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

1.关系数据库

    1.主从分离
    2.数据分片/分区

2.NoSql

sql + 数据一致性 => 高可用 + 可伸缩

六. 网站的可扩展架构

（说白了就是模块化 各种解耦 解得越彻底 复用性和可扩展性 就越高）

1.对 扩展性 和 伸缩性 进行区分

1.扩展性指的是: 当系统增加新功能时，不需要对现有系统的结构和代码进行修改。
2.伸缩性指的是: 利用集群的方式增加服务器的数量、提高系统的整体事务吞吐能力。

2.可扩展的 网站架构

通过模块分布式部署 以降低耦合性

3.分布式消息队列(降低系统耦合性)

即使 模块之间不存在 直接调用

事件驱动架构

1.操作系统中的生产者消费者模式 就是 典型的事件驱动架构
2.而在大型网站架构中, 分布式消息队列 就是 事件驱动架构的 一种具体实现手段
3.而消息队列 有利用 发布－订阅模式工作
为什么叫 消息队列 ？ 先进先出
发布者 发布消息 消息队列未满 消息进入队列
订阅者 消息队列不为空 消息从队列中弹出
先进先出
优点：通过消息队列使系统具有更好的 响应延迟(因为发布者不需要等待订阅者处理数据就可以得到返回)

更厉害的－－－分布式消息队列

通过一个消息队列服务器 (服务器本地内存队列)实现
厉害在哪里？
1.伸缩性，直接在分布式集群中增加主机
2.可用性，
通过内存和磁盘的相互读写 解决了 内存队列大小限制 的问题
通过在 生产者服务器中 备份消息 解决了 消息队列服务器宕机 的问题

4. 分布式服务(降低系统耦合性)

可复用的业务平台

分布式消息队列通过 消息 解耦

而分布式服务通过 接口 解耦

1.问题: 随着网站架构的不断发展，一个web应用中往往聚合了大量的应用和服务组件，这个巨无霸带来了很多问题:

1.编译部署困难
2.代码分支管理困难
3.数据库连接耗尽
4.新增业务困难(可扩展性差)

2.解决

1.纵向: 一个webapp变多个webapp
2.横向: 相同功能 模块化、分布化

3.需求和特点

1.负载均衡
2.失效转移
3.高效的远程通信
4.整合异构系统
5.对应用最少入侵(渐进式发展)

5.可扩展的数据结构

Sql => NoSql

6.利用开放平台建设网站生态圈

就像开放的nodejs社区使nodejs在近几年得到了飞速的发展

网站的安全架构

1.网站应用攻击与防御

1.XSS(跨站脚本)攻击

类型: 反射性 持久性
解决方案: 消毒 HttpOnly

2.sql注入

3.CSRF(跨站请求伪造)

攻击的主要原理： 窃取用户身份

防御手段:

1.表单token: 通过每次提交时带上 服务器随机产生并放入response的token随机数，对用户的身份进行验证，而坏蛋是无法获取token的(同源策略)
2.验证码
3.referrer 字段
http 请求头首部的referer字段 表明了 请求的来源
同时也是 图片防盗链 的原理
不是自己网站的的请求获取不到图片

2. 信息加密技术

1.单项散列加密

特点：
1. 不同长度 => 相同长度
2. 散列程度非常大
常见算法: MD5 SHA

2. 对称加密

加密解密一个密钥 => DES

3. 非对称加密

特点:
1.公开密钥 ＋ 私有密钥
2.一个加密 另外一个可以解密
应用场景:
1.信息安全传输
信息发送者(用户)通过 公开的(全世界都知道)的密钥 对明文进行加密 然后将密文传给 信息接收者(网站) 而只有接收者才有 私钥 所以只有接收者能看到明文的内容
2.数字签名
而数字签名与 安全传输 正好相反 发送者 用自己的 私钥 对明文的一小段进行加密然后随密文一起发送到服务器 因为私钥具有唯一性 所以能够标示用户的身份 具有签名的效用

4.密钥安全管理

密钥已明文的方式进行存储 不安全 下面是两种安全管理密钥的方式

1. 独立部署(服务器，硬件设备)，专人维护
2. 
   应用服务器提供 加解密接口
   密钥服务器提供 加解密服务
   多个密钥存储服务器 单独专人维护

3. 信息过滤与反垃圾

1.文本匹配
正则表达式 => 多级Hash
2.分类算法
朴素贝叶斯算法
3.黑名单
Hash表 => 布隆过滤器

4. 电子商务风险控制

通过设定某些规则，对用户受骗的风险进行控制
(例如，qq异地登录)