网站架构方案全解析

时间 2019-11-16

原文原文链接

一、HTML静态化其实你们都知道，效率最高、消耗最小的就是纯静态化的html页面，因此咱们尽量使咱们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。可是对于大量内容而且频繁更新的网站，咱们没法所有手动去挨个实现，因而出现了咱们常见的信息发布系统CMS，像咱们常访问的各个门户站点的新闻频道，甚至他们的其余频道，都是经过信息发布系统来管理和实现的，信息发布系统能够实现最简单的信息录入自动生成静态页面，还能具有频道管理、权限管理、自动抓取等功能，对于一个大型网站来讲，拥有一套高效、可管理的CMS是必不可少的。除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来讲，尽量的静态化也是提升性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再从新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询可是内容更新很小的应用，能够考虑使用html静态化来实现，好比论坛中论坛的公用设置信息，这些信息目前的主流论坛均可以进行后台管理而且存储再数据库中，这些信息其实大量被前台程序调用，可是更新频率很小，能够考虑将这部份内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。php

二、图片服务器分离你们知道，对于Web服务器来讲，无论是Apache、IIS仍是其余容器，图片是最消耗资源的，因而咱们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至不少台图片服务器。这样的架构能够下降提供页面访问请求的服务器系统压力，而且能够保证系统不会由于图片问题而崩溃，在应用服务器和图片服务器上，能够进行不一样的配置优化，好比apache在配置ContentType的时候能够尽可能少支持，尽量少的LoadModule，保证更高的系统消耗和执行效率。html

三、数据库集群和库表散列大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快没法知足应用，因而咱们须要使用数据库集群或者库表散列。在数据库集群方面，不少数据库都有本身的解决方案，Oracle、Sybase等都有很好的方案，经常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什么样的DB，就参考相应的解决方案来实施便可。上面提到的数据库集群因为在架构、成本、扩张性方面都会受到所采用DB类型的限制，因而咱们须要从应用程序的角度来考虑改善系统架构，库表散列是经常使用而且最有效的解决方案。咱们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不一样的模块对应不一样的数据库或者表，再按照必定的策略对某个页面或者功能进行更小的数据库散列，好比用户表，按照用户ID进行表散列，这样就可以低成本的提高系统的性能而且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，而后对帖子、用户按照板块和ID进行散列数据库和表，最终能够在配置文件中进行简单的配置便能让系统随时增长一台低成本的数据库进来补充系统性能。前端

四、缓存一词搞技术的都接触过，不少地方用到缓存。网站架构和网站开发中的缓存也是很是重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了本身的缓存模块，也可使用外加的Squid模块进行缓存，这两种方式都可以有效的提升Apache的访问响应能力。网站程序开发方面的缓存，Linux上提供的Memory Cache是经常使用的缓存接口，能够在web开发中使用，好比用Java开发的时候就能够调用MemoryCache对一些数据进行缓存和通信共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各类语言基本都有本身的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，.net不是很熟悉，相信也确定有。java

五、镜像是大型网站常采用的提升性能和数据安全性的方式，镜像的技术能够解决不一样网络接入商和地域带来的用户访问速度差别，好比 ChinaNet和EduNet之间的差别就促使了不少网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有不少专业的现成的解决架构和产品可选。也有廉价的经过软件实现的思路，好比Linux上的rsync等工具。node

六、负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有不少专业的服务提供商和产品能够选择，我我的接触过一些解决方法，其中有两个架构能够给你们作参考。python

七、硬件四层交换第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚 IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其余协议。这些业务在物理服务器基础上，须要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品能够选择，好比Alteon、F5等，这些产品很昂贵，可是物有所值，可以提供很是优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。mysql

八、软件四层交换你们知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。可是知足必定量的压力仍是游刃有余的，有人说软件实现方式其实更灵活，处理能力彻底看你配置的熟悉能力。软件四层交换咱们可使用Linux上经常使用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提升系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，能够同时知足多种应用需求，这对于分布式的系统来讲必不可少。一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在不少大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都很是容易。这样的架构我准备空了专门详细整理一下和你们探讨。对于大型网站来讲，前面提到的每一个方法可能都会被同时使用到，我这里介绍得比较浅显，具体实现过程当中不少细节还须要你们慢慢熟悉和体会，有时一个很小的squid参数或者apache参数设置，对于系统性能的影响就会很大，但愿你们一块儿讨论，达到抛砖引玉之效。linux

2nginx

用squid作web cache server，而apache在squid的后面提供真正的web服务。固然使用这样的架构必需要保证主页上大部分都是静态页面。这就须要程序员的配合将页面在反馈给客户端以前将页面所有转换成静态页面。程序员

基本看出sina和sohu对于频道等栏目都用了相同的技术，即squid来监听这些IP的80端口，而真正的web server来监听另一个端口。从用户的感受上来讲不会有任何的区别，而相对于将web server直接和客户端连在一块儿的方式，这样的方式明显的节省的带宽和服务器。用户访问的速度感受也会更快。

实例：Yupoo! 的网站技术架构

带宽：4000M/S

服务器数量：60 台左右

Web服务器：Lighttpd, Apache, nginx

应用服务器：Tomcat

其余：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

