大型网站技术架构探讨

本文内容主要来自于浩东2011年6月的ppt。

目录：

    一、大型网站架构的目标与挑战

    二、网站架构演变及其技术脉络

    三、架构设计理论与原则

 

何为“大型”网站？

    没有统一的判断标准，流量大小是一个重要指标（日均流量至少IP>1,000,000才算大型网站）

1、大型网站架构的目标与挑战

每一个目标背后面临着技术、设计、维护等诸多方面的挑战； 而目标自己的指望值也会根据实际状况进行调整，这也意味着网站架构建设是个不断调整的过程。

2、网站架构演变及其技术脉络

一、Web动静态资源分离及其与DB物理分离

-->优势：“简单”、安全性提升

-->缺点：存在单点，谈不上高可用性（high availability架构目标）

-->技术点：应用设计要保证可扩展（framework很重要Spring/Beetle）、Web Server动/静态资源分离

               Web Server（Apache\Nginx\IIS\JBoss…）、

               Database Server（Mysql\Oracle\Redis…）

注意：通常地，本文提到的物理服务器都是泛指pc级物理服务器；Web Server泛指HTTP服务器和应用服务器综合体对于一个试水性网站来讲为了节约成本，Web Server和DB Server都放在同一台pc Server服务器上是常见的事情。当网站访问量增大，cpu处理能力是瓶颈的时候，经过把web Server和Db Server简单物理分开的，效果明显！

web动静态资源分离：

-->img,doc,js,css等静态资源使用单独的Web HTTP Server处理请求

-->动态页面静态化处理                                                

二、采起缓存处理

访问量持续增大，页面响应愈来愈慢。考虑到网站还处在试水性成长阶段，节约成本，硬件不动，着重应用自己优化。采起缓存处理机制是个必然的选择。

-->优势：简单有效、维护方便

-->缺点：依然存在单点

-->技术点：客户端（浏览器）缓存、前端页面缓存、页面片断缓存、本地数据缓存/数据库缓存

    (1) 客户端（浏览器）缓存

          可以让浏览器缓存的数据必定要缓存；浏览器可以处理的运算，决不放在服务器端来处理。

         （1.1）根据HTTP协议特性，修改Header参数（Cache-Control、Expires、Pragma、Last-Modified、Etag），让浏览器来缓存页面（一些优秀开发框架会对此作透明的封装，例如：Beetle） http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html

         （1.2）使用HTTP1.1协议，因为http pipelining技术特性，可以使用get请求的决不采起post请求

         （1.3）为了节约带宽，压缩页面（Content-Encoding: gzip）；页面各个元素能“小”即“小”，例如：js包压缩，js合并，图片压缩等

         （1.4）会话状态信息采起Cookie代替传统使用服务器Sessions对象存储习惯作法；使用Ajax实现页面局部刷新

         （1.5）若是可能，可采起浏览器插件技术突破浏览器功能限制，将本来在服务器端运算，尽可能迁到浏览器端。ActiveX/Applet/Flash/….HTML5   （ 最值得期待，她的出现一定改变整个Web世界）

    （2）前端页面缓存

    访客向网站发出访问请求,由前端页面缓存器负担原服务器的处理进程作出响应,获取原服务器的相应网页内容,将其储存在自身的内存中,与 此同时,传送给访客这一缓存的内容;若有另外一访客也请求访问以前的相同内容,前端页面缓存器毋须再次获取原服务器上的相应内容,而直接从自身的内存中获取,将这一内容传送给访客。反之,前端页面缓存器也可缓存访客的GET和POST请求。　　    访客实际面对的是前端页面缓存器,与网站之间的通信彻底由前端页面缓存器反向代理,而非原服务器直接响应访客,这将大大加快访客上网流畅度,有效提高访问量,显著下降带宽占用,减轻原始服务器的繁忙度,加快响应速度,毋须不停地购置大内存,大硬盘,扩容电力设施为服务器端节省成本。

注意：采用具有缓存功能的http反向代理服务器做前端页面缓存器，Varnish\Squid\Ncache\AiCache(商业)…【硬件F5】

    （3）页面片断缓存ESI(Edge Side Includes)

ESI是一个基于XML的标记语言，目的是在HTTP中组装各类资源。在实际环境中，一个动态生成的页面，当中可能只有少许的内容是频繁变化的或是个性化的，对于传统的Cache服务器来讲，为了可以保证页面的时效性，却因为页面中这些少许的动态内容而没法将整个页面进行缓存。ESI经过使用简单的标记语言来对那些能够缓存和不能缓存的网页中的内容片段进行描述，每一个网页都被划分红不一样的小部分分别赋予不一样的缓存控制策略，使Cache服务器能够根据这些策略在将完整的网页发送给用户以前将不一样的小部分动态地组合在一块儿。经过这种控制，能够有效地减小从服务器抓取整个页面的次数，而只用从原服务器中提取少许的不能缓存的片段，所以能够有效下降原服务器的负载，同时提升用户访问的响应时间。

