章节 笔记 1.概述 网站架构模式:分层、分割、分布式、集群、缓存、异步、冗余、自动化、安全。 核心架构要素:性能、可用性、伸缩性、扩展性、安全。 4.高性能 一般重复请求一万次计算总响应时间然后除以一万得到单词响应时间。 测试程序并不是启动多线程然后不停发送请求,而是在两次请求之间加入一个随机等待时间。 吞吐量:每天通过收费站的车辆数目;并发数:正在行驶的车辆数目;响应时间:车速。TPS:每秒事务数;HPS:每秒请求数;QPS:每秒查询数。 性能计数器:System Load(系统负载,最理想为CPU数目)、对象与线程数、内存使用、CPU使用、磁盘与网络I/O等指标。 并发数逐渐增加阶段:性能测试-->负载测试-->压力测试、稳定性测试。 随着请求增加系统处理能力增加变缓达到最大值,这是系统最大负载点。继续加压系统处理能力反而下降,最后崩溃可看作系统崩溃点。 浏览器访问优化:1.减少HTTP请求(合并请求,CSS偏移响应);2.使用浏览器缓存(HTTP中Cache-Control和Expires属性,更改文件名逐步更新);3.启用压缩html、css、js启用GZip;4.Css放上面(下载后才渲染页面),js放最下面(下载后立马执行,所以可能阻塞);5.减少Cookie传输(静态资源可启用独立域名,不需要cookie)。 CND加速:对静态资源放入CDN极大改善网页打开速度。 反向代理:位于网站机房一侧,代理网站WEB服务器接收HTTP请求,可保护网站安全;可存放缓存;可实现自动负载均衡。 应用服务器性能优化:缓存、集群、异步。 网站性能优化第一定律:优先考虑使用缓存(访问速度高的存储介质,提高访问速度,无需重复计算)。计算KV对中Key的HashCode对应的Hash表索引,实现快速访问。 合理应用缓存的地方:频繁修改的数据(读写比例大于2:1)、没有热点的访问、数据不一致与脏读(接受超时后重新加载的时间间隔)、缓存可用性(缓存宕机不能对数据库产生很大影响)、缓存预热(提前加载数据放入缓存、LRU:最近最久未用算法)、缓存穿透(缓存无数据,直接访问数据库,最好将不存在的值缓存为null)。 分布式缓存:更新同步分布式(JBoss Cache,所有机器保存缓存内容相同)、互不通信的分布式(Memcached,内存:根据大小块分组,查找大于数据的最小chunk,采用LRU算法释放最近最久未被访问的空间,通过一致性哈希算法可无限制伸缩)。 异步操作:把用户请求直接访问数据库环节增加消息队列,请求发送到消息队列后直接返回,有消息队列操作数据库,从而达到削峰作用。 使用集群:使用负载均衡技术为一个应用构建一个由堕胎服务器组成的服务器集群,分散请求到多台服务器处理。 代码优化:多线程(启动线程数=[任务执行时间/(任务执行时间-IO等待时间)]*CPU内核数)、资源复用(数据库连接、网络通讯连接、线程、复杂对象等)、数据结构(字符-->MD5指纹-->hash计算-->hashcode)、垃圾回收。 存储性能优化:1.机械(快速顺序读写、慢速随机)vs固态 2.B+树vs LSM树 3.RAID vs HDFS RAID:RAID0(同时读写多块,100%)、RAID1(同时写入2块,50%)、RAID10(同时结合1和0,50%)、RAID5((n-1)/n)、RAID6(可靠性比5高,(n-2)/N)。 HDFS:以块为单位,一个文件被分割成若干Block,当写完一个Block是自动复制到另外2台,保证有3个副本。通过MapReduce并发计算任务框架,同时读取多个Block并发处理,相当于RAID0并发。 5.高可用 网站可用性达到4个9,99.99%;故障分=故障时间*故障权重;使用负载均衡进行无状态服务的失效转移。 应用服务器集群的session管理:1.复制;2.通过hash算法实现IP和服务器绑定;3.利用cookie记录session;4.利用分布式缓存、数据库独立部署session服务器(推荐)。 高可用服务:分级管理、超时设置、异步调用、服务降级、幂等性设计。 CAP原理:一个数据服务无法同时满足数据一致性(Consistency,强一致、用户一致、最终一致)、数据可用性(Availibility)、分区耐受性(Partition Tolerance,伸缩性);优先可用、伸缩。 数据备份:冷备(定期复制,无法保证数据一致性和可用性)、热备(异步热备(由代理写入slave)、同步热备(客户端同时读写master-slave))。 更新时暂停负载均衡中一部分服务器来更新,然后使用类似Selenium实现自动测试,然后使用预发布(和线上唯一不同的是未放入负载均衡列表中)。 实现以火车发布模型的自动化发布,然后采用灰度发布(AB测试)进行发布,可方便回滚。 监控数据采集:1.用户行为日志收集(服务端日志、客户端浏览日志(基于Storm实时计算框架日志统计分析));2.服务器性能监控Ganglia;3.运行数据报告(缓存命中率、平均响应、待处理任务) 监控管理:系统报警、失效转移、自动优雅降级。 6.伸缩性 伸缩性:不需要改变网站的软硬件设计,仅通过改变部署的服务器数量就可以扩大或缩小网站处理能力。 伸缩设计:一类通过功能进行物理分离实现伸缩(任何阶段、横向业务、纵向基础服务),一类是单一功能通过集群实现伸缩。 实现负载均衡:1.HTTP重定向(要请求2次、定向服务器瓶颈、SEO作弊);2.DNS域名轮询(配置A记录多个IP,缺点生效慢,权限少,通常作为第一步解析到负载均衡服务器);3.反向代理(接收公网,转发内网服务器,应用层负载均衡);4.IP负载均衡(网络修改IP,比反向代理性能好,但同样可能成为瓶颈);5.数据链路层负载均衡(数据链路层修改mac进行分发,然后直接响应数据给客户端,又称作直接路由方式DR,最好产品LVS)。 负载均衡算法:1.轮询;2.加权轮询;3.随机;4.最少连接(发给当前连接数最少的服务器);5.源地址散列(IP进行Hash,使同IP固定访问一台服务器)。 路由算法:1.取余(在固定服务器数量下可满足所有,无法扩容);2.一致性Hash(将缓存服务器,分发成多个虚拟节点(150)分布在圆形上,按一个方向查找最近的节点)。 读写分离-->分库-->MySQL可以使用Amoeba和Cobar两个产品实现分片(将一张表拆开存储在多个数据库中) NoSQL:not only sql作为关系数据库的补充,放弃结构化查询语言和事务一致性保证,强化可用性和伸缩性。采用HBase实现伸缩。 NoSQL伸缩:应用程序-->向Zookeeper请求HMaster地址-->然后向HMaster输入key请求HRegionServer地址-->然后向HRegionServer输入key查询数据-->HRegionServer访问HRegion得到数据 7.可扩展 扩展性:指对现有系统影响最小的情况下,系统功能可持续扩展或提升的能力。除模块分布式还有分布式消息队列和分布式服务两种方式。 消息队列:1.事件驱动架构(EDA,生产者消费者模式,借助事件消息完成模块间合作);2.分布式消息队列(先进先出、ESB、SOA) 分布式服务需求与特点:负载均衡、失效转移、高效远程通信、整合异构、对应用最小侵入、版本管理、实时监控。Thrift、Dubbo。 利用NOSQL实现可扩展的数据结构。 8.安全性 XSS攻击:跨站脚本攻击(反射型,持久型);防御:1.过滤符号;2.HTTPONLY(禁止js访问此属性cookie); 注入攻击、CSRF(跨站请求伪造)防御:1.表单token;2.验证码;Referer Check; 其他攻击:错误回显、HTML注释、文件上传、路径遍历。 web应用防火墙:ModSecurity、SiteShell。 信息加密:1.单向散列加密(MD5、sha+盐salt);2.对称加密(密钥相同DES、RC);3非对称加密(分公、私钥,RSA,证书即为公钥); 信息过滤:使用正则及Trie树算法或hash表过滤文本、分类算法([无关联即朴素]贝叶斯分类算法)、黑名单(hash表、提取8位指纹布隆过滤器)。 风险:账户风险、买家风险、卖家风险、交易风险;风控:规则引擎、统计模型。 9.其他 秒杀:系统独立部署、页面静态化、租借秒杀活动带宽、动态生成随机URL。单独放置定时js文件到不同服务器,限制每台应用服务器接受请求的总数,超过则丢弃。 故障案例:写日志故障、高并发访问数据库故障、高并发锁故障、缓存引发故障、应用启动不同步故障、大文件读写独占磁盘故障、滥用生产环境故障、不规范流程引发故障(穿透缓存)、编程习惯 时间: 2024-10-17 02:37:53
在第四章案例章节中的淘宝网的架构演化案例分析小节中作者主要分析了淘宝架构的演化,以淘宝网的实例给我们分析介绍了淘宝网的业务发展历程及淘宝网的技术架构演化两个方面,在业务发展中作者写到淘宝的技术是随着淘宝业务一起发展起来的,业务是推动这技术发展的动力,淘宝如今的规模和当初有很明显的变化,在技术架构演化中介绍了架构技术的更新升级,该章节中主要介绍淘宝网的发展的历程,在随着时间的发展不断中网站的架构不断的引用着新的技术,由最初简单的c2c更改过来的网站,放弃了lamp架构转而使用java作为开发平台并
在第四章案例章节中的海量分布式存储系统Doris的高可用架构设计分析的小节中作者主要分析介绍了分布式存储的高可用架构和不同故障情况下的高可用解决两个方面,在两小节前作者给我们介绍了Doris是一个海量分布式KV存储系统,其设计的目的是支持中等规模高可用.可伸缩的Kv存储群.跟主流的NoSQL系统HBase相比,doris具有相似的性能和线性伸缩能力,并具有更好的可用性及更友好的图形用户管理界面.而在分布式存储的高可用架构的小节中作者给我们分析了Doris的整体架构,其系统整体上可分为应用程序服务
在第二章的架构章节中的 随机应变:网站的可拓展架构的篇章中作者介绍了构建网站的可扩展架构.利用分布式队列降低系统的耦合性.利用分布式可复用的业务平台.可拓展的数据结构.利用开放平台建设网站生态圈五个方面,作者在讲述前通过微信的成功发布及其中摇一摇功能的加入的开发的快捷引出来的,其中构建网站的可扩展架构中区分了扩展性和伸缩性的区别,讲到了低耦合性的系统跟容易扩展,并且更容易复用,一个低耦合性的系统也可以让系统更加容易的开发和维护,在如何降低系统的耦合性中,作者主要介绍用分布式消息队列的方法来降低系
在第二章的架构章节中的 瞬时响应:网站的高性能架构的篇章中讲到网站的性能是客观的标准,可以具体的体现在响应时间.吞吐量等技术指标上,同时也是主观的感受.在高性能架构中讲到对于网站性能的测试,性能测试是性能优化的前提和基础,也是性能优化结果的检查和度量标准.在不同的角色响应下网站的性能有不同的标准,也有不同的优化手段.在此基础上作者更深一步的讲解到网站的性能测试,其中又包括了不同视角下的网站性能.性能测试指标.性能测试方法.性能测试报告.性能优化策略五个反面,同时也详细的讲解了这五个方面所具有的内
最近刚刚读完李智慧的<大型网站技术架构-核心原理与案例分析>,对每章重点内容作了一些笔记,以便加深印象及日后查阅. 一.大型网站软件系统的特点 高并发,大流量:需要面对高并发用户,大流量访问. 高可用:系统7X24小时不间断服务. 海量数据:需要存储.管理海量数据,需要使用大量服务器. 用户分布广泛,网络情况复杂:许多大型互联网都是为全球用户提供服务的,用户分布范围广,各地网络情况千差万别. 安全环境恶劣:由于互联网的开放性,使得互联网站更容易受到攻击,大型网站几乎每天都会被黑客攻击. 需求快
如果把上世纪90年代CERN正式发布web标准和第一个WEB服务的出现当作互联网的开始,那么互联网站的发展之经历了短短20多年的时间.在20多年的时间里,互联网的世界发生了变化,今天,全球有近一半的人口使用互联网,人们的生活因为互联网而产生了巨大的变化.从信息检索到即使通信,从电子购物到文化娱乐,互联网渗透到生活的每一个 角落,而且这种趋势还在蔓延.因为互联网,我们的世界正变得越来越小. 同时我们也看到,在互联网跨越式发展进程中,在电子商务火热的市场背后却是不堪重负的网站架构.某些B2C网站逢促
(1) 首先推荐的不是一本书,而是一个博客,也是我们博客园另外一位博友java_my_life. 目前市面上讲解设计模式的书很多,虽然我前面讲了看书是最好的,但是对设计模式感兴趣的朋友们,我推荐的是这个博客.这位博友的设计模式讲得非常非常好,我认为90%的内容都是没有问题且很值得学习的,其讲解设计模式的大体路线是: 1.随便开篇点明该设计模式的定义 2.图文并茂讲解该设计模式中的结构 3.以详细的代码形式写一下该种设计模式的实现 4.补充内容 5.讲解该设计模式的优缺点 对于一个设计模式我们关
通过阅读该书籍我们能够更加清楚的树立大型网站的的技术发展历程,剖析大型网站技术架构模式,深入的讲述大型互联网架构核心原理,并通过一些典型的技术案例来讲述大型网站开发全景视图,该书籍深入的阐述了各种大型网站面临的各种架构问题及解决方案. 在第一章第一篇大型网站架构演化中了解到与传统企业应用系统相比,大型互联网应用系统具有高并发大流量.高可用性.海量数据.用户分布广泛,网络情况复杂.安全环境恶劣.需求快速变更,发布频繁.渐进式发展等特点:大型网站架构演化发展历程经历了初始阶段的网络架构它的应用程序.
阿里系的书,也是讲大型网站系统架构的,平常我们总是挂在嘴边的高性能.高可用.易扩展.安全性,这些所谓的系统非功能性指标到底如何实现,书里面讲了这些干货,作为网站架构师或者哪怕是应用系统的架构师,都值得了解,也许不一定都能用上,但是等需要用的那天,你肯定不会迷茫. 1.大型网站架构发展常见历程:应用/数据库分离--->使用缓存--->应用服务器集群--->数据库读写分离--->CDN及反向代理--->使用分布式文件系统和分布式数据库--->NoSQL及搜索引擎--->