“大型”网站技术架构探讨 余浩东 2011年6月

大型网站架构的目标与挑战 网站架构演变及其技术脉络 架构设计理论与原则 讨论及总结

大型网站架构的目标与挑战 ■何谓“大型”网站？ 网站 日均流量[IP/PV] www.hao123.com 没有统一的判断标准，流量大小是一个重要指标 网站 日均流量[IP/PV] www.hao123.com IP≈ 5,972,587 PV≈ 9,376,962 www.facebook.com IP≈229,680,000 PV≈2,955,981,600 www.sina.com.cn IP≈25,680,000 PV≈222,132,000 www.tianya.cn IP≈5,532,000 PV≈25,723,800 www.pingan.com IP≈300,000 PV≈747,000 那是不是流量大就是大型网站呢？Google Analytics 日均流量至少IP>1,000,000才算大型网站

大型网站架构的目标与挑战 ■何谓“大型”网站？ 网站内容是否“动态”才是关键

大型网站架构的目标与挑战 ■网站架构目标与挑战 负载均衡 数据备份 异地容灾 。。。 高速缓存 并行计算 异地镜像 。。。 开发框架 追求这3个目标，是网站闹腾的根源 开发框架 多层设计 业务分割 。。。 每个目标背后面临着技术、设计、维护等诸多方面的挑战。 而目标本身的期望值也会根据实际情况进行调整，这也意味着网站架构建设是个不断调整的过程。

大型网站架构的目标与挑战 网站架构演变及其技术脉络 架构设计理论与原则 讨论及总结

网站架构演变及其技术脉络 ■[Step1]Web动静态资源分离及其与DB物理分离 优点：“简单”、安全性提高 一般地，本文提到的物理服务器都是泛指pc级物理服务器；Web Server泛指HTTP服务器和应用服务器综合体 对于一个试水性网站来说为了节约成本，Web Server和DB Server都放在同一台pc Server服务器上是常见的事情。 当网站访问量增大，cpu处理能力是瓶颈的时候，通过把web Server和Db Server简单物理分开的，效果明显 优点：“简单”、安全性提高 缺点：存在单点，谈不上高可用性（high availability架构目标） 技术点：应用设计要保证可扩展（framework很重要Spring/Beetle）、Web Server动/静态资源分离 Web Server（Apache\Nginx\IIS\JBoss…）、 Database Server（Mysql\Oracle\Redis…）

