大型网站技术架构 核心原理与案例分析 读后总结
- 概述
- 大型网站架构演化
-
- 大型网站软件系统的特点
- 高并发、大流量
- 高可用
- 海量数据
- 用户分布广泛,网络情况复杂
- 安全环境恶劣
- 需求快速变更,发布频繁
- 渐进式发展
- 大型网站架构演化发展历程
- 初始阶段的网站架构:大型网站都是从小型网站发展而来
- 应用服务和数据服务分离
- 使用缓存改善网站性能
- 使用应用服务器集群改善网站的并发处理能力
- 数据库读写分离
- 使用反向代理和CDN加速网站响应:
- 大型网站架构演化发展历程
- CDN部署在网络提供商的机房,使用户在请求网站服务时可以从距离自己最近的网络提供商机房获取数据。
- 反向代理部署在网站的中心机房,当用户请求到达中心机房后,首先访问的服务器是反向代理服务器,如果反向代理服务器中缓存着用户请求的资源,就将其直接返回给用户。
-
- 使用分布式文件系统和分布式数据库系统
- 使用NoSQL和搜索引擎
- 业务拆分
- 分布式服务
- 大型网站架构演化的价值
- 大型网站架构技术的核心价值是随网站所需灵活应对
- 大型网站技术发展的主要力量是网站的业务发展
- 网站架构设计误区
- 一味追随大公司的解决方案
- 为了技术而技术
- 企图用技术解决所有问题
-
-
- 大型网站架构模式
- 网站架构模式:
- 分层
应用层 | 负责具体业务和视图展示,如网站首页及搜索输入和结果展示。 |
服务层 | 为应用层提供服务支持,如用户管理服务,购物车服务等。 |
数据层 | 提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。 |
-
- 分割
- 分布式
常用方案:
- 分布式应用和服务
- 分布式静态资源
- 分布式数据和存储
- 分布式计算
- 集群
- 缓存
- CDN
- 反向代理
- 本地缓存
- 分布式缓存
- 异步
- 提高系统可用性
- 加快网站响应速度
- 消除并发访问高峰
- 冗余
- 自动化
- 发布过程自动化
- 自动化代码管理
- 自动化测试
- 自动化安全检测
- 自动化部署
- 自动化监控
- 自动化报警
- 自动化失效转移
- 自动化失效恢复
- 自动化降级
- 自动化分配资源
- 安全
-
- 大型网站核心架构要素
- 性能
- 可用性:主要手段是冗余
- 伸缩性:衡量标准是是否可以用多台服务器构建集群,是否容易向集群中添加新的服务器。
- 扩展性
- 大型网站核心架构要素
- 事件驱动架构:利用消息队列实现,将用户请求和其他业务事件构造成消息发布到消息队列,消息的处理者作为消费者从消息队列中获取消息进行处理。
- 分布式服务:将业务和可复用服务分离开来,通过分布式服务框架调用。
-
- 安全性
-
- 架构
- 瞬时响应:网站高性能架构
- 网站性能测试
- 不同视角下的网站性能:
- 用户视角的网站性能:
- 用户计算机和网站服务器通信的时间
- 网站服务器处理的时间
- 用户计算机浏览器构造请求解析响应应用数据的时间。
- 开发人员视角的网站性能:
- 相应延迟
- 系统吞吐量
- 并发处理能力
- 系统稳定性
优化手段:
- 使用缓存加速数据读取
- 使用集群提高吞吐量能力
- 使用异步消息加快请求响应及实现削峰
- 使用代码优化手段改善程序性能
- 运维人员视角的网站性能:
- 基础设施性能
- 资源利用率
- 性能测试指标:
- 响应时间
- 并发数
- 吞吐量:TPS(每秒事务数)、HPS(每秒HTTP请求数)、QPS(每秒查询数)
- 性能计数器
- 性能测试方法:
- 性能测试
- 负载测试
- 压力测试
- 稳定性测试
- 性能优化策略:
- Web前端性能优化
- 应用服务器性能优化
- 存储服务器性能优化
- 性能测试指标:
- Web前端性能优化
- 浏览器访问优化
- 减少http请求:主要手段是合并CSS、合并JavaScript、合并图片
- 使用浏览器缓存
- 启用压缩
- CSS放在页面最上面、JavaScript放在页面最下面
- 减少Cookie传输
- CDN加速:(Content Distribute Network,内容分发网络)的本质仍然是一个缓存,而且将数据缓存在离用户最近的地方,使用户以最快速度获取数据,即所谓网络访问第一跳。
- 反向代理;
- 具有保护网站安全的作用
- 通过配置缓存功能加速Web请求
- 可以实现负载均衡
- 浏览器访问优化
- 应用服务器性能优化:主要手段有缓存、集群、异步
- 分布式缓存
- 缓存的基本原理;
- 缓存主要用来存放那些读写比很高,很少变化的数据。
- 二八定律:80%的访问落在20%的数据上。
- 合理使用缓存
- 错误使用:
- 频繁修改的数据:读写比2:1以上,缓存才有意义
- 没有热点的访问
- 数据不一致与脏读:设置失效时间
- 缓存可用性
- 缓存预热:LRU(最近最久未用算法)
- 缓存穿透
- 错误使用:
- 分布式缓存架构:
- 需要更新同步的分布式缓存(JBoss Cache)
- 不互相通信的分布式缓存(Memcached)
- 缓存的基本原理;
- 异步操作
- 使用消息队列具有很好的削峰作用
- 使用集群
- 代码优化;
- 多线程:
- 启动线程数=[任务执行时间/(任务执行时间- IO等待时间)] *CPU内核数
- 将对象设计为无状态对象
- 使用局部对象
- 并发访问资源时使用锁
- 资源复用
- 数据结构
- 垃圾回收
- 多线程:
- 分布式缓存
- 存储性能优化:
- 机械硬盘、固态硬盘
- B+树、LSM树:LSM树上进行一次数据更新不需要磁盘访问,在内存即可完成,速度远快于B+树。当数据访问以写操作为主,而读操作则集中在最近写入的数据上时,使用LSM树可以极大程度地减少磁盘的访问次数,加快访问速度。
- RAID、HDFS
- RAID(廉价磁盘冗余阵列)技术主要是为了改善磁盘的访问延迟、增强磁盘可用性和容错能力。
- RAID0:数据在从内存缓冲区写入磁盘时,根据磁盘数量将数据分成N份,这些数据同时并发写入N块磁盘,使得数据整体写入速度是一块磁盘的N倍。
- RAID1:数据在写入磁盘,将一份数据同时写入两块磁盘,这样任何一块磁盘损坏都不会导致数据丢失,插入一块新磁盘就可以通过赋值数据的方式自动修复,具有极高的可靠性。
- RAID10:结合RAID0和RAID1两种方案,将所有磁盘平均分成两份,数据同时在两份磁盘写入,相当于RAID1,但是在每一份磁盘里的N/2块磁盘上,利用RAID0技术并发读写,既提高可靠性又改善性能,不过RAID10的磁盘利用率较低,有一半的磁盘用来写备份数据。
- RAID3:在数据写入磁盘的时候,将数据分成N-1份,并发写入N-1块磁盘,并在第N块磁盘记录校验数据,任何一块磁盘损坏(包括校验数据磁盘),都可以利用其他N-1块磁盘的数据修复。
- RAID5:与RAID3很相似,但是校验数据不是写入第N块磁盘,而是螺旋式地写入所有的磁盘中。
- RAID6:与RAID5类似,但是数据只写入N-2块磁盘,并螺旋式地在两块磁盘中写入校验信息(使用不同算法生成)。
- HDFS(hadoop分布式文件系统)
- RAID(廉价磁盘冗余阵列)技术主要是为了改善磁盘的访问延迟、增强磁盘可用性和容错能力。
- 万无一失:网站的高可用架构
- 网站可用性(Availability)描述网站可有效访问的特性。
- 网站可用性度量:
- 网站可用性(Availability)描述网站可有效访问的特性。
网站不可用时间(故障时间)=故障修复时间点-故障发现(报告)时间点
网站年度可用性指标=(1-网站不可用时间/年度总时间)*100%
-
-
- 网站可用性考核:
-
可用性指标是网站架构设计的重要指标,对外是服务承诺,对内是考核指标。
故障分=故障时间(分钟)*故障权重
-
- 高可用的网站架构
- 应用层:主要负责具体业务逻辑处理
- 服务层:负责提供可复用的服务
- 数据层:负责数据的存储和访问
- 高可用应用
- 通过负载均衡进行无状态服务的失效转移
- 应用服务器集群的Session管理
- 高可用的服务
- 分级管理
- 超时设置
- 异步调用
- 服务降级
- 幂等性设计
- 高可用的数据
- CAP原理:数据一致性(Consistency)、数据可用性(Availability)、分区耐受性(Partition Tolerance)
- 数据备份:异步热备份、同步热备份
- 失效转移:
- 高可用的网站架构
- 失效确认:心跳检测、应用程序访问失败报告
- 访问转移
- 数据恢复
- 高可用网站的软件质量保证
- 网站发布
- 自动化测试
- 预发布验证:
- 高可用网站的软件质量保证
- 预发布服务器是一种特殊用途的服务器,它和线上的正式服务器唯一的不同就是没有配置在负载均衡服务器上,外部用户无法访问。
- 预发布服务器和线上正式服务器都部署在相同的物理环境中,使用相同的线上配置,依赖相同的外部服务。
-
- 代码控制:
-
- 主干开发、分支发布
- 分支开发、主干发布
-
- 自动化发布
- 灰度发布(金丝雀发布)
- 网站运行监控:不允许没有监控的熊谈上线
- 监控数据采集:
-
- 用户行为日志收集;
- 服务端日志收集
- 客户端浏览器日志收集
- 服务器性能监控
- 运行数据报告
-
- 监控管理:
-
- 系统报警
- 失效转移
- 自动优雅降级
- 永无止境:网站的伸缩性架构
- 网站架构的伸缩性设计
- 伸缩性是指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。
- 网站架构的伸缩性设计
- 根据功能进行物理分离实现伸缩:不同服务器部署不通的服务,提供不同的功能
- 纵向分离(分层后分离):将业务处理流程上的不同部分分离部署,实现系统伸缩性。
- 纵向分离(业务分隔后分离):将不同的业务模块分离部署,实现系统伸缩性
- 单一功能通过集群实现伸缩:集群内的多台服务器部署相同的服务,提供相同的功能
- 应用服务器集群的伸缩性设计
- HTTP重定向负载均衡:HTTP重定向服务器是一台普通的应用服务器,其唯一的功能就是根据用户的HTTP请求计算一台真实的Web服务器地址,并将该Web服务器地址写入HTTP重定向响应中(响应状态码302)返回给用户浏览器。
- DNS域名解析负载均衡:每次域名解析请求都会根据负载均衡算法就算一个不同的IP地址返回。
- 反向代理负载均衡:利用反向代理服务器进行负载均衡
- IP负载均衡:在网络层通过修改请求目标地址进行负载均衡
- 数据链路层负载均衡:数据链路层负载均衡是指在通信协议的数据链路层修改mac地址进行负载均衡。
- 负载均衡算法:
- 轮询(Round Robin,RR)
- 加权轮询(Weighted Round Robin,WRR)
- 随机(Random)
- 最少连接(Least Connections)
- 源地址散列(Source Hashing)
-
- 分布式缓存集群的伸缩性设计
- 必须让新上线的缓存服务器对整个分布式缓存集群影响最小,也就是说新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到,这就是分布式缓存集群伸缩性设计的最主要目标。
- 计算机的任何问题都可以通过增加一个虚拟层来解决。
- 数据存储服务器集群的伸缩性设计
- 关系数据库集群的伸缩性设计:读写分离、数据分库、Cobar(分布式关系数据库访问代理)
- NoSQL数据库的伸缩性设计:
- 分布式缓存集群的伸缩性设计
- 随需应变:网站的可扩展架构
- 概念:
- 扩展性(Extensibility):指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。
- 伸缩性(Scalability):指系统能够通过增加(减少)自身资源规模的方式增强(减少)自己计算处理事务的能力。
- 构建可扩展的网站架构
- 度量一个开发框架、设计模式、编程语言优劣的中有尺度就是衡量它是不是让软件开发过程和软件产品跟家低耦合。
- 作者认为,软件架构师最大的价值不在于掌握多少先进的技术,而在于具有将一个大系统切分成N个低耦合的子模块的能力,这些子模块包含横向的业务模块,也包含纵向的基础技术模块。这种能力一部分源自专业的技术和经验,还有一部分源自架构师对业务场景的理解、对人性的把握、甚至对世界的认知。
- 利用分布式消息队列降低系统耦合性
- 事件驱动架构
- 分布式消息队列
- 利用分布式服务打造可复用的业务平台
- 巨无霸系统的问题:
- 概念:
- 编译、部署困难
- 代码分支管理困难
- 数据库连接耗尽
- 新增业务困难
-
- Web Service与企业级分布式服务
- 缺点:
- Web Service与企业级分布式服务
-
- 臃肿的注册与发现机制
- 低效的XML序列化手段
- 开销相对较高的HTTP的远程通信
- 复杂的部署与维护手段
-
- 大型网站分布式服务的需求与特点
-
- 负载均衡
- 失效转移
- 高效的远程通信
- 整合异构系统
- 对应用最小侵入
- 版本管理
- 实时监控
-
- 分布式服务框架设计
- 大型网站分布式服务的需求与特点
-
- SOA(Service Oriented Architecture 面向服务的体系架构)
- 可扩展的数据结构
- 利用开放品台建设网站生态圈
- API接口
- 协议转换
- 安全
- 审计
- 路由
- 固若金汤:网站的安全架构
- 网站安全:
- XSS攻击(Cross Site Script 跨站点脚本攻击,指黑客通过篡改网页,注入恶意HTML脚本,在用户浏览网页时,控制用户浏览器进行恶意操作的一种攻击方式):
- 网站安全:
- 反射型:攻击者诱使用户点击一个嵌入恶意脚本的连接,达到攻击的目的。
- 持久型:黑客提交含有恶意脚本的请求,保存在被攻击的Web站点的数据库中,用户浏览网页时,恶意脚本被包含在正常页面中,达到攻击的目的。
-
- XSS防攻击手段:
-
- 消毒
- HttpOnly
-
- 注入攻击
-
- SQL注入攻击
- OS注入攻击
-
- 注入防攻击手段:
-
- 消毒
- 参数绑定
-
- CSRF攻击:
-
- CSRF(Cross Site Request Forgery,跨站点请求伪造),攻击者通过跨站请求,以合法的用户的身份进行非法操作。
- 防御手段:
- 表单Token
- 验证码
- Referer check
- 其他攻击和漏洞
- Error Code
- HTML注释
- 文件上传
- 路径遍历
-
- Web应用防火墙
- 网站安全漏洞扫描
- 信息加密技术及密匙安全管理
- 单向散列加密
- 对称加密
- 非对称加密
- 信息过滤与反垃圾
- 文本匹配:主要解决敏感词过滤的问题;可以通过正则表达式匹配、通过构造多级Hash表进行文本匹配。
- 分类算法:贝叶斯分类算法、朴素贝叶斯算法
- 黑名单
- 电子商务风险控制
- 风险
-
- 账户风险
- 卖家风险
- 卖家风险
- 交易风险
-
- 风控
-
- 机器将自动风控技术手段:
- 规则引擎:四一中将业务规则和规则处理逻辑相分离的技术
- 统计模型:
- 案例
- 淘宝网的架构演化案例分析
- 维基百科的高性能架构设计分析
- 海量分布式存储系统Doris的高可用架构设计分析
- 网购秒杀系统架构设计案例分析
- 大型网站典型故障案例分析
- 写日志也会引发故障
- 高并发访问数据库引发的故障
- 高并发情况下锁引发分故障
- 缓存引发的故障
- 应用启动不同步引发的故障
- 大文件读写独占磁盘引发的故障
- 滥用生产环境引发的故障
- 不规范的流程引发的故障
- 不好的编程习惯引发的故障
- 架构师
- 架构师领导艺术
- 架构师职能:
- 架构设计
- 软件开发技术工作
- 规划产品路线
- 估算人力资源和人力资源
- 安排人员职责分工
- 确定计划里程碑点
- 指导工程师工作
- 过程风险评估与控制
- 关注人而不是产品
- 一群优秀的人做一件他们热爱的事,一定能取得成功。
- 寻找一个值得共同奋斗的目标,营造一个让大家都能最大限度发挥自我价值的工作氛围。
- 发掘人的优秀
- 是事情成就人,而不是人成就了事。
- 发掘人的优秀远比发掘优秀的人更有意义。
- 共享美好蓝图
- 蓝图应该是表述清楚的
- 蓝图应该是形象的
- 蓝图应该是简单的
- 共同参与架构
- 不要只有架构师一个人拥有架构
- 让其他人维护框架与框架文档
- 学会妥协
- 对于技术细节的争论应该立即验证而不是继续讨论
- 成就他人
- 我们活着是为了成就我们自己,而要想成就自己,就必须首先成就他人。
- 在项目过程中不要试图去控制什么,带着一个弹性的计划和蓝图推进,团队会管好他们自己。
- 架构师职能:
- 网站架构师职场攻略
- 发现问题,寻找突破
- 提出问题,寻求支持
- 把“我的问题”表述成“我们的问题”
- 给上司提封闭式问题,给下属提开放式问题
- 指出问题而不是批评人
- 用赞同的方式提出问题
- 解决问题,达成绩效
- 漫画网站架构师
- 按作用划分架构师:
- 设计型架构师
- 救火型架构师
- 布道型架构师
- Geek型架构师
- 按效果划分架构师
- 夏尔巴人架构师
- 斯巴达人架构师
- 达官贵人架构师
- 按职责角色划分架构师
- 产品架构师
- 基础服务架构师
- 基础设施架构师
- 按关注层次划分架构师
- 只关注功能的架构师
- 关注非功能的架构师
- 关注团队组织与管理的架构师
- 关注产品运营的架构师
- 关注产品未来的架构师
- 按口碑划分架构师
- 最好的架构师
- 好的架构师
- 一般的架构师
- 差的架构师
- 最差的架构师
- 非主流方式划分架构师
- 普通架构师
- 文艺架构师
- 1+1架构师
- 按作用划分架构师:
附录A 大型网站架构技术一览
- 前端架构
- 浏览器优化技术
- CDN
- 动静分离、静态资源独立部署
- 图片服务
- 反向代理
- DNS
- 应用层架构
- 开发框架
- 页面渲染
- 负载均衡
- Session管理
- 动态页面静态化
- 业务拆分
- 虚拟化服务器
- 服务层架构
- 分布式消息
- 分布式服务
- 分布式缓存
- 分布式配置
- 存储层架构
- 分布式文件
- 关系数据库
- NoSQL数据库
- 数据同步
- 后台架构
- 搜索引擎
- 数据仓库
- 推荐系统
- 数据采集与监控
- 浏览器数据采集
- 服务器业务数据采集
- 服务器性能数据采集
- 系统监控
- 系统报警
- 安全建构
- Web攻击
- 数据保护
- 数据中心机房架构
- 机房架构
- 机柜架构
- 服务器架构
附录B Web开发家属发展历程