大型网站建设架构设计与实践探讨课件

1、大型网站建设架构设计与实践探讨-从前端到后台童景文 技术架构师 景文童声明本文件中有些图片和文字源自互联网，其版权归属相关图片和文字的所有者。 需要了解的一些网络流量术语： /view/595240.htmUV(独立访客)：即Unique Visitor,访问您网站的一台电脑客户端为一个访客。00:00-24:00内相同的客户端只被计算一次。PV(访问量)：即Page View, 即页面浏览量或点击量，用户每次刷新即被计算一次。IP(独立IP)：指独立IP数。00:00-24:00内相同IP地址只被计算一次。 大型网站架构的目标与挑战 网站的主要分类网站有很多所分类方式（ /view/4232

2、.htm#5 ）：1、根据网站所用编程语言分类：例如asp网站、php网站、jsp网站、Asp. net网站等；2、根据网站的用途分类：例如门户网站（综合网站）、行业网站、娱乐网站等；3、根据网站的功能分类：例如单一网站（企业网站）、多功能网站（网络商城）等。4、根据网站的持有者分类：例如个人网站、商业网站、政府网站等。5、根据网站的商业目的分类：营利型网站（行业网站、论坛）、非营利性型网站（企业网站、政府网站）我们这按照对现在大众使用网络的应用类型和生活服务的习惯进行简单性的几种大致分类，不从专业角度的进行分类. 大型网站架构的目标与挑战 网站的主要分类2.娱乐：在线视频(xunlei,yo