网站架构演变及其技术脉络 ■[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世界 有时间还可以吹一下idempotent，etag(http://www.infoq.com/cn/articles/etags) 能够让浏览器缓存的数据一定要缓存；浏览器能够处理的运算，决不放在服务器端来处理。

网站架构演变及其技术脉络 ■[Step2]技术点—前端页面缓存 采用具备缓存功能的http反向代理服务器作前端页面缓存器， 访客向网站发出访问请求,由前端页面缓存器负担原服务器的处理进程做出响应,获取原服务器的相应网页内容,将其储存在自身的内存中,与 此同时,传送给访客这一缓存的内容;如有另一访客也请求访问之前的相同内容,前端页面缓存器毋须再次获取原服务器上的相应内容,而直接从自身的内存中获取,将这一内容传送给访客。反之,前端页面缓存器也可缓存访客的GET和POST请求。 　　访客实际面对的是前端页面缓存器,与网站之间的通讯完全由前端页面缓存器反向代理,而非原服务器直接响应访客,这将大大加快访客上网流畅度,有效提升访问量,显著降低带宽占用,减轻原始服务器的繁忙度,加快响应速度,毋须不停地购置大内存,大硬盘,扩容电力设施为服务器端节省成本。 采用具备缓存功能的http反向代理服务器作前端页面缓存器， Varnish\Squid\Ncache\AiCache(商业)…【硬件F5】

网站架构演变及其技术脉络 ■[Step2]技术点—页面片段缓存ESI(Edge Side Includes) ESI是一个基于XML的标记语言，目的是在HTTP中组装各种资源。在实际环境中，一个动态生成的页面，当中可能只有少量的内容是频繁变化的或是个性化的，对于传统的Cache服务器来说，为了能够保证页面的时效性，却由于页面中这些少量的动态内容而无法将整个页面进行缓存。ESI通过使用简单的标记语言来对那些可以缓存和不能缓存的网页中的内容片断进行描述，每个网页都被划分成不同的小部分分别赋予不同的缓存控制策略，使Cache服务器可以根据这些策略在将完整的网页发送给用户之前将不同的小部分动态地组合在一起。通过这种控制，可以有效地减少从服务器抓取整个页面的次数，而只用从原服务器中提取少量的不能缓存的片断，因此可以有效降低原服务器的负载，同时提高用户访问的响应时间。 ESI需要服务器端支持，常见apache(mod_esi)、WebLogic、 JSP标签库(JESI)等。

网站架构演变及其技术脉络 ■[Step2]技术点—本地数据缓存 技术点说明 关系数据库系统（如：Oracle\MySql）Query Cache策略：一般以sql为key来缓存查询结果，尽量不要拼sql，使用PreparedStatement的“？”模式sql；Query Cache大小要根据数据库系统具体情况合理设置，过大只会浪费内存，参考值：128M 关系数据库系统Data Buffer策略：就是数据库数据内存缓存器，其访问命中率决定数据库性能，可根据实际物理内存大小适量增大，如：MySql建议buffer值为物理内存60-80% 应用服务器Cache包括：对象缓存（例如：对象线程安全，做成单例），更新频率不大数据考虑缓存（如：基表数据、配置文件信息），考虑使用线程池，对象池，连接池等 常见java解决方案：map\OSCache\EHCache等 常见缓存算法 贝莱蒂算法（Belady's Algorithm） 最有效率的缓存算法会丢掉未来最长时间内不使用的数据。这种理想情况被称作贝莱蒂最优算法或者千里眼算法。由于要预计数据要多久后才被使用基本上是不可能的，所以这种算法没有实际的可操作性。它的作用在于为不同的缓存算法订立一个优劣标准。 最近最少使用算法(LRU，Least Recently Used） 最近最少使用算法的思路是丢弃近段时间内最少被使用的数据。要实现这种算法需要跟踪数据何时被使用，用这种方法来筛选去近一段时间被最少使用次数的数据其代价往往是昂贵的。它的实现往往是通过在缓存数据上设立时间标志位，用以跟踪最近最少被使用的缓存数据。一个数据每被使用一次，其他数据的时间标志位数值就要增加。 最近最频繁使用算法（MRU，Most Recently Used） 最近最频繁使用算法和最近最少使用算法相反，它会首先丢弃最近最常使用的数据。有观点认为“当文件在顺序访问时，MRU算法是最佳选择”，抱有这样观点人也认为在反复进行大量数据的随机存储时，MRU因为倾向于保留旧的数据，随意比LRU算法有着更高的命中率。MRU算法经常用于旧的数据更常被用到的情况下。 伪LRU算法（PLRU，Pseudo-LRU） 因为缓存有着大量的关联性，LRU算法实现的代价往往比较昂贵。如果实际情况在丢弃任一个最近最少使用的数据就能满足，那么伪LRU算法就派上用场了，它为每一个缓存数据设立一个标志位就可以工作。 需要从数据库系统和Web应用服务器两个层面考虑缓存优化

网站架构演变及其技术脉络 ■[Step3]增加机器做HA、数据库读写分离 优点：增加服务器和HA机制，系统性能及可用性得到保证 网站反馈不错，业务发展比较顺利。终于有傻逼VC投钱了，银弹充足，就必须考虑网站可用性及服务容量冗余性问题。增加机器，搞HA是必然选择了 优点：增加服务器和HA机制，系统性能及可用性得到保证 缺点：读写分离，增加程序难度，架构变复杂，维护难度增加 技术点：负载均衡、DAL、数据库读写分离

网站架构演变及其技术脉络 Virtual Server via NAT（VS-NAT） ■[Step3]技术点—负载均衡 类型 说明 DNS负载均衡 实现简单、有Cache缺乏灵活性，但对分区域（如构建CDN方案）访问简单有效 反向代理软件 HAProxy、Nginx、Apache、Lighttpd等 硬件产品 F5、NetScaler等 LVS(Linux Virtual Server) http://www.linuxvirtualserver.org/ SMART Client 自己写代码某些情况下简单有效 DNS负载均衡\反向代理负载均衡\直接路由\F5硬件 LVS（LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序） Virtual Server via NAT（VS-NAT） 用地址翻译实现虚拟服务器。地址转换器有能被外界访问到的合法IP地址，它修改来自专有网络的流出包的地址。外界看起来包是来自地址转换器本身，当外界包送到转换器时，它能判断出应该将包送到内部网的哪个节点。优点是节省IP 地址，能对内部进行伪装；缺点是效率低，因为返回给请求方的流量经过转换器。 Virtual Server via IP Tunneling （VS-TUN） 用IP隧道技术实现虚拟服务器。这种方式是在集群的节点不在同一个网段时可用的转发机制，是将IP包封装在其他网络流量中的方法。为了安全的考虑，应该使用隧道技术中的VPN，也可使用租用专线。 集群所能提供的服务是基于TCP/IP的Web服务、Mail服务、News服务、DNS服务、Proxy服务器等等． Virtual Server via Direct Routing（VS-DR） 用直接路由技术实现虚拟服务器。当参与集群的计算机和作为控制管理的计算机在同一个网段时可以用此法，控制管理的计算机接收到请求包时直接送到参与集群的节点。优点是返回给客户的流量不经过控制主机，速度快开销少。

网站架构演变及其技术脉络 ■[Step3]技术点—数据库读写分离及DAL ■读写分离逻辑分批 ■负载均衡 ■失效转移（failover） ■数据库分区透明支持 ■两大实现模式：独立Proxy服务器；单独API库文件 各个关系数据库厂商针对dal及replication都有自己方案 独立的DAL Proxy服务器 MySQL: mysqlproxy,Amoeba PostgreSQL: PL/Proxy (Skype) DAL API Java: Hibernate Shard,Ibatis Shard,HiveDB,Guzz Python: Pyshards 各个数据库厂商都有自己复制方案 常见通用方案：ETL、GoldenGate TJS…

网站架构演变及其技术脉络 ■[Step4]CDN、分布式缓存、分库 网站业务发展迅速，数据量大幅增大是当前最大的挑战，用户分散各地区，某些地方用户访问响应很慢，影响体验和业务发展 同时，由于数据量过大，数据缓存在本地内存已经不现实，分布式缓存是必然选择了 优点：异地缓存有效解决不同地方用户访问过慢的问题；分库策略带来网站性能整体提升 缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，架构开始臃肿了 技术点：CDN、分布式缓存、Shard分库

网站架构演变及其技术脉络 ■[Step4]技术点—CDN CDN(Content Delivery Network)内容分发网络 CDN的全称是Content Delivery Network，即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户可以就近取得所需的内容，解决 Internet网络拥挤的状况，提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提高速度。 CDN(Content Delivery Network)内容分发网络 将网站的内容分发到最接近用户的网络“边缘”，使用户可以就近获取，从而解决互联网网络拥挤的状况，提高用户访问的响应速度。 适合静态内容很多（如：静态页面、图片、视频等）及页面内容实时性要求不高的网站，如：新闻类门户网站 CDN构建可以做的很简单，也可以很复杂，主要根据自己网站实际情况而定

网站架构演变及其技术脉络 ■[Step4]技术点—分布式缓存 本地缓存性能优秀，但容量有限，无伸缩性 本地缓存vs分布式缓存，为什么要搞分布式缓存？ 为什么分布式缓存器都是采取Key-Value形式? 本地缓存性能优秀，但容量有限，无伸缩性 采用分布式缓存方案突破容量限制，具备良好伸缩性；但分布式涉及远程网络通信消耗其性能本地缓存来得优秀，并可涉及节点状态维护及数据复制问题，其稳定性和可靠性是个挑战。 目前流行分布式缓存方案：memcached、membase、redis等，基本上当前的NoSQL方案都可以用来做分布式缓存方案

网站架构演变及其技术脉络 ■[Step4]技术点—分库 读写分离（简单有效，前面已介绍） 垂直分区 良好的松耦合的模块化设计是垂直分库的前提 垂直分库后，各模块数据之间如何关联查询？垂直分库前提是良好的松耦合的模块化设计 良好的松耦合的模块化设计是垂直分库的前提

网站架构演变及其技术脉络 ■[Step4]技术点—分库 水平分区（Shard） 分片Key识别（划分检索依据）是关键 是否还有其它招？用NoSql数据库部分替换关系数据库

网站架构演变及其技术脉络 ■[Step5]多个数据中心，向分布式存储和计算的架构体系迈进 某天突然发现网站可以成为第2个facebook了，用户过亿，数据量达到pb级。网站性能不是通过简单增加硬件服务器就能够满足的。（机房放满都不够）这样就不得面对以下选择：既然1个机房都容不下了（可看做一个数据中心），那么就建多几个（多个数据中心）；建立数据中心，无疑就需要更多的机器和存储，考虑天价的成本的，利用现有廉价的存储和机器，参照google的GFS、Map/Reduce、Bigtable技术模式搭建分布式存储和计算的架构就是必然选择了。 优点：多数据中心，带来更高质量区域服务体验；分布式存储及计算架构有效解决pb级数据量存储、检索及计算性能问题 缺点：架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高 技术点：分布式文件系统、Map/Reduce、Key-Value存储

网站架构演变及其技术脉络 ■[Step5]技术点—向分布式存储计算解决方案[DFS、Map/Reduce、Key-Value DB] DFS提供了一个全局命名空间的高可用（通过跨机器（和跨机架）的文件数据复制来达到高可用性，免受传统文件存储系统无法避免的许多失败的影响）文件系统，解决高容量数据高效、可靠存储问题；Map/Reduce的计算框架，它与DFS紧密协作，帮助处理收集到的海量数据;Key-Value DB代替传统的数据库，通过一些主键来组织海量数据，并实现高效的查询。 DFS分布式文件系统，如：Lustre\HDFS\GFS\TFS\FreeNas等 Map/Reduce算法（计算框架），基本上现有NoSQL数据库中都支持此算法。 Key-Value DB，也作为NoSQL解决方案，如：BigTable\Tair\Hbase\ HyperTable等 提供完整解决方案： Google(GFS|Map/Reduce|BigTable) Apache Hadoop(HDFS|Map/Reduce|HBase)

大型网站架构的目标与挑战 网站架构演变及其技术脉络 架构设计理论与原则 讨论及总结

架构设计理论与原则 ■网站架构设计的精神食粮 从网站架构演变过程来看，涉及到n多的技术点及设计模式，为什么要用这些技术？为什么这样设计？困惑了？ 所以我们需要理论来支撑和指导我们架构设计工作

架构设计理论与原则 ■关于数据一致性—ACID vs BASE ACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。 问题：ACID原则适用于互联网应用吗？可用性似乎比一致性重要些 软状态 在不过分追求数据一致性（强一致性）前提下可考虑软状态策略，例如把数据缓存（State）在客户端一段时间，过后若没有新请求的话，就清除此缓存（Soft） BASE（ Basically Available 、 Soft state 、 Eventually consistent ）策略 基本可用 数据能够保证80%一致性就够了，剩下20%就不要过于纠结了。可参考八二定律 Eric Brewer,一位加州大学伯克利分校的教授 http://www.cs.berkeley.edu/~brewer/ 最终一致性 在某一段短时间内允许数据不一致，但经过一段较长时间，等所有节点上数据的拷贝都整合在一起的时候，数据会最终达到完全一致 BASE策略与ACID不同，其基本思想就是通过牺牲强一致性，以获得更好的可用性或可靠性

架构设计理论与原则 ■关于分布式系统—CAP理论 可用性 确保客户访问数据时可得到响应。不强调各个节点上数据要保持一致性。 一致性 分布式系统中，数据一般会存储在不同节点，一致性就是要保证对数据操作的原子性 CAP对开发分布式系统和选型都有重大指导意义； 分区容忍性 数据分区存储后，即使部分分区组件不可用，其施加的操作也能够完成 CAP理论指出：一个分布式系统不可能同时满足一致性、可用性 和分区容忍性这三项需求，最多只能同时满足其中两个。

架构设计理论与原则 ■无共享架构（Share Nothing Architecture） http://en.wikipedia.org/wiki/Shared_nothing_architecture SNA的主要是认为在一个集群分布式计算环境中，若Session状态维护在各个节点服务器上，为了保证状态一致性，节点间Session数据需要互相拷贝同步，严重影响性能。

架构设计理论与原则 ■ED-SOA架构 ■架构进化与退化--奥卡姆剃刀原理 ED-SOA，事件驱动，面向服务架构 切勿浪费较多东西去做用较少的东西同样可以做好的事情 进化—寻找最适合的；退化—简化不必要的 简单就好，慎防过渡设计

架构设计理论与原则 ■考量成本，先硬后软原则 很说明问题的漫画

大型网站架构的目标与挑战 网站架构演变及其技术脉络 架构设计理论与原则 讨论及总结

讨论及总结 ■大型网站架构是怎么样子的？ ■存在万能的架构吗？架构本质是什么？ ■网站架构如何选型？开发语言重要吗？ 语言的选择意味着不同的架构路线、不同的开发\测试框架、不同的部署方式及不同的开发效率，最终到底，语言选择涉及到资源成本。 钱和人是最终要的o(∩_∩)o… ■网站架构如何选型？开发语言重要吗？ ■架构只是浮云？神马才是重要的？。。。

Thank you！- Q&A