架构探讨(精品)

上传人:仙*** 文档编号:244449353 上传时间:2024-10-04 格式:PPT 页数:33 大小:2.95MB
返回 下载 相关 举报
架构探讨(精品)_第1页
第1页 / 共33页
架构探讨(精品)_第2页
第2页 / 共33页
架构探讨(精品)_第3页
第3页 / 共33页
点击查看更多>>
资源描述
Action title,Subtitle,Unit/measure,First level,Second level,Third level,BeetleSoft,大型网站技术架构探讨,*,CE v6.3,Action title,Subtitle,Unit/measure,First level,Second level,Third level,BeetleSoft,“,大型”网站技术架构探讨,余浩东,201,1,年6月,大型网站架构的目标与挑战,网站架构演变及其技术脉络,架构设计理论与原则,讨论及总结,大型网站架构的目标与挑战,何谓,“,大型,”,网站?,网站,日均流量,IP/PV,IP 5,972,587 PV 9,376,962,IP229,680,000 PV2,955,981,600,IP25,680,000 PV222,132,000,IP5,532,000 PV25,723,800,IP300,000 PV747,000,没有统一的判断标准,流量大小是一个重要指标,日均流量至少,IP1,000,000,才算大型网站,大型网站架构的目标与挑战,何谓,“,大型,”,网站?,网站内容是否,“,动态,”,才是关键,大型网站架构的目标与挑战,网站架构目标与挑战,每个目标背后面临着技术、设计、维护等诸多方面的挑战。,而目标本身的期望值也会根据实际情况进行调整,这也意味着,网站架构建设是个不断调整的过程,。,负载均衡,数据备份,异地容灾,。,高速缓存,并行计算,异地镜像,。,开发框架,多层设计,业务分割,。,大型网站架构的目标与挑战,网站架构演变及其技术脉络,架构设计理论与原则,讨论及总结,网站架构演变及其技术脉络,Step1Web,动静态资源分离及其与,DB,物理分离,优点:,“,简单,”,、安全性提高,缺点:存在单点,谈不上高可用性(,high availability,架构目标),技术点:应用设计要保证可扩展(,framework,很重要,Spring/Beetle,)、,Web Server,动,/,静态资源分离,Web Server,(,ApacheNginxIISJBoss,)、,Database Server,(,MysqlOracleRedis,),Step1,技术点,Web,动静态资源分离,img,doc,js,css,等静态资源使用单独的,Web HTTP Server,处理请求,动态页面静态化处理,网站架构演变及其技术脉络,Step2,采取缓存处理,优点:简单有效、维护方便,缺点:依然存在单点,技术点:客户端(浏览器)缓存、前端页面缓存、页面片段缓存、本地数据缓存,/,数据库缓存,网站架构演变及其技术脉络,减少对网站的访问,减少对,Web,应用服务器的请求,减少对数据库的查询,减少文件系统,I/O,操作,Step2,技术点,客户端(浏览器)缓存,技术点说明,根据,HTTP,协议特性,修改,Header,参数(,Cache-Control,、,Expires,、,Pragma,、,Last-Modified,、,Etag,),让浏览器来缓存页面(一些优秀开发框架会对此做透明的封装,例如:,Beetle,),http:/www.w3.org/Protocols/rfc2616/rfc2616-sec14.html,使用,HTTP1.1,协议,由于,http pipelining,技术特性,能够使用,get,请求的决不采取,post,请求,为了节约带宽,压缩页面(,Content-Encoding:gzip,);页面各个元素能,“,小,”,即,“,小,”,,例如:,js,包压缩,,js,合并,图片压缩等,会话状态信息采取,Cookie,代替传统使用服务器,Sessions,对象存储习惯做法;使用,Ajax,实现页面局部刷新,如果可能,可采取浏览器插件技术突破浏览器功能限制,将原本在服务,器端运算,尽量迁到浏览器端。,ActiveX/Applet/Flash/,.,HTML5,最值得期待,她的出现必定改变整个,Web,世界,能够让浏览器缓存的数据一定要缓存;浏览器能够处理的运算,决不放在服务器端来处理。,网站架构演变及其技术脉络,Step2,技术点,前端页面缓存,采用具备缓存功能的,http,反向代理服务器作前端页面缓存器,,VarnishSquidNcacheAiCache(,商业,),【,硬件,F5】,网站架构演变及其技术脉络,Step2,技术点,页面片段缓存,ESI(Edge Side Includes),ESI,需要服务器端支持,常见,apache(mod_esi),、,WebLogic,、,JSP,标签库,(JESI),等。,网站架构演变及其技术脉络,Step2,技术点,本地数据缓存,需要从数据库系统和,Web,应用服务器两个层面考虑缓存优化,网站架构演变及其技术脉络,技术点说明,关系数据库系统(如:,OracleMySql,),Query Cache,策略:一般以,sql,为,key,来缓存查询结果,尽量不要拼,sql,,使用,PreparedStatement,的,“,?,”,模式,sql,;,Query Cache,大小要根据数据库系统具体情况合理设置,过大只会浪费内存,参考值:,128M,关系数据库系统,Data Buffer,策略:就是数据库数据内存缓存器,其访问命中率决定数据库性能,可根据实际物理内存大小适量增大,如:,MySql,建议,buffer,值为物理内存,60-80%,应用服务器,Cache,包括:对象缓存(例如:对象线程安全,做成单例),更新频率不大数据考虑缓存(如:基表数据、配置文件信息),考虑使用线程池,对象池,连接池等,常见,java,解决方案:,mapOSCacheEHCache,等,Step3,增加机器做,HA,、数据库读写分离,网站架构演变及其技术脉络,优点:增加服务器和,HA,机制,系统性能及可用性得到保证,缺点:读写分离,增加程序难度,架构变复杂,维护难度增加,技术点:负载均衡、,DAL,、数据库读写分离,Step3,技术点,负载均衡,网站架构演变及其技术脉络,类型,说明,DNS,负载均衡,实现简单、有,Cache,缺乏灵活性,但对分区域(如构建,CDN,方案)访问简单有效,反向代理软件,HAProxy,、,Nginx,、,Apache,、,Lighttpd,等,硬件产品,F5,、,NetScaler,等,LVS(Linux Virtual Server),http:/www.linuxvirtualserver.org/,SMART Client,自己写代码某些情况下简单有效,Step3,技术点,数据库读写分离及,DAL,网站架构演变及其技术脉络,读写分离逻辑分批,负载均衡,失效转移(,failover,),数据库分区透明支持,两大实现模式:独立,Proxy,服务器;单独,API,库文件,各个数据库厂商都有自己复制方案,常见通用方案:,ETL,、,GoldenGate,TJS,Step4CDN,、分布式缓存、分库,网站架构演变及其技术脉络,优点:异地缓存有效解决不同地方用户访问过慢的问题;分库策略带来网站性能整体提升,缺点:成本大幅增加,架构进一步复杂化,也维护难度进一步增大,架构开始臃肿了,技术点:,CDN,、分布式缓存、,Shard,分库,Step4,技术点,CDN,网站架构演变及其技术脉络,CDN(Content Delivery Network),内容分发网络,将网站的内容分发到最接近用户的网络,“,边缘,”,,使用户可以就近获取,从而解决互联网网络拥挤的状况,提高用户访问的响应速度。,适合静态内容很多(如:静态页面、图片、视频等)及页面内容实时性要求不高的网站,如:新闻类门户网站,CDN,构建可以做的很简单,也可以很复杂,主要根据自己网站实际情况而定,Step4,技术点,分布式缓存,网站架构演变及其技术脉络,本地缓存性能优秀,但容量有限,无伸缩性,采用分布式缓存方案突破容量限制,具备良好伸缩性;但分布式涉及远程网络通信消耗其性能本地缓存来得优秀,并可涉及节点状态维护及数据复制问题,其稳定性和可靠性是个挑战。,目前流行分布式缓存方案:,memcached,、,membase,、,redis,等,基本上当前的,NoSQL,方案都可以用来做分布式缓存方案,Step4,技术点,分库,网站架构演变及其技术脉络,读写分离(简单有效,前面已介绍),垂直分区,良好的松耦合的模块化设计是垂直分库的前提,Step4,技术点,分库,网站架构演变及其技术脉络,水平分区(,Shard,),分片,Key,识别(划分检索依据)是关键,是否还有其它招?用,NoSql,数据库部分替换关系数据库,Step5,多个数据中心,向分布式存储和计算的架构体系迈进,网站架构演变及其技术脉络,优点:多数据中心,带来更高质量区域服务体验;分布式存储及计算架构有效解决,pb,级数据量存储、检索及计算性能问题,缺点:架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高,技术点:分布式文件系统、,Map/Reduce,、,Key-Value,存储,Step5,技术点,向分布式存储计算解决方案,DFS,、,Map/Reduce,、,Key-Value DB,网站架构演变及其技术脉络,DFS,分布式文件系统,如:,LustreHDFSGFSTFSFreeNas,等,Map/Reduce,算法(计算框架),基本上现有,NoSQL,数据库中都支持此算法。,Key-Value DB,,也作为,NoSQL,解决方案,如:,BigTableTairHbase HyperTable,等,提供完整解决方案:,Google(GFS|Map/Reduce|BigTable),Apache Hadoop(HDFS|Map/Reduce|HBase),大型网站架构的目标与挑战,网站架构演变及其技术脉络,架构设计理论与原则,讨论及总结,架构设计理论与原则,网站架构设计的精神食粮,架构设计理论与原则,关于数据一致性,ACID vs BASE,ACID,(,Atomicity,、,Consistency,、,Isolation,、,Durability,)是关系型数据库的最基本原则,遵循,ACID,原则强调一致性,对成本要求很高,对性能影响很大。,问题:,ACID,原则适用于互联网应用吗?可用性似乎比一致性重要些,BASE,(,B,asically,A,vailable,、,S,oft state,、,E,ventually consistent,)策略,BASE,策略与,ACID,不同,其基本思想就是通过牺牲强一致性,以获得更好的可用性或可靠性,基本可用,数据能够保证,80%,一致性就够了,剩下,20%,就不要过于纠结了。可参考八二定律,软状态,在不过分追求数据一致性(强一致性)前提下可考虑软状态策略,例如把数据缓存(,State,)在客户端一段时间,过后若没有新请求的话,就清除此缓存(,Soft,),最终一致性,在某一段短时间内允许数据不一致,但经过一段较长时间,等所有节点上数据的拷贝都整合在一起的时候,数据会最终达到完全一致,架构设计理论与原则,关于分布式系统,CAP,理论,一致性,分布式系统中,数据一般会存储在不同节点,一致性就是要保证对数据操作的原子性,可用性,确保客户访问数据时可得到响应。不强调各个节点上数据要保持一致性。,分区容忍性,数据分区存储后,即使部分分区组件不可用,其施加的操作也能够完成,CAP,理论指出:一个分布式系统不可能同时满足一致性、可用性,和分区容忍性这三项需求,最多只能同时满足其中两个。,架构设计理论与原则,无共享架构(,Share Nothing Architecture,),架构设计理论与原则,ED-SOA,架构,ED-SOA,,事件驱动,面向服务架构,SOA,是系统组件化、模块化构建性理论;,ED,是系统组件之间同步通信,采取事件机制异步化,提高响应速度,基于,
展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 管理文书 > 施工组织


copyright@ 2023-2025  zhuangpeitu.com 装配图网版权所有   联系电话:18123376007

备案号:ICP2024067431-1 川公网安备51140202000466号


本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。装配图网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知装配图网,我们立即给予删除!