Contenu connexe Similaire à 大型网站架构设计 (20) 3. BeetleSoft 大型网站技术架构探讨 [3]
一般地，本文提到的物理服 器都是泛指务 pc 物理服 器；级 务 Web Server 泛指
HTTP 服 器和 用服 器 合体务 应 务 综
于一个 水性网站来 了 成本，对 试 说为 节约 Web Server 和 DB Server 都放在同一台
pc Server 服 器上是常 的事情。务 见
当网站 量增大，访问 cpu 理能力是瓶 的 候，通 把处 颈 时 过 web Server 和 Db
Server 物理分 的，效果明简单 开 显
6. BeetleSoft 大型网站技术架构探讨 [6]
客向网站 出 求访 发 访问请 , 由前端 面 存器 担原服 器的 理 程做出页 缓 负 务 处 进
响应 , 取原服 器的相 网 内容获 务 应 页 , 将其 存在自身的内存中储 , 与 此同时 , 传
送 客 一 存的内容给访 这 缓 ; 如有另一 客也 求 之前的相同内容访 请 访问 , 前端 面页
存器毋 再次 取原服 器上的相 内容缓 须 获 务 应 , 而直接从自身的内存中 取获 , 将这
一内容 送 客。反之传 给访 , 前端 面 存器也可 存 客的页 缓 缓 访 GET 和 POST 求。请
客 面 的是前端 面 存器访 实际 对 页 缓 , 与网站之 的通 完全由前端 面 存间 讯 页 缓
器反向代理 , 而非原服 器直接响 客务 应访 , 将大大加快 客上网流 度这 访 畅 , 有效
提升 量访问 , 著降低 占用显 带宽 , 原始服 器的繁忙度减轻 务 , 加快响 速度应 , 毋
不停地 置大内存须 购 , 大硬盘 , 容 力 施 服 器端 省成本。扩 电 设 为 务 节
7. BeetleSoft 大型网站技术架构探讨 [7]
ESI 是一个基于 XML 的 言，目的是在标记语 HTTP 中 装各 源。在 境组 种资 实际环
中，一个 生成的 面，当中可能只有少量的内容是 繁 化的或是个性化动态 页 频 变
的， 于 的对 传统 Cache 服 器来 ， 了能 保 面的 效性，却由于 面务 说 为 够 证页 时 页
中 些少量的 内容而无法将整个 面 行 存。这 动态 页 进 缓 ESI 通 使用 的过 简单 标记语
言来 那些可以 存和不能 存的网 中的内容片断 行描述，每个网 都被对 缓 缓 页 进 页
分成不同的小部分分 予不同的 存控制策略，使划 别赋 缓 Cache 服 器可以根据务
些策略在将完整的网 送 用 之前将不同的小部分 地 合在一起。这 页发 给 户 动态 组
通 控制，可以有效地 少从服 器抓取整个 面的次数，而只用从原服过这种 减 务 页
器中提取少量的不能 存的片断，因此可以有效降低原服 器的 ，同务 缓 务 负载 时
提高用 的响 。户访问 应时间
8. BeetleSoft 大型网站技术架构探讨 [8]
常 存算法见缓
莱蒂算法（贝 Belady's Algorithm ）
最有效率的 存算法会 掉未来最 内不使用的数据。 理想情况被称缓 丢 长时间 这种
作 莱蒂最 算法或者千里眼算法。由于要 数据要多久后才被使用基本上贝 优 预计
是不可能的，所以 算法没有 的可操作性。它的作用在于 不同的 存这种 实际 为 缓
算法 立一个 劣 准。订 优 标
最近最少使用算法 (LRU ， Least Recently Used ）
最近最少使用算法的思路是 弃近段 内最少被使用的数据。要 算丢 时间 实现这种
法需要跟踪数据何 被使用，用 方法来 去近一段 被最少使用次数时 这种 筛选 时间
的数据其代价往往是昂 的。它的 往往是通 在 存数据上 立 志贵 实现 过 缓 设 时间标
位，用以跟踪最近最少被使用的 存数据。一个数据每被使用一次，其他数据缓
的 志位数 就要增加。时间标 值
10. BeetleSoft 大型网站技术架构探讨 [10]
DNS 均衡负载 反向代理 均衡负载 直接路由 F5 硬件
LVS （ LVS 集群采用 IP 均衡技 和基于内容 求分 技 。 度器具有很负载 术 请 发 术 调
好的吞吐率，将 求均衡地 移到不同的服 器上 行，且 度器自 屏蔽掉请 转 务 执 调 动
服 器的故障，从而将一 服 器 成一个高性能的、高可用的虚 服 器。务 组 务 构 拟 务
整个服 器集群的 客 是透明的，而且无需修改客 端和服 器端的程务 结构对 户 户 务
序）
Virtual Server via NAT （ VS-NAT ）
用地址翻 虚 服 器。地址 器有译实现 拟 务 转换
能被外界 到的合法访问 IP 地址，它修改来自专
有网 的流出包的地址。外界看起来包是来自络
地址 器本身，当外界包送到 器 ，它转换 转换 时
11. BeetleSoft 大型网站技术架构探讨 [11]
各个 系数据 厂商关 库 针对 dal 及 replication 都有自己方案
独立的 DAL Proxy 服 器务
MySQL: mysqlproxy,Amoeba
PostgreSQL: PL/Proxy (Skype)
DAL API
Java: Hibernate Shard,Ibatis Shard,HiveDB,Guzz
Python: Pyshards
12. BeetleSoft 大型网站技术架构探讨 [12]
网站 展迅速，数据量大幅增大是当前最大的挑 ，用 分散各地区，某业务发 战 户
些地方用 响 很慢，影响体 和 展户访问 应 验 业务发
同 ，由于数据量 大，数据 存在本地内存已 不 ，分布式 存是必然时 过 缓 经 现实 缓
了选择
13. BeetleSoft 大型网站技术架构探讨 [13]
CDN 的全称是 Content Delivery Network ，即内容分 网 。其目的是通 在发 络 过 现
有的 Internet 中增加一 新的网 架 ，将网站的内容 布到最接近用 的网层 络 构 发 户
络 " 边缘 " ，使用 可以就近取得所需的内容，解决户 Internet 网 的状况络拥挤
，提高用 网站的响 速度。从技 上全面解决由于网 小、用户访问 应 术 络带宽 户访
量大、网点分布不均等原因所造成的用 网站响 速度慢的 。问 户访问 应 问题 ( 也
就是一个服 器的内容，平均分部到多个服 器上，服 器智能 ， 用务 务 务 识别 让 户
取离用 最近的服 器，提高速度。获 户 务
17. BeetleSoft 大型网站技术架构探讨 [17]
某天突然 网站可以成 第发现 为 2 个 facebook 了，用 ，数据量 到户过亿 达 pb 。级
网站性能不是通 增加硬件服 器就能 足的。（机房放 都不 ）过简单 务 够满 满 够 这
就不得面 以下 ：既然样 对 选择 1 个机房都容不下了（可看做一个数据中心），
那么就建多几个（多个数据中心）；建立数据中心，无疑就需要更多的机器和
存 ，考 天价的成本的，利用 有廉价的存 和机器，参照储 虑 现 储 google 的 GFS 、
Map/Reduce 、 Bigtable 技 模式搭建分布式存 和 算的架 就是必然 了术 储 计 构 选择
。
18. BeetleSoft 大型网站技术架构探讨 [18]
DFS 提供了一个全局命名空 的高可用（通 跨机器（和跨机架）的文件数据间 过 复
制来 到高可用性，免受 文件存 系 无法避免的 多失 的影响）文件达 传统 储 统 许 败
系 ，解决高容量数据高效、可靠存 ；统 储问题 Map/Reduce 的 算框架，它与计
DFS 密 作，帮助 理收集到的海量数据紧 协 处 ;Key-Value DB 代替 的数据 ，传统 库
通 一些主 来 海量数据，并 高效的 。过 键 组织 实现 查询
![BeetleSoft 大型网站技术架构探讨 [1]
那是不是流量大就是大型网站 ？呢 Google Analytics](https://image.slidesharecdn.com/iaoiioeouiio-140726212535-phpapp01/85/-1-320.jpg)
![BeetleSoft 大型网站技术架构探讨 [2]
追求这 3 个目 ，是网站 的根源标 闹腾](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)