4. 瞬时响应：网站的高性能架构
4.1网站的性能测试
性能测试是性能优化的前提和基础，也是性能优化结果的检查和度量标准。
4.1.1不同视角下的网站性能
1.用户视角的网站性能
直观感受慢
手段:前端优化:优化html式样，浏览器并发和异步，缓存，cdn，反向代理，尽快显示感兴趣的数据。
2.开发人员视角的网站性能
关注:响应，吞吐量，并发能力，系统稳定性等技术指标。
手段:缓存（加速），集群（吞吐），异步（加速和削峰），代码优化
3.运维人员视角的网站性能
关注:基础设施性能和资源利用率。
4.1.2性能测试指标
开发和测试视角:响应时间，并发数，吞吐量，性能计数器。
1.响应时间
执行一个操作的总时间。
2.并发数
同时处理请求的数目。
3.吞吐量
单位时间内系统处理请求数量。
4.性能计数器
是描述服务器或操作系统性能的一些数据指标。system load.对象与线程数，内存使用，cpu使用，磁盘与i/o等指标。
4.1.3性能测试方法
性能测试是一个总称，包括性能测试，负载测试，压力测试，稳定性测试。
性能测试:
负载测试:加大并发请求，求峰值。
压力测试:施压到崩溃的境界最大承受能力
稳定性测试:不同环境，不同波动下运行一段时间，是否稳定。
性能测试:是一个不断对系统增加访问压力，以获得系统性能指标，最大负载能力，最大压力承受能力的过程。
4.1.4性能测试报告
4.1.5性能优化策略
1.性能分析
定位性能瓶颈位置
手段:检查各个环节日志，分析时间不合理的地方；然后检查监控数据，分析影响性能因素:内存，磁盘，网络，cpu，总结结果:代码问题，架构不合理，资源不够。
2.性能优化
web前端优化，应用服务器性能优化，存储服务器性能优化。
4.2web前端性能优化
4.2.1浏览器访问优化
1.减少http请求
原因:连接建立和线程数消耗资源
手段:合并css为一个文件，合并js，合并图片。
2.使用浏览器缓存
缓存静态文件。
改变文件名实在实时更新，逐步更新。
3.压缩
4.css放前面，js放页尾
原因:css全部加载完才渲染，js是立即执行，会阻塞页面渲染。
5.减少cookie传输
4.2.2cdn加速
物理位置分区缓存
4.2.3反向代理
代理服务器缓存，主要是静态内容。
4.3应用服务器性能优化
4.3.1分布式缓存
网站性能优化第一定律:优先考虑使用缓存优化性能。
1.缓存的基本原理
A:存储介质访问速度高；
B:数据是经过计算；
2/8原则，存储20%高频数据。
2.合理使用缓存
原因:滥用
不合理可能发生的地方:
频繁修改的数据
没有热点的访问
数据不一致与脏读
缓存可用性
缓存预热
缓存穿透
3.分布式缓存
4.3.2异步操作
消息队里缓存消息，提高生产者返回速率，减小消费者消费压力。
缺点:数据不实时
原则:任何可以晚点做的事情都可以应该晚点做。
4.3.3使用集群
提高吞吐量
4.3.4代码优化
1.多线程
启动线程数=[任务执行时间/（任务执行时间-io等待时间）]*cpu核数
线程安全:将对象设计为无状态，使用局部对象，加锁。
2.资源复用
原则:减少开销很大的资源的创建和销毁。
手段:单例和对象池。
3.数据结构
不同环境使用不同数据结构。
如:缓存用hashmap
4.垃圾回收
jvm调优
4.4存储性能优化
4.4.1机械硬盘vs固态硬盘
机械稳定快速顺序读，固态随机快
4.4.2B+树vs LSM树
4.4.3RAID vs HDFS
4.5小结
性能优化的目的:改善用户的体验。
5. 万无一失：网站的高可用架构
影响可用性的因素:DNS劫持，CDN服务挂掉，网站服务器宕机，交换机失效，硬盘损坏，网卡松动，停电，空调失灵，程序bug，黑客攻击，促销引发大流量，第三方不可用等等
5.1网站可用性的度量与考核
5.1.1网站可用性度量
n个9，如4个9既99.99%，一年最多53分钟不可用。
5.1.2网站可用性考核
5.2高可用的网站架构
原因:互联网使用廉价设备，故障是常态。
目的:高可用的目的就是保证服务器硬件故障时服务依然可用，数据依然保存并被访问。
手段:数据和服务冗余备份（集群，多机互备）以及失效转移（负载均衡）。
其他:同时考虑系统升级带来的宕机。
5.3高可用的应用
手段:无状态和集中式状态存储。
5.3.1通过负载均衡进行无状态服务的失效转移
5.3.2应用服务器集群的session管理
必须使用状态的应用使用集中式服务器管理session，让业务服务器仍然保持无状态。
手段:session复制
缺点:不易伸缩，网络消耗大，内存不足。
session绑定:同一ip路由到同一台服务器。缺点:服务器宕机，用户需要重新登录。
cookie记录session:cookie大小受限。
session服务器:有状态的sesioon服务器和无状态的应用服务器。
5.4高可用的服务
通用服务
高可用服务策略:
分级管理:高优先级使用好资源
超时设置:防止雪崩
异步调用:不重要的写操作，异步执行。
服务降级:不重要的服务在资源匮乏时拒绝服务或直接关闭。
幂等性设计:防止重发产生脏数据。
5.5高可用的数据
数据是公司核心资源。
手段:数据备份和失效转移。
5.5.1 CAP原理
高可用牺牲数据一致性。
高可用含义:
数据持久性:备份
数据可访问性:互备及转移
数据一致性:副本同步一致性。
三个特性无法同时满足。所以牺牲一致性。
一致性分为:
数据强一致:总是一致
数据用户一致:用户访问时通过纠错和检验机制保证返回用户一致。
数据最终一致:经过一段时间自我恢复和修正，数据最终达到一致。
选择:用户一致。
5.5.2 数据备份
目的:保证数据持久性和一致性
种类:冷备和热备。
热备:异步热备和同步热备。
5.5.3 失效转移
失效路由
步骤:失效确认，访问转移，数据恢复。
1.失效确认:手段:心跳检测和应用程序访问失败报告。
心跳检测:控制中心主动定时监测
访问失败报告:应用程序访问失败报告上传给控制中心。
2.访问转移
访问路由到其他机器
3.数据恢复
5.6 高可用网站的软件质量保证
5.6.1 网站发布
依次发布
5.6.2 自动化测试
回归测试，浏览器兼容测试。
自动化测试工具全面覆盖，并生成测试报告。
5.6.3 预发布验证
没加入正式环境负载均衡的生产机器，用于线上测试。
5.6.4 代码控制
1.主干开发，分支发布
2.分支开发，主干发布
5.6.5 自动化发布
5.6.6 灰度发布
发布部分服务器，开放给部分用户
5.7 网站运行监控
5.7.1 监控数据采集
1.用户行为日志收集
用户在浏览器上的所有操作及操作环境:操作系统，浏览器，ip，访问路径，页面停留时间。
目的:统计pv/uv，分析用户行为，优化网站设计，个性化营销与推荐。
手段:服务器端日志收集，浏览器日志收集。
服务器日志收集:简单但数据会失真（ip可能是代理ip）。
浏览器日志收集:js埋点，麻烦但准确。
2.服务器性能监控
目的:防范于未然，合理分配集群和改善性能。
指标:系统load，内存占用，磁盘io，网络io。
3.运行数据报告
相关技术或业务指标:缓存命中率，平均响应时间，每分钟发送邮件数，待处理任务总数。
5.7.2 监控管理
采集数据后进行后续应对策略。
系统报警:
采集的数据达到一定阀值通知报警。
失效转移:
自动路由转移。
自动优雅降级:
自动关闭部分低优先级服务。
5.8 小结
可用性关系网站的生死存亡。
6. 永无止境：网站的伸缩性架构
概念:不需要改变网站的软硬件设计，仅仅通过改变部署的服务器数量就可以扩大或缩小网站的服务处理能力。
6.1 网站架构的伸缩性设计
种类:
- 根据功能进行物理分离实现伸缩；（分布式）
- 通过集群实现伸缩。（集群）
6.1.1 不同功能进行物理分离实现伸缩
本质:分布式（水平切分，垂直分割）
6.1.2 单一功能通过集群规模实现伸缩
复制多台
6.2 应用服务器集群的伸缩性设计
条件:服务无状态，负载均衡
6.2.1 http重定向负载均衡
http服务器作为类域名服务器，获取真正的应用服务器ip，然后通过浏览器重定向到应用服务器。
优点:简单
缺点:重定向导致浏览器一次业务访问两次请求，性能低；http重定向服务器是瓶颈；降低搜索排名（浏览引擎认为作弊）。
与域名服务器差异:
6.2.2 DNS域名解析负载均衡
通过域名服务器获取真正的应用服务器ip。
优点:简单，瓶颈转嫁给运营商的服务器，域名可以根据地域分配就近应用服务器ip。
缺点:缓存较长，难以实时（特别是故障转移）。
6.2.3 反向代理负载均衡
原理:浏览器访问反向代理服务器，由反向代理服务器转发到隐藏在后面的真正应用服务器。
请求在http协议层，所以又叫应用层负载均衡。
优点:部署简单
缺点:流量瓶颈。
6.2.4 IP负载均衡
原理:浏览器发送请求到负载均衡服务器，负载均衡服务器不转发，而是直接修改目的地址为真实的ip和源ip.不经过用户进程处理。
与反向代理服务器对比:性能更高（内核层）
缺点:流量瓶颈
6.2.5 数据链路层负载均衡
数据链路层修改mac地址进行负载均衡。
原理:负载均衡服务器ip与应用服务器的ip配置相同，但mac地址不同，浏览器请求负载均衡服务器，然后修改数据包mac地址为真实应用服务器地址，数据包源ip任然是浏览器ip ，所以应用服务器返回数据不经过负载均衡服务器，直接返回给浏览器，负载均衡服务器只是上行单向通道。
优点:只做负载，不做返回转发，不再是流量瓶颈。
大型网站使用最广泛的负载均衡手段。
6.2.6 负载均衡算法
两阶段:
1.根据负载算法和应用服务器列表计算一台真实的应用服务器地址
2.请求转发到真实应用服务器。
种类:
1.轮询
原理:依次分发到每台应用服务器。
2.加权轮询
根据应用服务器性能情况，按提前配置单权重分发到应用服务器。
3.随机
随机分发。
4.最少连接
分发到当前请求最少的服务器。
5.源地址散列
根据请求ip，hash到具体应用服务器。
优点:同一浏览器机器每次分配到同一台应用服务器，可以保持状态。
缺点:低可用，一但这台应用服务器宕机，用户需要重新登录。
6.3 分布式缓存集群的伸缩性设计
应用服务器主要做计算，不保留状态，因此任何机器都是平等的，可以简单负载均衡。但是缓存服务器为数据存储，相当于有状态，除非每台缓存服务器数据都是实时相同。实际上，分布式缓存服务器数据各不相同。
目的:缓存服务器伸缩时对整个集群影响最少（伸缩不能让过多服务器负载失效）。
6.3.2 memcached
7. 随需应变：网站的可扩展架构
概念:对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力。开闭原则。
7.1 构建可扩展的网站架构
低耦合是软件设计终极目标。
架构师的最大价值:将一个大系统拆分成N个低耦合的子模块的能力（横向业务，纵向技术）。
设计网站可扩展架构的核心思想:模块化，并降低模块的耦合性和提高模块的复用性。
模块化手段:分层，分割
分布后的聚合方式:分布式消息和分布式服务。
7.2 利用分布式消息队列降低系统耦合性
7.2.1 事件驱动架构
概念:通过在低耦合的模块之间传输事件消息，以保持模块的松耦合，并借助事件消息的通信完成模块间的合作。
优点:松耦合（发布者和订阅者不一定知道对方的存在，数量不限），异步，缓存，调节速度不平衡。
7.2.2 分布式消息队列
activeMQ，rebbitMQ，rocketMQ, kafka
功能:消息传递，可用性，伸缩性，数据一致性，可管理。
伸缩性:新应用服务器加入消息队列即可。
可用性:消息队列可以持久化，可能支持集群，分片，副本等可用性特性。
7.3利用分布式服务打造可服用的业务平台
微服务化，细粒度服务以供重用，并通过接口通信。
单体应用缺点:
编译部署困难:慢
代码分支管理困难:一起开发，冲突严重。
数据库连接耗尽:大集群支撑大应用，每台消耗一定量连接，总共更多。
新增业务困难:代码网状交织，风格各不相同，相互耦合。
解决方案:横向拆分和纵向拆分，既微服务化。
7.3.1 Web Service 与企业级分布式服务
7.3.2 大型网站分布式服务的需求与特点
分布式框架需要支持以下特性:
负载均衡
失效转移
高效的远程通信:rpc
整合异构系统:
对应用最少入侵:
版本管理:服务提供者支持新老版本同时运行，使服务使用者平滑升级。
实时监控:使复杂的分布式调用方便快速定位问题。
7.3.3 分布式框架设计
facebook的thrift ，阿里的dubbo（多协议，nio），spring cloud（java 一站式全套解决方案） 。
7.4 可扩展的数据结构
nosql数据库，字段任意伸缩。
7.5 利用开放平台建设网站生态圈
他山之石可以攻玉。报团前进。
为第三方提供服务
API接口:暴露对外接口，RESTful，ws，PRC。
协议转换:入参转换（符合内部要求），返回值转换（符合对外要求）。
安全:身份认证，权限控制，流量限制，降级。
审计:监控，日志，计费。
路由:映射到具体内部服务。
流程:将一组离散的服务组织成一个上下文相关的新服务，隐藏服务细节，提供统一接口。既服务组装，适配器。
7.6 小结
不断试错，推陈出新，技术可以以最小代价快速响应业务变化-可扩展。
8. 固若金汤：网站的安全架构
8.1 道高一尺魔高一丈的网站应用攻击与防御
xss 与sql注入是最主要的手段。
csrf session劫持。
8.1.1 XSS攻击
概念:跨站点脚本攻击（Cross site script），指黑客通过篡改网页注入脚本，在用户浏览网页时，控制用户浏览器进行恶意操作的一种攻击方式。
反射型:诱使用户点击恶意脚本链接，达到恶意目的。
持久型:提交恶意脚本到应用服务器，寄生在真正的服务器上。
防御手段:消毒，httpOnly。
消毒:转义。
httpOnly:禁止js等脚本窃取cookie。
8.1.2 注入攻击
形式:sql和os注入。
sql注入:把sql片段以参数的方式提交到服务器，与真正的sql组成新的sql一起执行。
前提:了解数据库结构。
了解数据库结构的手段:
开源:开源软件库机构公开。
错误回显:通过猜测参数错误回显，猜测数据库结构。
盲注:网站关闭回显，攻击者根据页面变化判断sql执行情况。
预防手段:
避免猜测到库表结构。
消毒:转义，
参数绑定:sql参数化，占位符化。
8.1.3 CSRF 攻击
概念：CSRF(Cross site request forgery,跨站点请求伪造），攻击者通过跨站点请示，以合法用户的身份进行非法操作。
放预手段：
表单Token:
验证码：
Referer check:
8.1.4 其他攻击和漏洞
攻击漏洞利用：
error code:回显。
html注释：
文件上传：可执行文件。
路径遍历：
8.1.5 Web应用防火墙
通过防火墙一劳永逸解决上面的问题。
可用的开源产品如：ModSecurity
8.1.6 网站安全漏洞扫描
使用扫描工具检查。
8.2 信息加密技术及密钥安全管理
8.2.1 单向散列加密
ＭＤ5等散列摘要加密，防止数据泄露后密码公开。散列由于是不可逆的，即使数据泄露密码也是安全的。
不是绝对的：暴力破解（彩虹表－密码与散列值对照表），所以可以多加几次以及加盐等方式解决。
8.2.2 对称加密
概念：加密后可解密，且加解密密钥。
优点：算法简单
缺点：密码容易泄漏
8.2.3 非对称加密
概念：可密后可解密，但加密和解密用的是不同的密钥。
相当于：一个密码箱有前后两个门，同时有两把钥匙，一个用来锁一个用来开（都可以用来锁或开，但同一次只用来锁或开的一种，即：如果是用来锁，就只能用另一把开；如果另一把用来锁，第一把只能用来开）
特点：单向安全。
过程：客户端（如：浏览器）向服务器发送加密请求，并发送自己的公钥，此时是不安全的；服务器发送自己的公钥给客户。浏览器使用服务器的公钥加密一个对称加密的密钥（相当于密码：如123456)，发给服务器（此时单向安全：因为只有服务器有私钥可以打开，服务器的公开加密的数据，再用公钥是打不开的）。以后服务器与浏览器就可以使用对接密钥加密信道。
上面只是简单的过程，其中还会涉及中间服务器伪造，数字签名等问题。
8.2.4 密钥安全管理
无论哪种加密算法或解决方案，最终都必须密钥的参与（相于当密码的管理）。那么最终都必须保证密钥的安全：不能直接放到代码中等大家很容易获取到的位置。
手段：
Ａ：密钥和算法放在独立的服务器。
加解密通过这个服务器提供的接口实现，减少密钥公开的范围。
Ｂ：加密算法放在应用服务器，密钥放在独立服务器。
即：密钥只做为一个配置中心，应用启动时一次加载即可。
8.3 信息过滤与反垃圾
手段：
8.3.1 文本匹配
正则表达式（效率低）
trie算法
多级hash表过滤树
8.3.2 分类算法
8.3.3 黑名单
8.4 电子商务风险控制
主要指业务风险。
8.4.1 风险
账户风险：被黑被盗、恶意注册。
买家风险：恶意下单、退货。
卖家风险：恶意欺诈。
交易风险：盗刷卡、洗钱。
8.4.2 风控
Ａ：规则引擎：规则
Ｂ：统计模型：AI
8.5 小结
目标：让攻击者的代价远远高于得到利益。