大型网站建设架构设计与实践探讨.ppt

《大型网站建设架构设计与实践探讨.ppt》由会员分享，可在线阅读，更多相关《大型网站建设架构设计与实践探讨.ppt（65页珍藏版）》请在三一文库上搜索。

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

2、网站、php网站、jsp网站、Asp. net网站等； 2、根据网站的用途分类：例如门户网站（综合网站）、行业网站、娱乐网站等； 3、根据网站的功能分类：例如单一网站（企业网站）、多功能网站（网络商城）等。 4、根据网站的持有者分类：例如个人网站、商业网站、政府网站等。 5、根据网站的商业目的分类：营利型网站（行业网站、论坛）、非营利性型网站（企业网站、政府网站） 我们这按照对现在大众使用网络的应用类型和生活服务的习惯进行简单性的几种大致分类，不从专业角度的进行分类.,大型网站架构的目标与挑战,网站的主要分类,1.综合门户( )。 技术特点：以静态内容占绝大部分，动态内容较少,大型网站架构的

3、目标与挑战,网站的主要分类,2.娱乐：在线视频(xunlei,youku）。 技术特点：以静态内容占大部分，动态内容也多，对网站接入带宽要求高,大型网站架构的目标与挑战,网站的主要分类,2.娱乐：在线游戏(QQGame）。 技术特点：以客户端技术和相应的后台技术为核心（网站仅仅是一个服务手段），网页游戏现在还不是主流,大型网站架构的目标与挑战,网站的主要分类,3.办公和生活服务：在线邮件(QQ mail，163 mail）、网盘 技术特点：动态内容为绝大部分，功能很多基本上涵盖了大众在办公和生活服务方方面面,大型网站架构的目标与挑战,网站的主要分类,4.搜索（Google Search，Bai

4、du Search） 技术特点：搜索界面简单,基本上全是动态内容，但是技术极其复杂,大型网站架构的目标与挑战,网站的主要分类,5.电子商务（淘宝） 技术特点：动态内容，静态内容也多，功能多，技术实现极其复杂,大型网站架构的目标与挑战,网站的主要分类,6.SNS（新浪微博、QQZone 、FaceBook） 技术特点：动态内容占绝大部，功能多，技术实现极其复杂,大型网站架构的目标与挑战,何谓“大型”网站？,大型网站架构的目标与挑战,没有统一的判断标准，流量大小是一个非常重要指标；即UV,PV,独立IP,日均流量至少IP1,000,000 才能算大型网站,何谓“大型”网站？,大型网站架构的目标与挑

5、战,并且 网站内容 是否“动态”才是关键,网站架构目标与挑战,每个目标背后面临着技术、设计、维护等诸多方面的挑战。 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。,负载均衡 数据备份 异地容灾 。,高速缓存 并行计算 异地镜像 。,开发框架 多层设计 业务分割 。,大型网站架构的目标与挑战,大数据、大并发,并且对于一个大型网站来说，大并发、大数据量的高性能和可靠性的架构设计是最重要的；只要这个架构设计和相应的代码质量较好就可以满足所有的不同类型大型网站的要求。并且在国内外互联网领域 出名的不同类型的大型网站为了支撑大并发、大数据量的高性能和可靠性的思想都

6、是比较类似的,大型网站架构的目标与挑战,网站架构目标与挑战,SoLoMo：社交+本地化+移动,网站架构及其技术演进,Step1Web动静态资源分离及其与DB物理分离,优点：“简单”、安全性提高 缺点：存在单点，谈不上高可用性（high availability架构目标） 技术点：应用设计要保证可扩展（framework很重要Spring/Beetle）、Web Server动/静态资源分离 Web Server（ApacheNginxIISWAS）、 Database Server（RedisDB2）,Step1技术点Web动静态资源分离,网站架构及其技术演进,img,doc,js,css等静

7、态资源使用单独的Web HTTP Server处理请求 动态页面静态化处理,Step2.1 采取缓存处理,优点：简单有效、维护方便 缺点：依然存在单点 技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存,减少对网站的访问,减少对Web应用服务器的请求,减少对数据库的查询,减少文件系统I/O操作,网站架构及其技术演进,Step2.1技术点客户端（浏览器）缓存,能够让浏览器缓存的数据一定要缓存；浏览器能够处理的运算，决不放在服务器端来处理。,网站架构及其技术演进,Step2.1技术点前端页面缓存,采用具备缓存功能的http反向代理服务器作前端页面缓存器， WebSp

8、here Edge Component (商业),网站架构及其技术演进,Step2.1技术点页面片段缓存ESI(Edge Side Includes),ESI需要服务器端支持，常见apache(mod_esi)、WebSphere Appliication Server、 JSP标签库(JESI)等。,网站架构及其技术演进,Step2.1技术点本地数据缓存,需要从数据库系统和Web应用服务器两个层面考虑缓存优化,网站架构及其技术演进,给WebSphere Application Server打个广告,Step2.1技术点本地数据缓存-WebSphere Application Server 动

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

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

11、集群功能；我们为什么不利用呢？,网站架构及其技术演进,Step2.2技术点利用硬件的能力（大内存，SSD,高速网络等）,网站架构及其技术演进,Step2.2技术点利用硬件的能力（大内存，SSD,高速网络等）-固态硬盘,网站架构及其技术演进,Processors,Memory,Disk,SSD,Very, very, very, very, very fast,Very, very, very fast,Very, very slow comparatively,Fast,Step2.2技术点利用硬件的能力（大内存，SSD,高速网络等）-高速网路,网站架构及其技术演进,1.万兆以太网 2.Inf

12、iniband 网络，此网络技术特别适合于关系数据库集群机制中（例如DB2 PureScale）。,Step2.2技术点WEB HTTP Server 服务器HA(Active-StandBy)、应用服务器集群、数据库集群,网站架构及其技术演进,当然Web 服务器可以采用Apache Http Server/Nginx 应用服务器可以采用 WAS 数据库服务器可以采用DB2 PureScale,Step3增加机器做WEB HTTP Server 服务器集群、数据库读写分离,优点：Web HTTP Server 集群能够接入更多的并发请求，数据库扩展更好（读写分离）；从而提升系统整体性能 缺点：

13、读写分离，增加程序难度，架构变复杂，维护难度增加 技术点：负载均衡、DAL、数据库读写分离,网站架构及其技术演进,Step3技术点Web HTTP Server 集群负载均衡,网站架构及其技术演进,Step3技术点数据库读写分离及DAL,读写分离逻辑分批 负载均衡 失效转移（failover） 数据库分区透明支持 两大实现模式：独立Proxy服务器；单独API库文件,各个数据库厂商都有自己复制方案(例如基于日志实时复制）常见通用方案,CDC,网站架构及其技术演进,网站架构及其技术演进,Step4CDN、分布式缓存、分库、NoSQL、重新思考硬件体系、大数据,优点：异地缓存有效解决不同地方用户访

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

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

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

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

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

19、4技术点重新思考硬件体系,网站架构及其技术演进,到这里机器越来越多了，我们需要考虑采用高密度堆叠服务器，服务器低功耗、高性能、强调高温化运行了，以降低占用空间、降低PUE值。 向Google，FaceBook学习。在国内的互联网企业巨头：百度、阿里已经在这么做了。,Step4技术点重新思考硬件体系-虚拟化,网站架构及其技术演进,弹性 快速提供服务器资源 灾难恢复 高可用性 自动化 提高服务器利用率 省电 省空间,Step4技术点重新思考硬件体系,网站架构及其技术演进,打个广告推销下IBM 的 PureApplication System,Step4技术点重新思考硬件体系,网站架构及其技术演进,

20、Intel 计算节点 Intel processor (Sandy Bridge) 2.6 GHz 8C Intel processor, 115 W 20 MB L3 cache 2x 4 Port 10 GbE 2x 2 Port 8 Gb/s FC,交换机 Common Management Module 10Gb Ethernet Switch 1Gb FC Switch,VM 管理节点,主控制器 BLADE Network Technologies Top of Rack Switches Customer Data Center & Rack-to-rack communicati

21、ons,PureApplication System 管理节点,V7000 磁盘扩展槽 Per enclosure: SAS SSD SAS HDD,存储控制器 IBM Storwize Disk System SSD per enclosure HDD per enclosure,Step4技术点大数据DFS、Map/Reduce、Key-Value DB,DFS分布式文件系统，如：HDFSGFSTFSGPFS-SNC等 Map/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。 Key-Value DB，也作为NoSQL解决方案，如：BigTableTairHbase

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

23、案例简介,52,大淘宝技术架构演进,V1.0 2003.5 2004.1,V1.1 2004.1 2004.5,V2.0 2004.2-2005.03,V2.1 2004.10 2007.01,淘宝案例简介,大淘宝技术架构演进,V2.2 2006.10 2007.12,V3.0 2007.12 -,淘宝案例简介,大淘宝技术架构演进,淘宝案例简介,大淘宝的挑战,淘宝案例简介,大淘宝的挑战,这些数字导致淘宝面临的就是大并发、大数据的挑战,淘宝所面临的挑战一般都是在线用户数都是千万级别、数据量是100PB左右。即非功能性需求（高性能、高可靠性、高效的自动化运维）是淘宝最关键的需求是永恒的挑战。这种挑

24、战导致现在的淘宝必须依赖自己的大量的高质量核心技术人员进行定制开发才行。采用商用的系统是不可能的，因为商用的系统在这种量级的需求面前没有成功案例，即现在的淘宝系统是不可能简单地采用现在在企业级应用所大量使用的数据库集群技术、应用服务器集群技术、高端机器、高端存储就能够解决。 在以前，淘宝的服务器机器一般都是选用IBM 的服务器，特别是数据库采用的是IBM 小机，存储采用的EMC高端存储、数据库采用Oracle DB RAC。在2008年之前，是能够满足淘宝的需求的，但是这几年淘宝业务、用户数的爆发性增长导致对系统的压力太大（高并发、大数据）。如果还是采用传统的方式，这个成本是不可接受的（即几万

25、台IBM服务器、存储100PB数据的ECM存储、Oracle 数据库的License的成本不可接受；并且将来几年大淘宝的服务器数量突破10万台、数量突破1000PB 指日可待），并且。所以淘宝几年前开始了去IOE运动，即消除IBM、Oracle、EMC；现在淘宝的核心系统已经基本完成去IOE了。,淘宝案例简介,大淘宝现在的技术架构-系统框架示意图,淘宝案例简介,大淘宝现在的技术架构-软件基础设施规划,淘宝案例简介,如上两张图所示，淘宝的核心系统是及其复杂的，并且是没有可以采用的商用软件能够支撑业务的挑战（即大并发、大数据、业务需求变化极快）。所以现在淘宝走上了从服务器都自己设计、底层软件（数据

26、库、中间件、文件系统等）都是采用开源软件进行修改和自我研发、监控运维系统自我开发的道路，从而把IT 投入的成本 最大部分放在了需要大量的高质量核心技术人员人工成本上，而不是把钱投入到购买商用软硬件上。,大淘宝的技术支撑之路,淘宝案例简介,CDN：世界上流量最大的、面向图片的CDN系统 基于开源软件LVS+Haproxy+Squid+Bind上开发的CDN系统 现有103节点，双12支持了856Gbps实际流量；约5000台服务器 今年会建设到2400Gbps的承载能力 TFS：自主开发的分布式对象存储系统 可存储容量6.2P，实际使用4.06P；今年会建设到12P TAIR：淘宝的分布式缓存和

27、K/V存储 集成了开源的Redis和LevelDB存储引擎 提供跨机房容灾的解决方案 OceanBase：淘宝的分布式数据库系统 支持千亿条记录级别的数据库、支持事务,大淘宝的技术支撑之路-所采用的软件（开源和自我研发）,淘宝案例简介,海量数据：采用开源的Hadoop平台 现在单一集群到2500台服务器的规模 系统可存储容量为47.02PB，已使用32.47PB，历史数据为压缩存储 每天新增原始数据量为50T左右，存储净增量约为36T 每天运行的作业数为10万以上，每日处理数据为2.5PB 核心数据库：采用开源的MySQL，加上高速的非易失存储，以及多层级的系统优化 服务器平台：Nginx 部

28、署200多个应用，约3000台机器；完成TMD等重要防攻击软件，Tengine项目开源 底层的支撑软件： 在OpenJDK基础上开发和维护TaobaoJVM 在Red Hat基础上维护自己的Linux内核 在Sheepdog上实现了KVM的虚拟化弹性计算平台 在LVS基础上实现负载均衡解决方案 用开源软件实现了高流量的网络镜像项目,大淘宝的技术支撑之路-所采用的软件（开源和自我研发）,淘宝案例简介,淘宝自开源以来，共开源自主开发软件40余个 涵盖前端、后端、数据库、文件系统、硬件等多方面 对淘宝使用的若干项目贡献了代码,大淘宝的技术支撑之路-所采用的软件（开源和自我研发）,淘宝案例简介,大淘宝的技术支撑之路-定制的低功耗服务器,淘宝案例简介,大淘宝的技术支撑之路-低功耗服务器开源,开源网站http:/www.greencompute.org/,