3、uku）。 技术特点：以静态内容占大部分，动态内容也多，对网站接入带宽要求高 大型网站架构的目标与挑战 网站的主要分类2.娱乐：在线游戏(QQGame）。 技术特点：以客户端技术和相应的后台技术为核心（网站仅仅是一个服务手段），网页游戏现在还不是主流 大型网站架构的目标与挑战 网站的主要分类4.搜索（Google Search，Baidu Search） 技术特点：搜索界面简单,基本上全是动态内容，但是技术极其复杂 大型网站架构的目标与挑战 网站的主要分类5.电子商务（淘宝） 技术特点：动态内容，静态内容也多，功能多，技术实现极其复杂 大型网站架构的目标与挑战 网站的主要分类6.SNS（新浪微

4、博、QQZone 、FaceBook） 技术特点：动态内容占绝大部，功能多，技术实现极其复杂 大型网站架构的目标与挑战何谓“大型”网站？大型网站架构的目标与挑战没有统一的判断标准，流量大小是一个非常重要指标；即UV,PV,独立IP网站日均流量IP/PVwww.QQ.comIP 45,180,000 PV 407,523,600IP229,680,000 PV2,955,981,600IP25,680,000 PV222,132,000IP5,532,000 PV25,723,800IP25,740,000 PV500,128,IP22,200 PV48,840www. IP1,152,000

5、PV3,375,360IP1,758,000 PV11,936,820 日均流量至少IP1,000,000 才能算大型网站何谓“大型”网站？大型网站架构的目标与挑战并且 网站内容 是否“动态”才是关键网站架构目标与挑战 每个目标背后面临着技术、设计、维护等诸多方面的挑战。 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。 负载均衡数据备份异地容灾。高速缓存并行计算异地镜像。开发框架多层设计业务分割。大型网站架构的目标与挑战大数据、大并发并且对于一个大型网站来说，大并发、大数据量的高性能和可靠性的架构设计是最重要的；只要这个架构设计和相应的代码质量较好就可以

6、满足所有的不同类型大型网站的要求。并且在国内外互联网领域 出名的不同类型的大型网站为了支撑大并发、大数据量的高性能和可靠性的思想都是比较类似的 网站架构及其技术演进Step1Web动静态资源分离及其与DB物理分离优点：“简单”、安全性提高缺点：存在单点，谈不上高可用性（high availability架构目标）技术点：应用设计要保证可扩展（framework很重要Spring/Beetle）、Web Server动/静态资源分离Web Server（ApacheNginxIISWAS）、Database Server（RedisDB2）Step1技术点Web动静态资源分离网站架构及其技术演进

7、img,doc,js,css等静态资源使用单独的Web HTTP Server处理请求动态页面静态化处理Step2.1技术点客户端（浏览器）缓存技术点说明根据HTTP协议特性，修改Header参数（Cache-Control、Expires、Pragma、Last-Modified、Etag），让浏览器来缓存页面（一些优秀开发框架会对此做透明的封装，例如：Beetle）/Protocols/rfc2616/rfc2616-sec14.html使用HTTP1.1协议，由于http pipelining技术特性，能够使用get请求的决不采取post请求为了节约带宽，压缩页面（Content-Enc

8、oding: gzip）；页面各个元素能“小”即“小”，例如：js包压缩，js合并，图片压缩等会话状态信息采取Cookie代替传统使用服务器Sessions对象存储习惯做法；使用Ajax实现页面局部刷新如果可能，可采取浏览器插件技术突破浏览器功能限制，将原本在服务器端运算，尽量迁到浏览器端。ActiveX/Applet/Flash/.HTML5 最值得期待，她的出现必定改变整个Web世界能够让浏览器缓存的数据一定要缓存；浏览器能够处理的运算，决不放在服务器端来处理。网站架构及其技术演进Step2.1技术点前端页面缓存采用具备缓存功能的http反向代理服务器作前端页面缓存器，WebSphere

9、Edge Component (商业)网站架构及其技术演进Step2.1技术点页面片段缓存ESI(Edge Side Includes)ESI需要服务器端支持，常见apache(mod_esi)、WebSphere Appliication Server、JSP标签库(JESI)等。网站架构及其技术演进Step2.1技术点本地数据缓存需要从数据库系统和Web应用服务器两个层面考虑缓存优化技术点说明关系数据库系统（如：DB2）Query Cache策略：一般以sql为key来缓存查询结果，尽量不要拼sql，使用PreparedStatement的“？”模式sql；Query Cache大小要根据

10、数据库系统具体情况合理设置，过大只会浪费内存，参考值：128M关系数据库系统Data Buffer策略：就是数据库数据内存缓存器，其访问命中率决定数据库性能，可根据实际物理内存大小适量增大，如：DB2建议buffer值为物理内存60-80%应用服务器Cache包括：对象缓存（例如：对象线程安全，做成单例），更新频率不大数据考虑缓存（如：基表数据、配置文件信息），考虑使用线程池，对象池，连接池等常见java解决方案：WebSphere Application Server 动态缓存mapOSCacheEHCache等网站架构及其技术演进给WebSphere Application Server打

11、个广告Step2.1技术点本地数据缓存-WebSphere Application Server 动态缓存网站架构及其技术演进 动态缓存是目前大型复杂应用特别是互联网应用中提升性能和并发能力的关键技术之一。因为在很多场合有些动态页面经过一次执行后所反映的内容，在一定时间内基本上是不会经过任何变化的所以就可以在后续的访问后不用再执行而直接访问这将大大提升应用系统的的响应能力和吞吐能力，在同等的硬件条件下提供更强大的处理能力，满足企业日益增长的业务需要。高速动态缓存做为 WAS 的一个扩展服务从 5.0.2 开始就被包含在从 WAS Express 开始的各个版本。该服务可以缓存 WebSpher

12、e Command 对象、Servlet 和 JavaServer Pages（JSP）的输出，从而明显提升应用程序性能。动态高速缓存服务位于应用程序服务器 Java 虚拟机（JVM）内部，通过拦截对可高速缓存对象的调用隐式的实现了对缓存的调用，程序员甚至意识不到它的存在。下图展示了缓存命中和不命中的两种情况下系统的流程，如果缓存命中将避免执行后面复杂的商业逻辑，业务逻辑的执行时间大大缩短了。 Step2.1技术点本地数据缓存-WebSphere Application Server 动态缓存网站架构及其技术演进Step2.2技术点利用硬件的能力（大内存，SSD,高速网络等）网站架构及其技术演

13、进Step2.2技术点利用硬件的能力（大内存，SSD,高速网络等）-固态硬盘网站架构及其技术演进ProcessorsMemoryDiskSSDVery, very, very, very, very fastVery, very, very fastVery, very slow comparativelyFast 10s ns100 ns200,000 ns1,000,000 -8,000,000 nsAccess Speed1 second33 minutes 12.5 hoursHuman Time ContextStep2.2技术点WEB HTTP Server 服务器HA(Activ

14、e-StandBy)、应用服务器集群、数据库集群网站架构及其技术演进当然Web 服务器可以采用Apache Http Server/Nginx 应用服务器可以采用 WAS 数据库服务器可以采用DB2 PureScaleStep3增加机器做WEB HTTP Server 服务器集群、数据库读写分离优点：Web HTTP Server 集群能够接入更多的并发请求，数据库扩展更好（读写分离）；从而提升系统整体性能缺点：读写分离，增加程序难度，架构变复杂，维护难度增加技术点：负载均衡、DAL、数据库读写分离网站架构及其技术演进Step3技术点Web HTTP Server 集群负载均衡类型说明DNS负

15、载均衡实现简单、有Cache缺乏灵活性，但对分区域（如构建CDN方案）访问简单有效反向代理软件HAProxy、Nginx、Apache、Lighttpd等硬件产品F5、NetScaler等LVS(Linux Virtual Server)/SMART Client自己写代码某些情况下简单有效网站架构及其技术演进Step3技术点数据库读写分离及DAL读写分离逻辑分批负载均衡失效转移（failover）数据库分区透明支持两大实现模式：独立Proxy服务器；单独API库文件各个数据库厂商都有自己复制方案(例如基于日志实时复制）常见通用方案,CDC网站架构及其技术演进网站架构及其技术演进Step4CD

16、N、分布式缓存、分库、NoSQL、重新思考硬件体系、大数据优点：异地缓存有效解决不同地方用户访问过慢的问题；分库策略带来网站性能整体提升等等缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，架构开始臃肿了技术点：CDN、分布式缓存、Shard分库、NoSQL、重新思考硬件体系、大数据Step4技术点CDNCDN(Content Delivery Network)内容分发网络将网站的内容分发到最接近用户的网络“边缘”，使用户可以就近获取，从而解决互联网网络拥挤的状况，提高用户访问的响应速度。适合静态内容很多（如：静态页面、图片、视频等）及页面内容实时性要求不高的网站，如：新闻类门户网站

17、CDN构建可以做的很简单，也可以很复杂，主要根据自己网站实际情况而定网站架构及其技术演进WebSphere Edge ComponentStep4技术点分布式缓存本地缓存性能优秀，但容量有限，无伸缩性采用分布式缓存方案突破容量限制，具备良好伸缩性；但分布式涉及远程网络通信消耗其性能本地缓存来得优秀，并可涉及节点状态维护及数据复制问题，其稳定性和可靠性是个挑战。目前流行分布式缓存方案：memcached、membase、redis,WebSphere extreme Scale 等，基本上当前的NoSQL方案都可以用来做分布式缓存方案网站架构及其技术演进WebSphere eXtreme Sca

18、le网站架构及其技术演进Step4技术点分布式缓存DB2 Not SQL：KV网站架构及其技术演进Step4技术点分布式缓存Step4技术点分库读写分离（简单有效，前面已介绍）垂直分区（功能域）和水平切分网站架构及其技术演进用户信息产品信息交易流水信息客户信息业务类型信息功能域用户信息1水平切分（sharding）交易流水信息1交易流水信息2Step4技术点分库网站架构及其技术演进垂直分区良好的松耦合的模块化设计是垂直分库的前提网站架构及其技术演进Step4技术点分库水平分区（Shard）分片Key识别（划分检索依据）是关键是否还有其它招？用NoSql数据库部分替换关系数据库Step4技术点N

19、oSQL网站架构及其技术演进随着Web 的发展，电子商务和社交计算的兴起所引起的企业里不受控的非结构化并且面向信息的数据大爆炸和那些超大规模和高并发的应用场景下，该如何应对呢？企业确实不需要关系型数据库来管理这些数据，因为关系型数据库的特点决定了它不适用于这些数据的性质和使用方式。关系型数据库针对这些信息来说确实不是银弹或者称之为万金油的解决方法，最关键的是关系型数据库已经显得力不从心，暴露了很多难以克服的问题：（1）对数据库高并发读写的需求（2）对海量数据的高效率存储和访问的需求（3）对数据库的高可扩展性和高可用性的需求。所以我们需要分布式的非关系型数据库（即NOSQL，它的意思是对于我们的

20、应用类型，信息类型Only SQL是不够的，所以需要Not Only SQL）。Step4技术点NoSQL网站架构及其技术演进 NOSQL is simply Not Only SQL!Step4技术点NoSQL网站架构及其技术演进NOSQL特点它们不是关系型数据库，它也不是什么类型应用都能用有自己的使用场景它们可以处理超大量的数据它们运行在较为便宜的服务器集群上它们打破了性能瓶颈没有过多的操作。缺点：现在基本上都是开源产品还不是特别成熟。Step4技术点NoSQL网站架构及其技术演进NoSQL支持率调查报告网站架构及其技术演进Step4技术点NoSQLStep4技术点重新思考硬件体系网站架构

21、及其技术演进到这里机器越来越多了，我们需要考虑采用高密度堆叠服务器，服务器低功耗、高性能、强调高温化运行了，以降低占用空间、降低PUE值。 向Google，FaceBook学习。在国内的互联网企业巨头：百度、阿里已经在这么做了。服务器 CPU：x86/ ARM DRAM DISK:HDD/SSD Architect：高密度设计Racks（机柜） 服务器数量越多越好 以太网交换（光纤)/或者Infiniband网络Cluster(服务器集群） Step4技术点重新思考硬件体系-虚拟化网站架构及其技术演进弹性快速提供服务器资源灾难恢复高可用性自动化提高服务器利用率省电省空间Step4技术点重新思考

22、硬件体系网站架构及其技术演进打个广告推销下IBM 的PureApplication SystemStep4技术点重新思考硬件体系网站架构及其技术演进1 U2 U3 U4 U5 U6 U7 U8 U9 U10U11U12U13U14U15U16U17U18U19U20U21U22U23U24U25U26U27U28U29U30U31U32U33U34U35U36U37U38U39U40U41U42UV7000 ControllerV7000 ExpansionV7000 ControllerV7000 ExpansionBNT 64 PT Enet SW BNT 64 PT Enet SW Ca

23、ble ingress / egressPDUPDUPDUPDUIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel Compu

24、teIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeMGMTMGMTIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeIntel Compute Intel ComputeMGMTMGMTCable ingress / egressIntel 计算节点Intel p

25、rocessor (Sandy Bridge)2.6 GHz 8C Intel processor, 115 W20 MB L3 cache 2x 4 Port 10 GbE 2x 2 Port 8 Gb/s FC交换机Common Management Module10Gb Ethernet Switch1Gb FC SwitchVM 管理节点主控制器BLADE Network Technologies Top of Rack SwitchesCustomer Data Center & Rack-to-rack communicationsPureApplication System 管理

26、节点V7000 磁盘扩展槽Per enclosure:SAS SSDSAS HDD存储控制器IBM Storwize Disk SystemSSD per enclosureHDD per enclosureStep4技术点大数据DFS、Map/Reduce、Key-Value DBDFS分布式文件系统，如：HDFSGFSTFSGPFS-SNC等Map/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。Key-Value DB，也作为NoSQL解决方案，如：BigTableTairHbase HyperTable等提供完整解决方案： Google(GFS|Map/Redu

27、ce|BigTable) Apache Hadoop(HDFS|Map/Reduce|HBase) IBM BigInsights(GPFS-SNC|Map/Reduce|Hbase）网站架构及其技术演进网站架构及其技术演进到这里我们必须要明白的是 建设一个大型网站架构是一个非常复杂的工作；对整个技术Team的技术技能是有很高要求的。技术Team 的技术氛围要好、少忽悠、多干实事 极致性能需要架构的力量和代码质量的双重组合，缺一不可。并且不存在万能的架构 最重要的是“人”即真正的人才而不是“砖家”。淘宝案例简介52大淘宝技术架构演进V1.0 2003.5 2004.1V1.1 2004.1 2

28、004.5V2.0 2004.2-2005.03V2.1 2004.10 2007.01淘宝案例简介大淘宝技术架构演进V2.2 2006.10 2007.12V3.0 2007.12 -淘宝案例简介大淘宝技术架构演进淘宝案例简介大淘宝的挑战淘宝案例简介大淘宝的挑战 这些数字导致淘宝面临的就是大并发、大数据的挑战,淘宝所面临的挑战一般都是在线用户数都是千万级别、数据量是100PB左右。即非功能性需求（高性能、高可靠性、高效的自动化运维）是淘宝最关键的需求是永恒的挑战。这种挑战导致现在的淘宝必须依赖自己的大量的高质量核心技术人员进行定制开发才行。采用商用的系统是不可能的，因为商用的系统在这种量级的

29、需求面前没有成功案例，即现在的淘宝系统是不可能简单地采用现在在企业级应用所大量使用的数据库集群技术、应用服务器集群技术、高端机器、高端存储就能够解决。 在以前，淘宝的服务器机器一般都是选用IBM 的服务器，特别是数据库采用的是IBM 小机，存储采用的EMC高端存储、数据库采用Oracle DB RAC。在2008年之前，是能够满足淘宝的需求的，但是这几年淘宝业务、用户数的爆发性增长导致对系统的压力太大（高并发、大数据）。如果还是采用传统的方式，这个成本是不可接受的（即几万台IBM服务器、存储100PB数据的ECM存储、Oracle 数据库的License的成本不可接受；并且将来几年大淘宝的服务器数量突破10万台、数量突破1000PB 指日可待），并且。所以淘宝几年前开始了去IOE运动，即消除IBM、Oracle、EMC；现在淘宝的核心系统已经基本完成去IOE了。 淘宝案例简介大淘宝现在的技术架构-系统框架示意图淘宝案例简介大淘宝现在的技术架构-软件基础设施规划淘宝案例简介如上两张图所示，淘宝的核心系统是及其复杂的，并且是没有可以采用的