ESI须要服务器端支持，常见apache(mod_esi)、WebLogic、JSP标签库(JESI)等。

    （4）本地数据缓存

          （4.1）关系数据库系统（如：Oracle\MySql）Query Cache策略：通常以sql为key来缓存查询结果，尽可能不要拼sql，使用PreparedStatement的“？”模式sql；Query Cache大小要根据数据库系统具体状况合理设置，过大只会浪费内存，参考值：128M

          （4.2）关系数据库系统Data Buffer策略：就是数据库数据内存缓存器，其访问命中率决定数据库性能，可根据实际物理内存大小适量增大，如：MySql建议buffer值为物理内存60-80%

          （4.3）应用服务器Cache包括：对象缓存（例如：对象线程安全，作成单例），更新频率不大数据考虑缓存（如：基表数据、配置文件信息），考虑使用线程池，对象池，链接池等

          （4.4）常见java解决方案：map\OSCache\EHCache等

注意：一、须要从数据库系统和Web应用服务器两个层面考虑缓存优化

         二、常见缓存算法：（贝莱蒂算法、最近最少使用算法、最近最频繁使用算法、伪LRU算法）

三、增长机器作HA、数据库读写分离

-->优势：增长服务器和HA机制，系统性能及可用性获得保证

-->缺点：读写分离，增长程序难度，架构变复杂，维护难度增长

-->技术点：负载均衡、DAL、数据库读写分离

   （1）负载均衡

LVS（LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具备很好的吞吐率，将请求均衡地转移到不一样的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，并且无需修改客户端和服务器端的程序）

       （2）数据库读写分离及DAL

各个关系数据库厂商针对dal及replication都有本身方案

独立的DAL Proxy服务器（MySQL: mysqlproxy,Amoeba；PostgreSQL: PL/Proxy ）

DAL API（Java: Hibernate Shard,Ibatis Shard,HiveDB,Guzz；Python: Pyshards）

 

四、CDN、分布式缓存、分库

网站业务发展迅速，数据量大幅增大是当前最大的挑战，用户分散各地区，某些地方用户访问响应很慢，影响体验和业务发展；同时，因为数据量过大，数据缓存在本地内存已经不现实，分布式缓存是必然选择了

-->优势：异地缓存有效解决不一样地方用户访问过慢的问题；分库策略带来网站性能总体提高

-->缺点：成本大幅增长，架构进一步复杂化，也维护难度进一步增大，架构开始臃肿了

-->技术点：CDN、分布式缓存、Shard分库

 

    （1）CDN

CDN的全称是Content Delivery Network，即内容分发网络。其目的是经过在现有的Internet中增长一层新的网络架构，将网站的内容发布到最接近用户的网络"边缘"，使用户能够就近取得所需的内容，解决 Internet网络拥挤的情况，提升用户访问网站的响应速度。从技术上全面解决因为网络带宽小、用户访问量大、网点分布不均等缘由所形成的用户访问网站响应速度慢的问题。 (也就是一个服务器的内容，平均分部到多个服务器上，服务器智能识别，让用户获取离用户最近的服务器，提升速度。

   （2）分布式缓存

-->本地缓存性能优秀，但容量有限，无伸缩性

-->采用分布式缓存方案突破容量限制，具有良好伸缩性；但分布式涉及远程网络通讯消耗其性能本地缓存来得优秀，并可涉及节点状态维护及数据复制问题，其稳定性和可靠性是个挑战。

-->目前流行分布式缓存方案：memcached、membase、redis等，基本上当前的NoSQL方案均可以用来作分布式缓存方案

 

    （3）分库

垂直分区和水平分区两种。

垂直分库后，各模块数据之间如何关联查询？垂直分库前提是良好的松耦合的模块化设计

水平分区中，Shard是分布式解决方案，与数据库集中式的表空间分区是两个不一样方案（分片Key识别（划分检索依据）是关键）

 

五、多个数据中心，向分布式存储和计算的架构体系迈进

-->优势：多数据中心，带来更高质量区域服务体验；分布式存储及计算架构有效解决pb级数据量存储、检索及计算性能问题

-->缺点：架构复杂、数据同步、一致性及系统维护、技能要求等成本十分高

-->技术点：分布式文件系统、Map/Reduce、Key-Value存储

 

    （1）分布式存储计算解决方案[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)

 

3、架构设计理论与原则

一、关于数据一致性—ACID vs BASE

-->ACID（ Atomicity 、 Consistency 、 Isolation 、 Durability ）是关系型数据库的最基本原则，遵循ACID原则强调一致性，对成本要求很高，对性能影响很大。

-->BASE（ Basically Available 、 Soft state 、 Eventually consistent ）策略(注意：ACID原则适用于互联网应用吗？可用性彷佛比一致性重要些；BASE策略与ACID不一样，其基本思想就是经过牺牲强一致性，以得到更好的可用性或可靠性)

二、关于分布式系统—CAP理论

CAP理论指出，一个分布式系统只能知足如下两个指标

三、ED-SOA架构

四、架构进化与退化