该架构图给出了很好的概览(点击能够查看在 Yupoo! 上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

Squid 与 Tomcat 彷佛在 Web 2.0 站点的架构中较少看到。我首先是对 Squid 有点疑问，对此阿华的解释是"目前暂时还没找到效率比 Squid 高的缓存系统，原来命中率的确不好，后来在 Squid 前又装了层 Lighttpd, 基于 url 作 hash, 同一个图片始终会到同一台 squid 去，因此命中率完全提升了"

对于应用服务器层的 Tomcat，如今 Yupoo! 技术人员也在逐渐用其余轻量级的东西替代，而 YPWS/YPFS 如今已经用 Python 进行开发了。

名次解释：

YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，能够增长针对用户、图片、外链网站显示的逻辑判断，能够安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS--Yupoo File System 与 YPWS 相似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

【Updated: 有网友留言质疑 Python 的效率，Yupoo 老大刘平阳在 del.icio.us 上写到 "YPWS用Python本身写的，每台机器每秒能够处理294个请求, 如今压力几乎都在10%如下"】

图片处理层

接下来的 Image Process Server 负责处理用户上传的图片。使用的软件包也是 ImageMagick，在上次存储升级的同时，对于锐化的比率也调整过了(我我的感受，效果的确好了不少)。”Magickd“ 是图像处理的一个远程接口服务，能够安装在任何有空闲 CPU资源的机器上，相似 Memcached的服务方式。

咱们知道 Flickr 的缩略图功能原来是用 ImageMagick 软件包的，后来被雅虎收购后出于版权缘由而不用了(?);EXIF 与 IPTC Flicke 是用 Perl 抽取的，我是很是建议 Yupoo! 针对 EXIF 作些文章，这也是潜在产生受益的一个重点。

图片存储层

原来 Yupoo! 的存储采用了磁盘阵列柜，基于 NFS 方式的，随着数据量的增大，”Yupoo! 开发部从07年6月份就开始着手研究一套大容量的、能知足 Yupoo! 从此发展须要的、安全可靠的存储系统“，看来 Yupoo! 系统比较有信心，也是满怀期待的，毕竟这要支撑以 TB 计算的海量图片的存储和管理。咱们知道，一张图片除了原图外，还有不一样尺寸的，这些图片统一存储在 MogileFS 中。

对于其余部分，常见的 Web 2.0 网站必须软件都能看到，如 MySQL、Memcached 、Lighttpd 等。Yupoo! 一方面采用很多相对比较成熟的开源软件，一方面也在自行开发定制适合本身的架构组件。这也是一个 Web 2.0 公司所必须要走的一个途径。

很是感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

--EOF--

lighttpd+squid这套缓存是放在另一个机房做为cdn的一个节点使用的，图中没描绘清楚，给你们带来不便了。

squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，因此就没想其余的了。

URL Hash的扩展性的确很差，能作的就是不轻易去增减服务器，咱们目前是5台服务器作一组hash.

咱们如今用Python写的Web Server，在效率方面，我能够给个测试数据，根据目前的访问日志模拟访问测试的结果是1台ypws,平均每秒处理294个请求(加载全部的逻辑判断)。

在可靠性上，还不没具体的数据，目前运行1个多月尚未任何异常。

lvs每一个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。

咱们处理图片都是即时的，咱们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。

实例：Tailrank 网站架构

天天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。

专门爆料网站架构的 Todd Hoff 对 Kevin Burton 进行了采访。因而咱们能了解一下 Tailrank 架构的一些信息。每小时索引 2400 万的 Blog 与 Feed，内容处理能力为 160-200Mbps，IO 写入大约在10-15MBps。每月要处理 52T 之多的原始数据。Tailrank 所用的爬虫如今已经成为一个独立产品：spinn3r

服务器硬件

目前大约 15 台服务器，CPU 是 64 位的 Opteron。每台主机上挂两个 SATA 盘，作 RAID 0。据我所知，国内不少 Web 2.0 公司也用的是相似的方式，SATA 盘容量达，低廉价格，堪称不二之选。操做系统用的是 Debian Linux 。Web 服务器用 Apache 2.0，Squid 作反向代理服务器。

数据库

Tailrank 用 MySQL 数据库，联邦数据库形式。存储引擎用 InnoDB，数据量 500GB。Kevin Burton 也指出了 MySQL 5 在修了一些多核模式下互斥锁的问题(This Bug?)。到数据库的JDBC 驱动链接池用 lbpool 作负载均衡。MySQL Slave 或者 Master的复制用 MySQLSlaveSync 来轻松完成。不过即便这样，还要花费 20%的时间来折腾 DB。

其余开放的软件

任何一套系统都离不开合适的 Profiling 工具，Tailrank 也不利外，针对 Java 程序的 Benchmark 用 Benchmark4j。Log 工具用 Log5j(不是 Log4j)。Tailrank 所用的大部分工具都是开放的。

Tailrank 的一个比较大的竞争对手是 Techmeme，虽然两者暂时看面向内容的侧重点有所不一样。其实，最大的对手仍是本身，当须要挖掘的信息量愈来愈大，若是精准并及时的呈现给用户内容的成本会愈来愈高。从如今来看，Tailrank 离预期目标还差的很远。期待罗马早日建成

YouTube架构学习

原文: YouTube Architecture

YouTube发展迅速，天天超过1亿的视频点击量，但只有不多人在维护站点和确保伸缩性。

平台

Apache
Python
Linux(SuSe)
MySQL
psyco，一个动态的Python到C的编译器
lighttpd代替Apache作视频查看

状态

支持天天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到天天3千万的视频点击量
于2006年7月达到天天1亿的视频点击量
2个系统管理员，2个伸缩性软件架构师
2个软件开发工程师，2个网络工程师，1个DBA
处理飞速增加的流量

Java代码

1. while (true)
2. {
3. identify_and_fix_bottlenecks();
4. drink();
5. sleep();
6. notice_new_bottleneck();
7. }
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

天天运行该循环屡次

Web服务器

NetScaler用于负载均衡和静态内容缓存
使用mod_fast_cgi运行Apache
使用一个Python应用服务器来处理请求的路由
应用服务器与多个数据库和其余信息源交互来获取数据和格式化html页面
通常能够经过添加更多的机器来在Web层提升伸缩性
Python的Web层代码一般不是性能瓶颈，大部分时间阻塞在RPC
Python容许快速而灵活的开发和部署
一般每一个页面服务少于100毫秒的时间
使用psyco(一个相似于JIT编译器的动态的Python到C的编译器)来优化内部循环
对于像加密等密集型CPU活动，使用C扩展
对于一些开销昂贵的块使用预先生成并缓存的html
数据库里使用行级缓存
缓存完整的Python对象
有些数据被计算出来并发送给各个程序，因此这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给全部服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，而后发送。

视频服务

1，花费包括带宽，硬件和能源消耗

2，每一个视频由一个迷你集群来host，每一个视频被超过一台机器持有

3，使用一个集群意味着：

-更多的硬盘来持有内容意味着更快的速度

-failover。若是一台机器出故障了，另外的机器能够继续服务

-在线备份

4，使用lighttpd做为Web服务器来提供视频服务：

-Apache开销太大

-使用epoll来等待多个fds

-从单进程配置转变为多进程配置来处理更多的链接

5，大部分流行的内容移到CDN：

-CDN在多个地方备分内容，这样内容离用户更近的机会就会更高

-CDN机器常常内存不足，由于内容太流行以至不多有内容进出内存的颠簸

6，不太流行的内容(天天1-20浏览次数)在许多colo站点使用YouTube服务器

-长尾效应。一个视频能够有多个播放，可是许多视频正在播放。随机硬盘块被访问

-在这种状况下缓存不会很好，因此花钱在更多的缓存上可能没太大意义。

-调节RAID控制并注意其余低级问题

-调节每台机器上的内存，不要太多也不要太少

视频服务关键点

1，保持简单和廉价

2，保持简单网络路径，在内容和用户间不要有太多设备

3，使用经常使用硬件，昂贵的硬件很难找到帮助文档

4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具

5，很好的处理随机查找(SATA，tweaks)

缩略图服务

1，作到高效使人惊奇的难

2，每一个视频大概4张缩略图，因此缩略图比视频多不少

3，缩略图仅仅host在几个机器上

4，持有一些小东西所遇到的问题：

-OS级别的大量的硬盘查找和inode和页面缓存问题

-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3容许大目录，但在一个文件系统里存储大量文件不是个好主意

-每秒大量的请求，由于Web页面可能在页面上显示60个缩略图

-在这种高负载下Apache表现的很是糟糕

-在Apache前端使用squid，这种方式工做了一段时间，可是因为负载继续增长而以失败了结。它让每秒300个请求变为20个

-尝试使用lighttpd可是因为使用单线程它陷于困境。遇到多进程的问题，由于它们各自保持本身单独的缓存

-如此多的图片以至一台新机器只能接管24小时

-重启机器须要6-10小时来缓存

5，为了解决全部这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：

-避免小文件问题，由于它将文件收集到一块儿

-快，错误容忍

-更低的延迟，由于它使用分布式多级缓存，该缓存与多个不一样collocation站点工做

-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库

1，早期

-使用MySQL来存储元数据，如用户，tags和描述

-使用一整个10硬盘的RAID 10来存储数据

-依赖于信用卡因此YouTube租用硬件

-YouTube通过一个常见的革命：单服务器，而后单master和多read slaves，而后数据库分区，而后sharding方式

-痛苦与备份延迟。master数据库是多线程的而且运行在一个大机器上因此它能够处理许多工做，slaves是单线程的而且一般运行在小一些的服务器上而且备份是异步的，因此slaves会远远落后于master

-更新引发缓存失效，硬盘的慢I/O致使慢备份

-使用备份架构须要花费大量的money来得到增长的写性能

-YouTube的一个解决方案是经过把数据分红两个集群来将传输分出优先次序：一个视频查看池和一个通常的集群

2，后期

-数据库分区

-分红shards，不一样的用户指定到不一样的shards

-扩散读写

-更好的缓存位置意味着更少的IO

-致使硬件减小30%

-备份延迟下降到0

-如今能够任意提高数据库的伸缩性

数据中心策略

1，依赖于信用卡，因此最初只能使用受管主机提供商

2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议

3，YouTube改成使用colocation arrangement。如今YouTube能够自定义全部东西而且协定本身的契约

4，使用5到6个数据中心加CDN

5，视频来自任意的数据中心，不是最近的匹配或其余什么。若是一个视频足够流行则移到CDN

6，依赖于视频带宽而不是真正的延迟。能够来自任何colo

7，图片延迟很严重，特别是当一个页面有60张图片时

8，使用BigTable将图片备份到不一样的数据中心，代码查看谁是最近的

学到的东西

1，Stall for time。创造性和风险性的技巧让你在短时间内解决问题而同时你会发现长期的解决方案

2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别

3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。建立本身的网络将花费太多时间和太多money

4，Keep it simple!简单容许你更快的从新架构来回应问题

5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不只仅是得到更多的写性能

6，Constant iteration on bottlenecks：

-软件：DB，缓存

-OS：硬盘I/O

-硬件：内存，RAID

7，You succeed as a team。拥有一个跨越条律的了解整个系统并知道系统内部是什么样的团队，如安装打印机，安装机器，安装网络等等的人。With a good team all things are possible。

Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。

平台

Linux

大量语言：Python，Java，C++

状态

在2006年大约有450,000台廉价服务器

在2005年Google索引了80亿Web页面，如今没有人知道数目

目前在Google有超过200个GFS集群。一个集群能够有1000或者甚至5000台机器。成千上万的机器从运行着5000000000000000字节存储的GFS集群获取数据，集群总的读写吞吐量能够达到每秒40兆字节

目前在Google有6000个MapReduce程序，并且每月都写成百个新程序

BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择

堆栈

Google形象化它们的基础组织为三层架构：

1，产品：搜索，广告，email，地图，视频，聊天，博客

2，分布式系统基础组织：GFS，MapReduce和BigTable

3，计算平台：一群不一样的数据中内心的机器

4，确保公司里的人们部署起来开销很小

5，花费更多的钱在避免丢失日志数据的硬件上，其余类型的数据则花费较少

可信赖的存储机制GFS(Google File System)

1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台

2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据

3，为何构建GFS而不是利用已有的东西?由于能够本身控制一切而且这个平台与别的不同，Google须要：

-跨数据中心的高可靠性

-成千上万的网络节点的伸缩性

-大读写带宽的需求

-支持大块的数据，可能为上千兆字节

-高效的跨节点操做分发来减小瓶颈

4，系统有Master和Chunk服务器

-Master服务器在不一样的数据文件里保持元数据。数据以64MB为单位存储在文件系统中。客户端与Master服务器交流来在文件上作元数据操做而且找到包含用户须要数据的那些Chunk服务器

-Chunk服务器在硬盘上存储实际数据。每一个Chunk服务器跨越3个不一样的Chunk服务器备份以建立冗余来避免服务器崩溃。一旦被Master服务器指明，客户端程序就会直接从Chunk服务器读取文件

6，一个上线的新程序可使用已有的GFS集群或者能够制做本身的GFS集群

7，关键点在于有足够的基础组织来让人们对本身的程序有所选择，GFS能够调整来适应个别程序的需求

使用MapReduce来处理数据

1，如今你已经有了一个很好的存储系统，你该怎样处理如此多的数据呢?好比你有许多TB的数据存储在1000台机器上。数据库不能伸缩或者伸缩到这种级别花费极大，这就是MapReduce出现的缘由

2，MapReduce是一个处理和生成大量数据集的编程模型和相关实现。用户指定一个map方法来处理一个键/值对来生成一个中间的键/值对，还有一个reduce方法来合并全部关联到一样的中间键的中间值。许多真实世界的任务均可以使用这种模型来表现。以这种风格来写的程序会自动并行的在一个大量机器的集群里运行。运行时系统照顾输入数据划分、程序在机器集之间执行的调度、机器失败处理和必需的内部机器交流等细节。这容许程序员没有多少并行和分布式系统的经验就能够很容易使用一个大型分布式系统资源

3，为何使用MapReduce?

-跨越大量机器分割任务的好方式

-处理机器失败

-能够与不一样类型的程序工做，例如搜索和广告。几乎任何程序都有map和reduce类型的操做。你能够预先计算有用的数据、查询字数统计、对TB的数据排序等等

4，MapReduce系统有三种不一样类型的服务器

-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态

-Map服务器接收用户输入并在其基础上处理map操做。结果写入中间文件

-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操做

5，例如，你想在全部Web页面里的字数。你将存储在GFS里的全部页面抛入MapReduce。这将在成千上万台机器上同时进行而且全部的调整、工做调度、失败处理和数据传输将自动完成

-步骤相似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS

-在MapReduce里一个map操做将一些数据映射到另外一个中，产生一个键值对，在咱们的例子里就是字和字数

-Shuffling操做汇集键类型

-Reduction操做计算全部键值对的综合并产生最终的结果

6，Google索引操做管道有大约20个不一样的map和reduction。

7，程序能够很是小，如20到50行代码

8，一个问题是掉队者。掉队者是一个比其余程序慢的计算，它阻塞了其余程序。掉队者可能由于缓慢的IO或者临时的CPU不能使用而发生。解决方案是运行多个一样的计算而且当一个完成后杀死全部其余的

9，数据在Map和Reduce服务器之间传输时被压缩了。这能够节省带宽和I/O。

在BigTable里存储结构化数据

1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它能够每秒钟处理百万的读写

2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询

3，它提供查询机制来经过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据

4，商业数据库不能达到这种级别的伸缩性而且不能在成千上万台机器上工做

5，经过控制它们本身的低级存储系统Google获得更多的控制权来改进它们的系统。例如，若是它们想让跨数据中心的操做更简单这个特性，它们能够内建它

6，系统运行时机器能够自由的增删而整个系统保持工做

7，每一个数据条目存储在一个格子里，它能够经过一个行key和列key或者时间戳来访问

8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列而且格式为SSTable

9，BigTable有三种类型的服务器：

-Master服务器分配tablet服务器，它跟踪tablet在哪里而且若是须要则从新分配任务

-Tablet服务器为tablet处理读写请求。当tablet超过大小限制(一般是100MB-200MB)时它们拆开tablet。当一个Tablet服务器失败时，则100个Tablet服务器各自挑选一个新的tablet而后系统恢复。

-Lock服务器造成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都须要互斥

10，一个locality组能够用来在物理上将相关的数据存储在一块儿来获得更好的locality选择

11，tablet尽量的缓存在RAM里

硬件

1，当你有不少机器时你怎样组织它们来使得使用和花费有效?

2，使用很是廉价的硬件

3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.

4，Linux，in-house rack design，PC主板，低端存储

5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues

6，使用一些collocation和Google本身的数据中心

其余

1，迅速更改而不是等待QA

2，库是构建程序的卓越方式

3，一些程序做为服务提供

4，一个基础组织处理程序的版本，这样它们能够发布而不用惧怕会破坏什么东西

Google未来的方向

1，支持地理位置分布的集群

2，为全部数据建立一个单独的全局名字空间。当前的数据由集群分离

3，更多和更好的自动化数据迁移和计算

4，解决当使用网络划分来作广阔区域的备份时的一致性问题(例如保持服务即便一个集群离线维护或因为一些损耗问题)

学到的东西

1，基础组织是有竞争性的优点。特别是对Google而言。Google能够很快很廉价的推出新服务，而且伸缩性其余人很难达到。许多公司采起彻底不一样的方式。许多公司认为基础组织开销太大。Google认为本身是一个系统工程公司，这是一个新的看待软件构建的方式

2，跨越多个数据中心仍然是一个未解决的问题。大部分网站都是一个或者最多两个数据中心。咱们不得不认可怎样在一些数据中心之间完整的分布网站是很须要技巧的

3，若是你本身没有时间从零开始从新构建全部这些基础组织你能够看看Hadoop。Hadoop是这里不少一样的主意的一个开源实现

4，平台的一个优势是初级开发人员能够在平台的基础上快速而且放心的建立健全的程序。若是每一个项目都须要发明一样的分布式基础组织的轮子，那么你将陷入困境由于知道怎样完成这项工做的人相对较少

5，协同工做不一直是掷骰子。经过让系统中的全部部分一块儿工做则一个部分的改进将帮助全部的部分。改进文件系统则每一个人从中受益并且是透明的。若是每一个项目使用不一样的文件系统则在整个堆栈中享受不到持续增长的改进

6，构建自管理系统让你不必让系统关机。这容许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级

7，建立可进化的基础组织，并行的执行消耗时间的操做并采起较好的方案

8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.

9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。

实例：Lighttpd+Squid+Apache搭建高效率Web服务器

架构原理

Apache一般是开源界的首选Web服务器，由于它的强大和可靠，已经具备了品牌效应，能够适用于绝大部分的应用场合。可是它的强大有时候却显得笨重，配置文件得让人望而生畏，高并发状况下效率不过高。而轻量级的Web服务器Lighttpd倒是后起之秀，其静态文件的响应能力远高于 Apache，听说是Apache的2-3倍。Lighttpd的高性能和易用性，足以打动咱们，在它可以胜任的领域，尽可能用它。Lighttpd对 PHP的支持也很好，还能够经过Fastcgi方式支持其余的语言，好比Python。

毕竟Lighttpd是轻量级的服务器，功能上不能跟Apache比，某些应用没法胜任。好比Lighttpd还不支持缓存，而如今的绝大部分站点都是用程序生成动态内容，没有缓存的话即便程序的效率再高也很难知足大访问量的需求，并且让程序不停的去作同一件事情也实在没有意义。首先，Web程序是须要作缓存处理的，即把反复使用的数据作缓存。即便这样也还不够，单单是启动Web处理程序的代价就很多，缓存最后生成的静态页面是必不可少的。而作这个是 Squid的强项，它本是作代理的，支持高效的缓存，能够用来给站点作反向代理加速。把Squid放在Apache或者Lighttpd的前端来缓存 Web服务器生成的动态内容，而Web应用程序只须要适当地设置页面实效时间便可。

即便是大部份内容动态生成的网站，仍免不了会有一些静态元素，好比图片、JS脚本、CSS等等，将Squid放在Apache或者Lighttp 前端后，反而会使性能降低，毕竟处理HTTP请求是Web服务器的强项。并且已经存在于文件系统中的静态内容再在Squid中缓存一下，浪费内存和硬盘空间。所以能够考虑将Lighttpd再放在Squid的前面，构成 Lighttpd+Squid+Apache的一条处理链，Lighttpd在最前面，专门用来处理静态内容的请求，把动态内容请求经过proxy模块转发给Squid，若是Squid中有该请求的内容且没有过时，则直接返回给Lighttpd。新请求或者过时的页面请求交由Apache中Web程序来处理。通过Lighttpd和Squid的两级过滤，Apache须要处理的请求将大大减小，减小了Web应用程序的压力。同时这样的构架，便于把不一样的处理分散到多台计算机上进行，由Lighttpd在前面统一把关。

在这种架构下，每一级都是能够进行单独优化的，好比Lighttpd能够采用异步IO方式，Squid能够启用内存来缓存，Apache能够启用MPM 等，而且每一级均可以使用多台机器来均衡负载，伸缩性很好。

六、负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有不少专业的服务提供商和产品能够选择，我我的接触过一些解决方法，其中有两个架构能够给你们作参考。

用squid作web cache server，而apache在squid的后面提供真正的web服务。固然使用这样的架构必需要保证主页上大部分都是静态页面。这就须要程序员的配合将页面在反馈给客户端以前将页面所有转换成静态页面。

实例：Yupoo! 的网站技术架构

带宽：4000M/S

服务器数量：60 台左右

Web服务器：Lighttpd, Apache, nginx

应用服务器：Tomcat

其余：Python, Java, MogileFS 、ImageMagick 等

首先看一下网站的架构图：

该架构图给出了很好的概览(点击能够查看在 Yupoo! 上的大图和原图，请注意该图版权信息)。

关于 Squid 与 Tomcat

对于应用服务器层的 Tomcat，如今 Yupoo! 技术人员也在逐渐用其余轻量级的东西替代，而 YPWS/YPFS 如今已经用 Python 进行开发了。

名次解释：

YPWS--Yupoo Web Server YPWS 是用 Python开发的一个小型 Web 服务器，提供基本的 Web 服务外，能够增长针对用户、图片、外链网站显示的逻辑判断，能够安装于任何有空闲资源的服务器中，遇到性能瓶颈时方便横向扩展。
YPFS--Yupoo File System 与 YPWS 相似，YPFS 也是基于这个 Web 服务器上开发的图片上传服务器。

图片处理层

图片存储层

很是感谢一下 Yupoo! 阿华对于技术信息的分享，技术是共通的。下一个能爆料是哪家?

--EOF--

lighttpd+squid这套缓存是放在另一个机房做为cdn的一个节点使用的，图中没描绘清楚，给你们带来不便了。

squid前端用lighttpd没用nginx，主要是用了这么久，没出啥大问题，因此就没想其余的了。

URL Hash的扩展性的确很差，能作的就是不轻易去增减服务器，咱们目前是5台服务器作一组hash.

在可靠性上，还不没具体的数据，目前运行1个多月尚未任何异常。

lvs每一个节点上都装nginx，主要是为了反向代理及处理静态内容，不过apache已显得不是那么必需，准备逐渐去掉。

咱们处理图片都是即时的，咱们目前半数以上的服务器都装了magickd服务，用来分担图片处理请求。

实例：Tailrank 网站架构

天天数以千万计的 Blog 内容中，实时的热点是什么? Tailrank 这个 Web 2.0 Startup 致力于回答这个问题。

服务器硬件

数据库

其余开放的软件

YouTube架构学习

原文: YouTube Architecture

YouTube发展迅速，天天超过1亿的视频点击量，但只有不多人在维护站点和确保伸缩性。

平台

Apache
Python
Linux(SuSe)
MySQL
psyco，一个动态的Python到C的编译器
lighttpd代替Apache作视频查看

状态

支持天天超过1亿的视频点击量
成立于2005年2月
于2006年3月达到天天3千万的视频点击量
于2006年7月达到天天1亿的视频点击量
2个系统管理员，2个伸缩性软件架构师
2个软件开发工程师，2个网络工程师，1个DBA
处理飞速增加的流量

Java代码

1. while (true)
2. {
3. identify_and_fix_bottlenecks();
4. drink();
5. sleep();
6. notice_new_bottleneck();
7. }
while (true)
{
identify_and_fix_bottlenecks();
drink();
sleep();
notice_new_bottleneck();
}

天天运行该循环屡次

Web服务器

NetScaler用于负载均衡和静态内容缓存
使用mod_fast_cgi运行Apache
使用一个Python应用服务器来处理请求的路由
应用服务器与多个数据库和其余信息源交互来获取数据和格式化html页面
通常能够经过添加更多的机器来在Web层提升伸缩性
Python的Web层代码一般不是性能瓶颈，大部分时间阻塞在RPC
Python容许快速而灵活的开发和部署
一般每一个页面服务少于100毫秒的时间
使用psyco(一个相似于JIT编译器的动态的Python到C的编译器)来优化内部循环
对于像加密等密集型CPU活动，使用C扩展
对于一些开销昂贵的块使用预先生成并缓存的html
数据库里使用行级缓存
缓存完整的Python对象
有些数据被计算出来并发送给各个程序，因此这些值缓存在本地内存中。这是个使用不当的策略。应用服务器里最快的缓存将预先计算的值发送给全部服务器也花不了多少时间。只需弄一个代理来监听更改，预计算，而后发送。

视频服务

1，花费包括带宽，硬件和能源消耗

2，每一个视频由一个迷你集群来host，每一个视频被超过一台机器持有

3，使用一个集群意味着：

-更多的硬盘来持有内容意味着更快的速度

-failover。若是一台机器出故障了，另外的机器能够继续服务

-在线备份

4，使用lighttpd做为Web服务器来提供视频服务：

-Apache开销太大

-使用epoll来等待多个fds

-从单进程配置转变为多进程配置来处理更多的链接

5，大部分流行的内容移到CDN：

-CDN在多个地方备分内容，这样内容离用户更近的机会就会更高

-CDN机器常常内存不足，由于内容太流行以至不多有内容进出内存的颠簸

6，不太流行的内容(天天1-20浏览次数)在许多colo站点使用YouTube服务器

-长尾效应。一个视频能够有多个播放，可是许多视频正在播放。随机硬盘块被访问

-在这种状况下缓存不会很好，因此花钱在更多的缓存上可能没太大意义。

-调节RAID控制并注意其余低级问题

-调节每台机器上的内存，不要太多也不要太少

视频服务关键点

1，保持简单和廉价

2，保持简单网络路径，在内容和用户间不要有太多设备

3，使用经常使用硬件，昂贵的硬件很难找到帮助文档

4，使用简单而常见的工具，使用构建在Linux里或之上的大部分工具

5，很好的处理随机查找(SATA，tweaks)

缩略图服务

1，作到高效使人惊奇的难

2，每一个视频大概4张缩略图，因此缩略图比视频多不少

3，缩略图仅仅host在几个机器上

4，持有一些小东西所遇到的问题：

-OS级别的大量的硬盘查找和inode和页面缓存问题

-单目录文件限制，特别是Ext3，后来移到多分层的结构。内核2.6的最近改进可能让Ext3容许大目录，但在一个文件系统里存储大量文件不是个好主意

-每秒大量的请求，由于Web页面可能在页面上显示60个缩略图

-在这种高负载下Apache表现的很是糟糕

-在Apache前端使用squid，这种方式工做了一段时间，可是因为负载继续增长而以失败了结。它让每秒300个请求变为20个

-尝试使用lighttpd可是因为使用单线程它陷于困境。遇到多进程的问题，由于它们各自保持本身单独的缓存

-如此多的图片以至一台新机器只能接管24小时

-重启机器须要6-10小时来缓存

5，为了解决全部这些问题YouTube开始使用Google的BigTable，一个分布式数据存储：

-避免小文件问题，由于它将文件收集到一块儿

-快，错误容忍

-更低的延迟，由于它使用分布式多级缓存，该缓存与多个不一样collocation站点工做

-更多信息参考Google Architecture，GoogleTalk Architecture和BigTable

数据库

1，早期

-使用MySQL来存储元数据，如用户，tags和描述

-使用一整个10硬盘的RAID 10来存储数据

-依赖于信用卡因此YouTube租用硬件

-YouTube通过一个常见的革命：单服务器，而后单master和多read slaves，而后数据库分区，而后sharding方式

-更新引发缓存失效，硬盘的慢I/O致使慢备份

-使用备份架构须要花费大量的money来得到增长的写性能

-YouTube的一个解决方案是经过把数据分红两个集群来将传输分出优先次序：一个视频查看池和一个通常的集群

2，后期

-数据库分区

-分红shards，不一样的用户指定到不一样的shards

-扩散读写

-更好的缓存位置意味着更少的IO

-致使硬件减小30%

-备份延迟下降到0

-如今能够任意提高数据库的伸缩性

数据中心策略

1，依赖于信用卡，因此最初只能使用受管主机提供商

2，受管主机提供商不能提供伸缩性，不能控制硬件或使用良好的网络协议

3，YouTube改成使用colocation arrangement。如今YouTube能够自定义全部东西而且协定本身的契约

4，使用5到6个数据中心加CDN

5，视频来自任意的数据中心，不是最近的匹配或其余什么。若是一个视频足够流行则移到CDN

6，依赖于视频带宽而不是真正的延迟。能够来自任何colo

7，图片延迟很严重，特别是当一个页面有60张图片时

8，使用BigTable将图片备份到不一样的数据中心，代码查看谁是最近的

学到的东西

1，Stall for time。创造性和风险性的技巧让你在短时间内解决问题而同时你会发现长期的解决方案

2，Proioritize。找出你的服务中核心的东西并对你的资源分出优先级别

3，Pick your battles。别怕将你的核心服务分出去。YouTube使用CDN来分布它们最流行的内容。建立本身的网络将花费太多时间和太多money

4，Keep it simple!简单容许你更快的从新架构来回应问题

5，Shard。Sharding帮助隔离存储，CPU，内存和IO，不只仅是得到更多的写性能

6，Constant iteration on bottlenecks：

-软件：DB，缓存

-OS：硬盘I/O

-硬件：内存，RAID

Google是伸缩性的王者。Google一直的目标就是构建高性能高伸缩性的基础组织来支持它们的产品。

平台

Linux

大量语言：Python，Java，C++

状态

在2006年大约有450,000台廉价服务器

在2005年Google索引了80亿Web页面，如今没有人知道数目

目前在Google有6000个MapReduce程序，并且每月都写成百个新程序

BigTable伸缩存储几十亿的URL，几百千千兆的卫星图片和几亿用户的参数选择

堆栈

Google形象化它们的基础组织为三层架构：

1，产品：搜索，广告，email，地图，视频，聊天，博客

2，分布式系统基础组织：GFS，MapReduce和BigTable

3，计算平台：一群不一样的数据中内心的机器

4，确保公司里的人们部署起来开销很小

5，花费更多的钱在避免丢失日志数据的硬件上，其余类型的数据则花费较少

可信赖的存储机制GFS(Google File System)

1，可信赖的伸缩性存储是任何程序的核心需求。GFS就是Google的核心存储平台

2，Google File System - 大型分布式结构化日志文件系统，Google在里面扔了大量的数据

3，为何构建GFS而不是利用已有的东西?由于能够本身控制一切而且这个平台与别的不同，Google须要：

-跨数据中心的高可靠性

-成千上万的网络节点的伸缩性

-大读写带宽的需求

-支持大块的数据，可能为上千兆字节

-高效的跨节点操做分发来减小瓶颈

4，系统有Master和Chunk服务器

6，一个上线的新程序可使用已有的GFS集群或者能够制做本身的GFS集群

7，关键点在于有足够的基础组织来让人们对本身的程序有所选择，GFS能够调整来适应个别程序的需求

使用MapReduce来处理数据

3，为何使用MapReduce?

-跨越大量机器分割任务的好方式

-处理机器失败

4，MapReduce系统有三种不一样类型的服务器

-Master服务器分配用户任务到Map和Reduce服务器。它也跟踪任务的状态

-Map服务器接收用户输入并在其基础上处理map操做。结果写入中间文件

-Reduce服务器接收Map服务器产生的中间文件并在其基础上处理reduce操做

-步骤相似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS

-在MapReduce里一个map操做将一些数据映射到另外一个中，产生一个键值对，在咱们的例子里就是字和字数

-Shuffling操做汇集键类型

-Reduction操做计算全部键值对的综合并产生最终的结果

6，Google索引操做管道有大约20个不一样的map和reduction。

7，程序能够很是小，如20到50行代码

9，数据在Map和Reduce服务器之间传输时被压缩了。这能够节省带宽和I/O。

在BigTable里存储结构化数据

1，BigTable是一个大伸缩性、错误容忍、自管理的系统，它包含千千兆的内存和1000000000000000的存储。它能够每秒钟处理百万的读写

2，BigTable是一个构建于GFS之上的分布式哈希机制。它不是关系型数据库。它不支持join或者SQL类型查询

3，它提供查询机制来经过键访问结构化数据。GFS存储存储不透明的数据而许多程序需求有结构化数据

4，商业数据库不能达到这种级别的伸缩性而且不能在成千上万台机器上工做

6，系统运行时机器能够自由的增删而整个系统保持工做

7，每一个数据条目存储在一个格子里，它能够经过一个行key和列key或者时间戳来访问

8，每一行存储在一个或多个tablet中。一个tablet是一个64KB块的数据序列而且格式为SSTable

9，BigTable有三种类型的服务器：

-Master服务器分配tablet服务器，它跟踪tablet在哪里而且若是须要则从新分配任务

-Lock服务器造成一个分布式锁服务。像打开一个tablet来写、Master调整和访问控制检查等都须要互斥

10，一个locality组能够用来在物理上将相关的数据存储在一块儿来获得更好的locality选择

11，tablet尽量的缓存在RAM里

硬件

1，当你有不少机器时你怎样组织它们来使得使用和花费有效?

2，使用很是廉价的硬件

4，Linux，in-house rack design，PC主板，低端存储

5，Price per wattage on performance basis isn't getting better. Have huge power and cooling issues

6，使用一些collocation和Google本身的数据中心

其余

1，迅速更改而不是等待QA

2，库是构建程序的卓越方式

3，一些程序做为服务提供

4，一个基础组织处理程序的版本，这样它们能够发布而不用惧怕会破坏什么东西

Google未来的方向

1，支持地理位置分布的集群

2，为全部数据建立一个单独的全局名字空间。当前的数据由集群分离

3，更多和更好的自动化数据迁移和计算

4，解决当使用网络划分来作广阔区域的备份时的一致性问题(例如保持服务即便一个集群离线维护或因为一些损耗问题)

学到的东西

3，若是你本身没有时间从零开始从新构建全部这些基础组织你能够看看Hadoop。Hadoop是这里不少一样的主意的一个开源实现

6，构建自管理系统让你不必让系统关机。这容许你更容易在服务器之间平衡资源、动态添加更大的容量、让机器离线和优雅的处理升级

7，建立可进化的基础组织，并行的执行消耗时间的操做并采起较好的方案

8，不要忽略学院。学院有许多没有转变为产品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.

9，考虑压缩。当你有许多CPU而IO有限时压缩是一个好的选择。

实例：Lighttpd+Squid+Apache搭建高效率Web服务器

架构原理