大型网站技术架构
第一章 大型网站架构演化
大型网站软件系统的特点:
1.高并发，大流量
2.高可用
3.海量数据
4.用户分布广泛，网络情况复杂
5.安全环境恶劣
6.需求快速变更，发布频繁
7.渐进式发展
大型网站架构演化发展历程
1.初始阶段
一个物理机器，应用程序，数据库和文件放在一个机器上
2.应用服务和数据服务分离
根据对CPU，磁盘内存的需求不同分为 应用服务器机器，文件服务器，数据库服务器
3.使用缓存改善网站性能
用于缓解数据库压力，缓存分两种:
a.直接缓存在本地机器上，这样速度快，但是容量有限
b.远程分布式缓存集群，理论上可以无限扩展
4.使用应用服务器集群改善并发处理能力
部署多台应用服务器，提高并发能力。也可以在应用服务器上加一些本地缓存
5.数据读写分离
主库负责更新删除操作，从库负责读操作
6.使用反向代理和CDN加速网站响应
部署CDN让用户访问离自己最近的数据，再部署反向代理，如果反向代理中有缓存则直接返回
7.分布式文件系统和数据库
数据库压力很大，将单表拆分部署到不同的物理机器上
8.使用NoSql和搜索引擎
继续减轻数据库的压力
9.业务拆分
将一个网站拆分成不同的应用，每个应用独立部署，应用之间通过超链接建立关系，也可以通过
消息队列进行数据分发
10.分布式服务
业务拆分越多，之间逻辑调用关系就越复杂，将一些可以复用的业务单独部署，然后通过分布式
服务调用共同的业务完成具体操作
基本上到了第十点，所有的技术问题都可以解决了
大型网站技术的核心价值是随网站所需灵活应对
驱动大型网站技术发展的主要力量是网站的业务发展
网站架构设计误区
1.一味追求大公司的解决方案
2.为了技术而技术
3.企图用技术解决所有问题
12306就是这样，根本问题并不是技术，不管技术做到多好，秒杀最终会导致很多人买不到票
第二章 大型网站架构模式
1.分层
应用层，服务层，数据层
2.分隔
3.分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
4.集群
5.缓存
反向代理
本地缓存
分布式缓存
6.异步
提高系统可用性
加速网站响应速度
消除并发访问高峰
7.冗余
数据冷备，数据热备
8.自动化
自动化测试
自动化代码管理
发布过程自动化
自动化安全检查
自动化报警
自动化失效转移
自动化降级
自动化失效恢复
9.安全
第三章 大型网站核心架构要素
1.性能
2.可用性
3.伸缩性
4.扩展性
5.安全性
第四章 网站的高性能架构
网站性能测试
1.用户视角的网站性能
2.开发人员视角的网站性能
主要是响应延迟，系统吞吐量，并发处理能力，系统稳定性等
3.运维人员视角的网站性能
网络运行商的带宽能力，服务器硬件配置，数据中心网络架构，服务器和网络带宽利用率
性能测试指标
1.响应时间
2.并发数
3.吞吐量
TPS(每秒查询数)，QPS(每秒事务数)
4.性能计数器
性能测试方法
1.性能测试
对系统不断施加压力，验证系统再资源可接受范围内，是否能达到性能指标
2.负载测试
对系统不断地增加请求，直到达到某项或多项性能指标的安全临界值
3.压力测试
超过安全负载的情况下，继续施加压力，直接奔溃或不能再处理任何请求，获得系统最大承受能力
4.稳定性测试
系统在特定的硬件，软件，网络环境下，加载一定的业务压力，使系统运行一段较长时间，以测试
系统是否稳定
Web前端性能优化
1.减少HTTP请求
合并JS,合并CSS，合并图片
2.使用浏览器缓存
3.启用压缩
4.CSS放在页面最上面，JS放在页面最下面
CSS全部下载完之后才会渲染，而JS会加载后立即执行
5.减少Cookie传输
6.CDN加速
7.反向代理
反向代理也有负载均衡功能，还可以缓存一些数据，也起到了保护网站安全的作用
应用服务器性能优化
1.分布式缓存
网站优化第一定律:有限考虑使用缓存优化性能
2.合理使用缓存
频繁修改的数据
没有热点的访问
数据不一致与脏读
缓存可用性(当缓存宕机时数据库无法承受巨大压力)
缓存预热
缓存穿透
3.分布式缓存架构
JBoss cache:需要同步更新的缓存
memcache互不通讯的缓存
4.异步操作
5.使用集群
代码优化
多线程
资源复用
数据结构
垃圾回收
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
RAID0:将数据分成N份读取，速度大大提高，但是坏掉一块盘数据完整性就被破坏
RAID1:一次写入两块盘，具有极高的可靠性
RAID3:数据并发写入到N-1块盘，校验数据写入第N块盘
RAID5:类似RAID3，但是校验数据螺旋的写入到所有磁盘中
RAID6:数据写入N-2块盘，校验信息螺旋写入剩下两块盘
RAID10:将所有磁盘分成两份，相当于RAID1，但是每一份磁盘的N/2块磁盘上，利用RAID0的技术并发读写，即提高可靠性又改善性能
第五章 网站的高可用架构
网站的可靠性:
网站年度可用性指标 = (1-网站不可用时间/年度总时间)*100%
99% 基本可靠，不可用时间小于88个小时
99.9% 较高可用，年度不可用时间小于9小时
99.99% 具有自动回复能力的高可用，不可用时间小于53分钟
99.999% 极高可用性，不可用时间小于5分钟
网站故障分类权重表示
事故级故障 严重故障，网站整体不可用 100
A类故障 网站访问不顺畅或核心功能不可用 20
B类故障 非核心功能不可用，或者核心功能少数用户不可用 5
C类故障 以上故障以外的其他故障 1
故障分的计算公式:
故障分 = 故障时间(分钟) * 故障权重
这会很大的影响年度绩效考核
高可用的应用:
1.通过负载均衡进行无状态服务的失效转移
2.应用服务集群的session管理
session复制
session绑定
利用cookie记录session
session服务器
高可用的服务:
1.分级管理(核心模块，非核心模块)
2.超时设置
3.异步调用
4.服务降级
5.冥等性设计
服务失败后，会将请求重新发给其他服务器
高可用数据
1.CAP原理
一个提供数据服务的存储系统无法同时满足:
一致性(Consistency)
数据可用性(Availibility)
分区耐受性(Patition Toerance 系统具有跨网络的伸缩性)
数据一致性又分:
强一致性
数据用户一致性(在各个副本不一致，但终端访问时通过校验机制保证一致性)
最终一致性(经过一个较短的时间之后数据达到一致)
2.数据备份
冷备，热备
热备包括:
同步热备份
异步热备份
3.失效转移
失效确认
访问转移
数据恢复
高可用的软件质量保证
1.自动化测试
2.预发布验证
跟线上环境一样，只是根据LB调度策略，用户无法访问
3.代码控制
主干开发，分支发布(类似apache这样的)
分支开发，主干发布(git)
4.自动化发布
周四发布，这样有三天准备，还有一天可以挽回
5.灰度发布
网站运行监控
1.监控数据采集
用户行为日志收集
服务器端日志，客户端浏览器日志收集
服务器性能监控
运行数据报告
2.监控管理
系统报警
失效转移
自动优雅降级
第六章 网站的伸缩性架构
网站架构的伸缩性设计
不同功能进行物理分离实现伸缩
单一服务器处理所有请求-->数据库从应用服务器分离-->缓存从应用服务器分离-->静态资源分离
横向分离
网站前台，卖家后台，买家后台，交易论坛
当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车
应用服务器集群的伸缩性设计
1.HTTP重定向负载均衡
2.DNS域名解析负载均衡
3.反向代理负载均衡
4.IP负载均衡
5.数据链路负载均衡(LVS，三角传输，即Web服务器直接将数据返回给客户端)
6.负载均衡算法
轮询(Round Robin RR)
加权均衡(Weighted Round Robin WRR)
随即(Random)
最少连接(Least Connections)
源地址散列(Source Hashing)
分布式缓存集群的伸缩设计
1.Memchacd分布式缓存集群
2.分布式缓存一致性Hash算法
数据存储服务器集群的伸缩性设计
1.关系型数据库集群的伸缩性设计
2.NoSql数据库的伸缩性设计 HBase
一个100W用户的网站，不会遇到1亿用户同时在线的问题
一个拥有100W件商品的网站，无法理解一个拥有10亿件商品网站的架构
第七章 网站的可扩展架构
扩展性:对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力
伸缩性:系统能够通过增加(减少)自身资源规模的方式增加(减少)自己计算处理事务的能力
利用分布式消息队列降低系统耦合性
1.事件驱动架构
发布/订阅模型
2.分布式消息队列
利用分布式服务打造可复用的业务平台
将业务柴发，部署为独立的模块，降低系统耦合度
纵向拆分:将一个大应用拆分为多个小应用
横向拆分:将一个复杂的业务拆分出来，独立部署为分布式服务
WebService虽然有成熟的技术规范和产品实现，但是缺点如下:
1.臃肿的注册和发现机制
2.低效的XML序列化手段
3.开销相对较高的HTTP远程通讯
4.复杂的部署和维护手段
大型网站分布式服务器的需求和特点:
1.负载均衡
2.失效转移
3.高效的远程通讯
4.整合异构系统
5.对应用最少侵入
6.版本管理
7.实时监控
可扩展的数据结构
类似Nosq(HBase)这样的表设计
利用开放平台建立网站生态圈
API接口:提供给开发者的一组API，以RESTful或者WebService，RPC等形式
协议转换:将API输入为内部服务可识别的形式
安全:身份识别，权限控制等手段，还需要分级的带宽访问权限
审计:记录第三方应用访问情况
路由:将开放平台的各种访问路由映射到具体的内部服务商
流程:将一组离散的服务组织成一个上下文相关的新服务，隐藏服务的细节，提供统一接口给开发者
第八章 网站的安全架构
网站应用攻击与防御
1.XSS攻击(Cross Site Script)跨站点脚本攻击
反射型:攻击者诱使用户点击一个嵌入恶意脚本的链接(只发布一个URL，但是内容在自己机器上)
持久性:提交恶意脚本到数据中，如论坛，博客
解决办法:
消毒(也就是HTML过滤)
HttpOnly(浏览器禁止页面JS访问带有HttpOnly属性的Cookie)
2.注入攻击
SQL注入和OS注入攻击
有如下几种手段:
开源的应用，数据库结构都是公开的
错误回显
盲注(猜测数据库表结构)
消毒
参数绑定
3.CSRF攻击(Cross Site Request Forgery)跨站点请求伪造
以合法用户的身份进行非法操作
防御手段如下:
单表Token
验证码
Referer check
4.其他攻击和漏洞
ErrorCode
显示出内部服务器的一些信息
HTML注释
文件上传
路径遍历
如xx/../.. 这种方式
5.Web应用防火墙
ModSecurity，读取攻击规则集合判断是否合法请求
6.网站安全漏洞扫描
信息加密及秘钥管理
1.单向散列加密
MD5，SHA等
2.对称加密
DES，RC等
3.非对称加密
RSA，椭圆曲线加密算法等
4.秘钥管理
把秘钥和算法放在一个独立的服务器上(甚至做成专门硬件)对外提供服务，应用系统通过这个服务
实现数据的加密和解密，但这样性能不好
将加密算法放在应用系统中，秘钥则放在独立服务器中，为了提高秘钥的安全性，实际存储时，
秘钥被切分成数片，密码后分别保存在不同数据介质中，兼顾安全又改善性能s
信息过滤与反垃圾
1.文本匹配
基本上都是Trie树的变种，还有空间时间都比较好的双数组Trie算法
2.分类算法
贝叶斯算法
3.黑名单
布隆过滤器
电子商务风险控制
1.风险
账户风险，买家风险，卖家风险，交易风险
2.风控
规则引擎，由运营人员通过界面编辑
统计模型
根据历史数据训练算法
第九章 淘宝网的架构演化案列分析
2003年花3000美元买来的PHP开发的网站修改后做成了淘宝
最初也是LAMP架构的
2004年在SUN的协助下慢慢开始转为java，有自己的MVC框架，自动测试和打包工具
使用IOE解决方案
放弃EJB，采用spring
使用免费的JBoss替代weblogic
最后开始用免费的开源产品替代IOE，并开发自己的产品并开源
第十章 维基百科的高性能构架分析
维基百科只有几百台服务器，十余名技术人员
维基百科架构的主要组成部分:
GeoDNS:开源域名服务器BIND的增强版本
LVS，Squid(反向代理)，Lighttped
PHP，Memcached
Lucene，MySql
Wikipedia前端性能优化
维基百科80%以上的用户访问都可以通过前端返回，请求根本不会达到应用服务器，所以网站的
最复杂最有挑战的存储压力骤减
使用CDN，加上Squid缓存
维基百科CDN缓存的几条准则:
内容页面不包含动态信息，以免页面内容缓存很快失效或者包含过时信息
每个内容页面有唯一的REST风格的URL，以便CDN快速查找并避免重复缓存
在HTML响应头写入缓存控制信息，通过应用控制内容是否缓存及缓存有效期等
Wikipedia服务端性能优化
使用APC，这个是一个PHP字节码缓存模块
使用Imagemagick进行图片处理和转化
使用Tex进行文本格式化，特别是将科学公式内容转化成图片格式
替换PHP的字符串查找函数strtr()，使用优化的算法重构
Wikipedia后端性能优化
热点特别集中的数据直接缓存到应用服务器的本地内存中
缓存数据的内容尽量是应用服务器可以直接使用的格式，如HTML格式
使用缓存服务器存储session对象
相比数据库，memcached的持久化连接非常廉价，如有需要就创建一个memcached连接
使用较大的服务器内存，在Wikipedia场景中，增加内存比增加其他资源更能改善MySql性能
使用RAID0磁盘阵列加速磁盘访问(Wikipedia认为性能更重要，可靠性通过其他手段解决)
将数据库事务一致性设置在较低水平，加快宕机恢复速度
如果master数据库宕机，应将应用切换到salve数据库，同事关闭数据库写服务
第十一章 海量分布式存储系统Doris的高可用架构设计分析
这是一个KV存储系统
第十二章 网购叫啥系统架构设计案例分析
秒杀活动的技术挑战
1.对现有网站业务造成冲击
2.高并发下的应用，数据库负载
3.突然增加的网络及服务器带宽
4.直接下单
秒杀系统的应对策略
1.秒杀系统独立部署，使用独立域名
2.秒杀商品页面静态化
3.租借秒杀活动网络带宽
4.动态生成随即下单页面URL
秒杀系统架构设计
1.如何控制秒杀商品页面购买按钮的点亮
在静态页面中加入一个JS文件，这个文件不被CDN和浏览器缓存，每次刷新都会加载这个文件
2.如何只允许第一个提交的订单被发送到订单子系统
控制进入下单页面的入口，只有少数用户能进入下单页面
第十三章 大型网站典型故障案例分析
1.写日志引发的故障
应用服务器磁盘都很小，但是将日志级别配置成debug，导致磁盘空间很快被消耗完
应用程序自己的日志输出配置和第三方组件日志输出要分别配置
日志输出级别至少为warn
有些开源的第三方工具也会输出太多的error日志
2.高并发访问数据库引发的故障
网站首页应用调用触发了这个sql
首页不应该访问数据库，应该从缓存服务器或者搜索引擎服务器获取
首页最好静态化
3.高并发情况下锁引发的故障
某个服务器不定期的超时，反反复复
因为单列对象多出使用了同步导致的，所以使用锁要谨慎
4.缓存引发的故障
数据库load突然飙升，切换到备用机也是load飙升最终瘫痪
这是因为不正确的关闭了大量缓存服务器导致的
当缓存已不再是改善性能而是网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别
5.应用启动不同步引发的故障
某应用发布后服务器立即奔溃
应用服务器启动还没启动完，前段代理服务器早就启动好了，导致大量请求阻塞在应用服务器队列中
6.大文件读写独占磁盘引发的故障
上传图片突然非常慢
原因是有几个图片非常大，有几百M，导致磁盘读取都被这个文件占用了
存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专门的存储服务器，不能和大文件公用存储，批量处理大文件可以使用其他的分布式文件系统
7.滥用生成环境引发的故障
某个时间段内某些应用突然变慢，内部网络访问延迟非常大
原因是有人在生产环境做性能压力测试
访问线上生成环境要规范
8.不规范的流程引发的故障
某应用发布后数据库load飙升，回滚代码后又恢复正常
原因是发布代码时访问缓存的那段代码被特意注释掉了
提交代码前要小心做diff
9.不好的编程习惯引发的故障
某应用更新某功能后，有少量用户反映无法正常使用该功能
原因是这些人第一次使用该功能，而代码是根据历史记录构造的对象，导致了null
程序处理第一个输入对象时，如果不能明确该对象是否为空，必须做空指针判断
程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象
第十四章 架构师领导艺术
关注人而不是产品
一群优秀的人做一件他们热爱的事，一定能取得成功
寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围
发掘人的优秀
是事情成就了人，而不是人成就了事
共享美好蓝图
蓝图应该是表述清楚的
蓝图应该是形象的
蓝图应该是简单的
共同参与架构
不要只有架构师一个人拥有架构
让其他人维护框架与架构文档
学会妥协
不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要
企图去证明自己了不起。
成就他人
想要成就自己，就必须首先成就他人
第十五章 架构师职场攻略
把"我的问题"表述称"我们的问题"
给上司提封闭式问题，给下属提开放式问题
指出问题而不是批评人
用赞同的方式提出问题
在解决我的问题之前，先解决你的问题
适当的逃避问题
有的人提出不靠谱的问题，先不用说不行会挫伤积极性，等他经过一段时间会意识到不可行
第十六章 漫话网站架构师
按作用分
设计型架构师
救火型架构师
布道型架构师
Geek型架构师
按效果划分架构师
按职责角色划分架构师
按关注层次划分架构师
按口碑划分架构师
非主流方式划分架构师
附录A 大型网站架构技术一览
1.前端架构
浏览器技术优化(页面缓存，合并HTTP请求数，页面压缩)
CDN
动静分离，静态资源独立部署
图片服务
反向代理
DNS
2.应用层架构
开发框架
页面渲染
负载均衡
session管理
动态页面静态化
业务拆分
虚拟化服务
3.服务层架构
分布式消息
分布式服务
分布式缓存
分布式配置
4.存储层架构
分布式文件
关系型数据库
NoSql数据库
数据同步
5.后台架构
搜索引擎
数据仓库
推荐系统
6.数据采集与健康
浏览器数据采集
服务器业务数据采集
服务器性能数据采集
系统监控
系统报警
7.安全架构
web攻击
数据保护
8.数据中心机房架构
机房架构(数据中心地理位置应该供电便宜充足，散热好)
机柜架构
服务器架构
大型网站软件系统的特点:
1.高并发，大流量
2.高可用
3.海量数据
4.用户分布广泛，网络情况复杂
5.安全环境恶劣
6.需求快速变更，发布频繁
7.渐进式发展
大型网站架构演化发展历程
1.初始阶段
一个物理机器，应用程序，数据库和文件放在一个机器上
2.应用服务和数据服务分离
根据对CPU，磁盘内存的需求不同分为 应用服务器机器，文件服务器，数据库服务器
3.使用缓存改善网站性能
用于缓解数据库压力，缓存分两种:
a.直接缓存在本地机器上，这样速度快，但是容量有限
b.远程分布式缓存集群，理论上可以无限扩展
4.使用应用服务器集群改善并发处理能力
部署多台应用服务器，提高并发能力。也可以在应用服务器上加一些本地缓存
5.数据读写分离
主库负责更新删除操作，从库负责读操作
6.使用反向代理和CDN加速网站响应
部署CDN让用户访问离自己最近的数据，再部署反向代理，如果反向代理中有缓存则直接返回
7.分布式文件系统和数据库
数据库压力很大，将单表拆分部署到不同的物理机器上
8.使用NoSql和搜索引擎
继续减轻数据库的压力
9.业务拆分
将一个网站拆分成不同的应用，每个应用独立部署，应用之间通过超链接建立关系，也可以通过
消息队列进行数据分发
10.分布式服务
业务拆分越多，之间逻辑调用关系就越复杂，将一些可以复用的业务单独部署，然后通过分布式
服务调用共同的业务完成具体操作
基本上到了第十点，所有的技术问题都可以解决了
大型网站技术的核心价值是随网站所需灵活应对
驱动大型网站技术发展的主要力量是网站的业务发展
网站架构设计误区
1.一味追求大公司的解决方案
2.为了技术而技术
3.企图用技术解决所有问题
12306就是这样，根本问题并不是技术，不管技术做到多好，秒杀最终会导致很多人买不到票
第二章 大型网站架构模式
1.分层
应用层，服务层，数据层
2.分隔
3.分布式
分布式应用和服务
分布式静态资源
分布式数据和存储
分布式计算
4.集群
5.缓存
反向代理
本地缓存
分布式缓存
6.异步
提高系统可用性
加速网站响应速度
消除并发访问高峰
7.冗余
数据冷备，数据热备
8.自动化
自动化测试
自动化代码管理
发布过程自动化
自动化安全检查
自动化报警
自动化失效转移
自动化降级
自动化失效恢复
9.安全
第三章 大型网站核心架构要素
1.性能
2.可用性
3.伸缩性
4.扩展性
5.安全性
第四章 网站的高性能架构
网站性能测试
1.用户视角的网站性能
2.开发人员视角的网站性能
主要是响应延迟，系统吞吐量，并发处理能力，系统稳定性等
3.运维人员视角的网站性能
网络运行商的带宽能力，服务器硬件配置，数据中心网络架构，服务器和网络带宽利用率
性能测试指标
1.响应时间
2.并发数
3.吞吐量
TPS(每秒查询数)，QPS(每秒事务数)
4.性能计数器
性能测试方法
1.性能测试
对系统不断施加压力，验证系统再资源可接受范围内，是否能达到性能指标
2.负载测试
对系统不断地增加请求，直到达到某项或多项性能指标的安全临界值
3.压力测试
超过安全负载的情况下，继续施加压力，直接奔溃或不能再处理任何请求，获得系统最大承受能力
4.稳定性测试
系统在特定的硬件，软件，网络环境下，加载一定的业务压力，使系统运行一段较长时间，以测试
系统是否稳定
Web前端性能优化
1.减少HTTP请求
合并JS,合并CSS，合并图片
2.使用浏览器缓存
3.启用压缩
4.CSS放在页面最上面，JS放在页面最下面
CSS全部下载完之后才会渲染，而JS会加载后立即执行
5.减少Cookie传输
6.CDN加速
7.反向代理
反向代理也有负载均衡功能，还可以缓存一些数据，也起到了保护网站安全的作用
应用服务器性能优化
1.分布式缓存
网站优化第一定律:有限考虑使用缓存优化性能
2.合理使用缓存
频繁修改的数据
没有热点的访问
数据不一致与脏读
缓存可用性(当缓存宕机时数据库无法承受巨大压力)
缓存预热
缓存穿透
3.分布式缓存架构
JBoss cache:需要同步更新的缓存
memcache互不通讯的缓存
4.异步操作
5.使用集群
代码优化
多线程
资源复用
数据结构
垃圾回收
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
RAID0:将数据分成N份读取，速度大大提高，但是坏掉一块盘数据完整性就被破坏
RAID1:一次写入两块盘，具有极高的可靠性
RAID3:数据并发写入到N-1块盘，校验数据写入第N块盘
RAID5:类似RAID3，但是校验数据螺旋的写入到所有磁盘中
RAID6:数据写入N-2块盘，校验信息螺旋写入剩下两块盘
RAID10:将所有磁盘分成两份，相当于RAID1，但是每一份磁盘的N/2块磁盘上，利用RAID0的技术并发读写，即提高可靠性又改善性能
第五章 网站的高可用架构
网站的可靠性:
网站年度可用性指标 = (1-网站不可用时间/年度总时间)*100%
99% 基本可靠，不可用时间小于88个小时
99.9% 较高可用，年度不可用时间小于9小时
99.99% 具有自动回复能力的高可用，不可用时间小于53分钟
99.999% 极高可用性，不可用时间小于5分钟
网站故障分类权重表示
事故级故障 严重故障，网站整体不可用 100
A类故障 网站访问不顺畅或核心功能不可用 20
B类故障 非核心功能不可用，或者核心功能少数用户不可用 5
C类故障 以上故障以外的其他故障 1
故障分的计算公式:
故障分 = 故障时间(分钟) * 故障权重
这会很大的影响年度绩效考核
高可用的应用:
1.通过负载均衡进行无状态服务的失效转移
2.应用服务集群的session管理
session复制
session绑定
利用cookie记录session
session服务器
高可用的服务:
1.分级管理(核心模块，非核心模块)
2.超时设置
3.异步调用
4.服务降级
5.冥等性设计
服务失败后，会将请求重新发给其他服务器
高可用数据
1.CAP原理
一个提供数据服务的存储系统无法同时满足:
一致性(Consistency)
数据可用性(Availibility)
分区耐受性(Patition Toerance 系统具有跨网络的伸缩性)
数据一致性又分:
强一致性
数据用户一致性(在各个副本不一致，但终端访问时通过校验机制保证一致性)
最终一致性(经过一个较短的时间之后数据达到一致)
2.数据备份
冷备，热备
热备包括:
同步热备份
异步热备份
3.失效转移
失效确认
访问转移
数据恢复
高可用的软件质量保证
1.自动化测试
2.预发布验证
跟线上环境一样，只是根据LB调度策略，用户无法访问
3.代码控制
主干开发，分支发布(类似apache这样的)
分支开发，主干发布(git)
4.自动化发布
周四发布，这样有三天准备，还有一天可以挽回
5.灰度发布
网站运行监控
1.监控数据采集
用户行为日志收集
服务器端日志，客户端浏览器日志收集
服务器性能监控
运行数据报告
2.监控管理
系统报警
失效转移
自动优雅降级
第六章 网站的伸缩性架构
网站架构的伸缩性设计
不同功能进行物理分离实现伸缩
单一服务器处理所有请求-->数据库从应用服务器分离-->缓存从应用服务器分离-->静态资源分离
横向分离
网站前台，卖家后台，买家后台，交易论坛
当一头牛拉不动车的时候，不要去寻找一头更强壮的牛，而是用两头牛来拉车
应用服务器集群的伸缩性设计
1.HTTP重定向负载均衡
2.DNS域名解析负载均衡
3.反向代理负载均衡
4.IP负载均衡
5.数据链路负载均衡(LVS，三角传输，即Web服务器直接将数据返回给客户端)
6.负载均衡算法
轮询(Round Robin RR)
加权均衡(Weighted Round Robin WRR)
随即(Random)
最少连接(Least Connections)
源地址散列(Source Hashing)
分布式缓存集群的伸缩设计
1.Memchacd分布式缓存集群
2.分布式缓存一致性Hash算法
数据存储服务器集群的伸缩性设计
1.关系型数据库集群的伸缩性设计
2.NoSql数据库的伸缩性设计 HBase
一个100W用户的网站，不会遇到1亿用户同时在线的问题
一个拥有100W件商品的网站，无法理解一个拥有10亿件商品网站的架构
第七章 网站的可扩展架构
扩展性:对现有系统影响最小的情况下，系统功能可持续扩展或提升的能力
伸缩性:系统能够通过增加(减少)自身资源规模的方式增加(减少)自己计算处理事务的能力
利用分布式消息队列降低系统耦合性
1.事件驱动架构
发布/订阅模型
2.分布式消息队列
利用分布式服务打造可复用的业务平台
将业务柴发，部署为独立的模块，降低系统耦合度
纵向拆分:将一个大应用拆分为多个小应用
横向拆分:将一个复杂的业务拆分出来，独立部署为分布式服务
WebService虽然有成熟的技术规范和产品实现，但是缺点如下:
1.臃肿的注册和发现机制
2.低效的XML序列化手段
3.开销相对较高的HTTP远程通讯
4.复杂的部署和维护手段
大型网站分布式服务器的需求和特点:
1.负载均衡
2.失效转移
3.高效的远程通讯
4.整合异构系统
5.对应用最少侵入
6.版本管理
7.实时监控
可扩展的数据结构
类似Nosq(HBase)这样的表设计
利用开放平台建立网站生态圈
API接口:提供给开发者的一组API，以RESTful或者WebService，RPC等形式
协议转换:将API输入为内部服务可识别的形式
安全:身份识别，权限控制等手段，还需要分级的带宽访问权限
审计:记录第三方应用访问情况
路由:将开放平台的各种访问路由映射到具体的内部服务商
流程:将一组离散的服务组织成一个上下文相关的新服务，隐藏服务的细节，提供统一接口给开发者
第八章 网站的安全架构
网站应用攻击与防御
1.XSS攻击(Cross Site Script)跨站点脚本攻击
反射型:攻击者诱使用户点击一个嵌入恶意脚本的链接(只发布一个URL，但是内容在自己机器上)
持久性:提交恶意脚本到数据中，如论坛，博客
解决办法:
消毒(也就是HTML过滤)
HttpOnly(浏览器禁止页面JS访问带有HttpOnly属性的Cookie)
2.注入攻击
SQL注入和OS注入攻击
有如下几种手段:
开源的应用，数据库结构都是公开的
错误回显
盲注(猜测数据库表结构)
消毒
参数绑定
3.CSRF攻击(Cross Site Request Forgery)跨站点请求伪造
以合法用户的身份进行非法操作
防御手段如下:
单表Token
验证码
Referer check
4.其他攻击和漏洞
ErrorCode
显示出内部服务器的一些信息
HTML注释
文件上传
路径遍历
如xx/../.. 这种方式
5.Web应用防火墙
ModSecurity，读取攻击规则集合判断是否合法请求
6.网站安全漏洞扫描
信息加密及秘钥管理
1.单向散列加密
MD5，SHA等
2.对称加密
DES，RC等
3.非对称加密
RSA，椭圆曲线加密算法等
4.秘钥管理
把秘钥和算法放在一个独立的服务器上(甚至做成专门硬件)对外提供服务，应用系统通过这个服务
实现数据的加密和解密，但这样性能不好
将加密算法放在应用系统中，秘钥则放在独立服务器中，为了提高秘钥的安全性，实际存储时，
秘钥被切分成数片，密码后分别保存在不同数据介质中，兼顾安全又改善性能s
信息过滤与反垃圾
1.文本匹配
基本上都是Trie树的变种，还有空间时间都比较好的双数组Trie算法
2.分类算法
贝叶斯算法
3.黑名单
布隆过滤器
电子商务风险控制
1.风险
账户风险，买家风险，卖家风险，交易风险
2.风控
规则引擎，由运营人员通过界面编辑
统计模型
根据历史数据训练算法
第九章 淘宝网的架构演化案列分析
2003年花3000美元买来的PHP开发的网站修改后做成了淘宝
最初也是LAMP架构的
2004年在SUN的协助下慢慢开始转为java，有自己的MVC框架，自动测试和打包工具
使用IOE解决方案
放弃EJB，采用spring
使用免费的JBoss替代weblogic
最后开始用免费的开源产品替代IOE，并开发自己的产品并开源
第十章 维基百科的高性能构架分析
维基百科只有几百台服务器，十余名技术人员
维基百科架构的主要组成部分:
GeoDNS:开源域名服务器BIND的增强版本
LVS，Squid(反向代理)，Lighttped
PHP，Memcached
Lucene，MySql
Wikipedia前端性能优化
维基百科80%以上的用户访问都可以通过前端返回，请求根本不会达到应用服务器，所以网站的
最复杂最有挑战的存储压力骤减
使用CDN，加上Squid缓存
维基百科CDN缓存的几条准则:
内容页面不包含动态信息，以免页面内容缓存很快失效或者包含过时信息
每个内容页面有唯一的REST风格的URL，以便CDN快速查找并避免重复缓存
在HTML响应头写入缓存控制信息，通过应用控制内容是否缓存及缓存有效期等
Wikipedia服务端性能优化
使用APC，这个是一个PHP字节码缓存模块
使用Imagemagick进行图片处理和转化
使用Tex进行文本格式化，特别是将科学公式内容转化成图片格式
替换PHP的字符串查找函数strtr()，使用优化的算法重构
Wikipedia后端性能优化
热点特别集中的数据直接缓存到应用服务器的本地内存中
缓存数据的内容尽量是应用服务器可以直接使用的格式，如HTML格式
使用缓存服务器存储session对象
相比数据库，memcached的持久化连接非常廉价，如有需要就创建一个memcached连接
使用较大的服务器内存，在Wikipedia场景中，增加内存比增加其他资源更能改善MySql性能
使用RAID0磁盘阵列加速磁盘访问(Wikipedia认为性能更重要，可靠性通过其他手段解决)
将数据库事务一致性设置在较低水平，加快宕机恢复速度
如果master数据库宕机，应将应用切换到salve数据库，同事关闭数据库写服务
第十一章 海量分布式存储系统Doris的高可用架构设计分析
这是一个KV存储系统
第十二章 网购叫啥系统架构设计案例分析
秒杀活动的技术挑战
1.对现有网站业务造成冲击
2.高并发下的应用，数据库负载
3.突然增加的网络及服务器带宽
4.直接下单
秒杀系统的应对策略
1.秒杀系统独立部署，使用独立域名
2.秒杀商品页面静态化
3.租借秒杀活动网络带宽
4.动态生成随即下单页面URL
秒杀系统架构设计
1.如何控制秒杀商品页面购买按钮的点亮
在静态页面中加入一个JS文件，这个文件不被CDN和浏览器缓存，每次刷新都会加载这个文件
2.如何只允许第一个提交的订单被发送到订单子系统
控制进入下单页面的入口，只有少数用户能进入下单页面
第十三章 大型网站典型故障案例分析
1.写日志引发的故障
应用服务器磁盘都很小，但是将日志级别配置成debug，导致磁盘空间很快被消耗完
应用程序自己的日志输出配置和第三方组件日志输出要分别配置
日志输出级别至少为warn
有些开源的第三方工具也会输出太多的error日志
2.高并发访问数据库引发的故障
网站首页应用调用触发了这个sql
首页不应该访问数据库，应该从缓存服务器或者搜索引擎服务器获取
首页最好静态化
3.高并发情况下锁引发的故障
某个服务器不定期的超时，反反复复
因为单列对象多出使用了同步导致的，所以使用锁要谨慎
4.缓存引发的故障
数据库load突然飙升，切换到备用机也是load飙升最终瘫痪
这是因为不正确的关闭了大量缓存服务器导致的
当缓存已不再是改善性能而是网站架构不可或缺的一部分时，对缓存的管理就需要提高到和其他服务器一样的级别
5.应用启动不同步引发的故障
某应用发布后服务器立即奔溃
应用服务器启动还没启动完，前段代理服务器早就启动好了，导致大量请求阻塞在应用服务器队列中
6.大文件读写独占磁盘引发的故障
上传图片突然非常慢
原因是有几个图片非常大，有几百M，导致磁盘读取都被这个文件占用了
存储的使用需要根据不同文件类型和用途进行管理，图片都是小文件，应该使用专门的存储服务器，不能和大文件公用存储，批量处理大文件可以使用其他的分布式文件系统
7.滥用生成环境引发的故障
某个时间段内某些应用突然变慢，内部网络访问延迟非常大
原因是有人在生产环境做性能压力测试
访问线上生成环境要规范
8.不规范的流程引发的故障
某应用发布后数据库load飙升，回滚代码后又恢复正常
原因是发布代码时访问缓存的那段代码被特意注释掉了
提交代码前要小心做diff
9.不好的编程习惯引发的故障
某应用更新某功能后，有少量用户反映无法正常使用该功能
原因是这些人第一次使用该功能，而代码是根据历史记录构造的对象，导致了null
程序处理第一个输入对象时，如果不能明确该对象是否为空，必须做空指针判断
程序在调用其他方法时，输入的对象尽量保证不是null，必要时构造空对象
第十四章 架构师领导艺术
关注人而不是产品
一群优秀的人做一件他们热爱的事，一定能取得成功
寻找一个值得共同奋斗的目标，营造一个让大家都能最大限度发挥自我价值的工作氛围
发掘人的优秀
是事情成就了人，而不是人成就了事
共享美好蓝图
蓝图应该是表述清楚的
蓝图应该是形象的
蓝图应该是简单的
共同参与架构
不要只有架构师一个人拥有架构
让其他人维护框架与架构文档
学会妥协
不要企图在项目中证明自己是正确的，一定要记住，你是来做软件的，不是来当老大的。所以不要
企图去证明自己了不起。
成就他人
想要成就自己，就必须首先成就他人
第十五章 架构师职场攻略
把"我的问题"表述称"我们的问题"
给上司提封闭式问题，给下属提开放式问题
指出问题而不是批评人
用赞同的方式提出问题
在解决我的问题之前，先解决你的问题
适当的逃避问题
有的人提出不靠谱的问题，先不用说不行会挫伤积极性，等他经过一段时间会意识到不可行
第十六章 漫话网站架构师
按作用分
设计型架构师
救火型架构师
布道型架构师
Geek型架构师
按效果划分架构师
按职责角色划分架构师
按关注层次划分架构师
按口碑划分架构师
非主流方式划分架构师
附录A 大型网站架构技术一览
1.前端架构
浏览器技术优化(页面缓存，合并HTTP请求数，页面压缩)
CDN
动静分离，静态资源独立部署
图片服务
反向代理
DNS
2.应用层架构
开发框架
页面渲染
负载均衡
session管理
动态页面静态化
业务拆分
虚拟化服务
3.服务层架构
分布式消息
分布式服务
分布式缓存
分布式配置
4.存储层架构
分布式文件
关系型数据库
NoSql数据库
数据同步
5.后台架构
搜索引擎
数据仓库
推荐系统
6.数据采集与健康
浏览器数据采集
服务器业务数据采集
服务器性能数据采集
系统监控
系统报警
7.安全架构
web攻击
数据保护
8.数据中心机房架构
机房架构(数据中心地理位置应该供电便宜充足，散热好)
机柜架构
服务器架构