主题：【半原创】Flickr 网站架构研究（1） -- 西电鲁丁
家园 【半原创】Flickr 网站架构研究（1） 引言Flickr.com 是网上最受欢迎的照片共享网站之一，还记得那位给Windows Vista拍摄壁纸的Hamad Darwish吗？他就是将照片上传到Flickr，后而被微软看中成为Vista壁纸御用摄影师。
Flickr.com 是最初由位于温哥华的Ludicorp公司开发设计并于2004年2月正式发布的，由于大量应用了WEB 2.0技术，注重用户体验，使得其迅速获得了大量的用户，2007年11月，Flickr迎来了第20亿张照片，一年后，这个数字就达到了30亿，并且还在以加速度增长。
2005年3月，雅虎公司以3千500万美元收购了Ludicorp公司和Flickr.com。虽然Flickr并不是最大的照片共享网站（Facebook以超过100亿张照片排名第一），但这笔收购仍然被认为是WEB 2.0浪潮中最精明的收购，因为仅仅一年后，Google就以16亿美元的高价收购了YouTube，而2007年10月，微软斥资2.4亿美元收购Facebook 1.6%股份，此举使Facebook估值高达150亿美元。估计Ludicorp公司的创始人Stewart Butterfield和Caterina Fake夫妇现在还在后悔吧。
在2005年温哥华PHP协会的简报以及随后的一系列会议上，Flickr的架构师Cal Henderson公开了大部分Flickr所使用的后台技术，使得我们能有机会来分享和研究其在构建可扩展Web站点的经验。
本文大部分资料来自互联网和自己的一点点心得，欢迎大家参与讨论，要是能够起到抛砖引玉的作用，本人将不胜荣幸。Flickr 网站架构综述在讨论Flickr 网站架构之前，让我们先来看一组统计数据（数据来源：April 2007 MySQL Conf and Expo和Flickr网站）
。每天多达40亿次的查询请求
。squid总计约有3500万张照片（硬盘+内存）
。squid内存中约有200万张照片
。总计有大约4亿7000万张照片，每张图片又生成不同尺寸大小的4－5份图片
。每秒38，000次Memcached请求 (Memcached总共存储了1200万对象)
。超过2 PB 存储，其中数据库12TB
。每天新增图片超过 40万（周日峰值超过200万，约1.5TB)
。超过8百50万注册用户
。超过1千万的唯一标签（tags)
你如果觉得这些过时的数据都已经很惊人了，那么让我们来看看Cal Henderson在2008年9月的一次会议上公布的另一组数据，在短短的一秒钟内：
。响应4万个照片访问请求
。处理10万个缓存操作
。运行13万个数据库查询
这张是Flickr的网站架构图，我们这里只作一些简要的描述，具体的分析请静待后续文章。
外链图片需谨慎，可能会被源头改。Pair of ServerIron's
－ Load Balancer
。Squid Caches
－ 反向代理，用于缓存静态的HTML和照片
。Net App'
－ NetApp 公司的Filer, NAS存储设备，用于存储照片
。PHP App Servers
－ 运行REDHAT LINUX,Apache上的PHP应用，Flickr网站的主体是大约6万行PHP代码
－ 没有使用PHP session, 应用是stateless,便于扩展，并避免PHP Server故障所带来的Session失效。
－ 每个页面有大约27～35个查询（不知道为什么这么设计，个人觉得没有必要
）－ 另有专门的Apache Web Farm 服务于静态文件（HTML和照片）的访问
。Storage Manager
－ 运行私有的，适用于海量文件存储的Flickr File System
。Dual Tree Central Database
－ MySQL 数据库，存放用户表，记录的信息是用户主键以及此用户对以的数据库Shard区，从中心用户表中查出用户数据所在位置，然后直接从目标Shard中取出数据。
－ “Dual Tree"架构是”Master－Master"和“Master-Slave"的有效结合，双Master 避免了“单点故障”，Master－Slave又提高了读取速度，因为用户表的操作90％以上是读。
。Master-master shards
－ MySQL 数据库，存储实际的用户数据和照片的元数据（Meta Data)，每个Shard 大约40万个用户，120GB 数据。每个用户的所有数据存放在同一个shard中。
－ Shard中的每一个server的负载只是其可最大负载的50％，这样在需要的时候可以Online停掉一半的server进行升级或维护而不影响系统性能。
－ 为了避免跨Shard查询所带来的性能影响，一些数据有在不同的Shard有两份拷贝，比如用户对照片的评论，通过事务来保证其同步。
。Memcached Cluster
－ 中间层缓存服务器，用于缓存数据库的SQL查询结果等。
。Big Search Engine
- 复制部分Shard数据（Owner’s single tag）到Search Engine Farm以响应实时的全文检索。
- 其他全文检索请求利用Yahoo的搜索引擎处理（Flickr是Yahoo旗下的公司
）服务器的硬件配置：
- Intel或AMD 64位CPU，16GB RAM
- 6-disk 15K RPM RAID-10.
- 2U boxes.
服务器数量：(数据来源：April 2008 MySQL Conference & Expo)
166 DB servers, 244 web servers(不知道是否包括 squid server？), 14 Memcached servers
本帖一共被 6 帖 引用 (帖内工具实现)家园 【原创】Flickr 网站架构研究（7） 系统监控和故障管理对于Flickr这样运行几百台甚至上千台服务器，以及网络和存储设备的大型网站来说，有效的监视整个系统各部分的运行状况，及时发现并处理故障和潜在的问题，是保障网站平稳和可持续运营的关键。
以系统监控和网络管理为主要目的的软件通常称之为“网管软件”，商用软件中以IBM Tivoli, HP OpenView，和CA Unicenter TNG为主流，开源社区则以OpenNMS和Nagios为代表，Flickr采用的是Nagios。传统上定义的网络管理有五大功能：故障管理、配置管理、性能管理、安全管理、计费管理。近些年随着”全面管理“概念的引入，这类软件一般更多的自称为“企业基础架构管理软件”。
SNMP即“Simple Network Management Protocol”是目前最常用的网络管理协议，目前几乎所有的网络设备和主流操作系统都实现了对SNMP的支持。它提供了一种从网络上的设备中收集网络管理信息的方法，也为设备向网络管理工作站报告问题和错误提供了一种方法。
SNMP的最初版本1.0只定义了5种报文：Get,GetNext,getResponse,Set,Trap（这也是它称之为“简单”的原因，而事实上SNMP报文的编解码较为复杂。），示意图如下：
外链图片需谨慎，可能会被源头改SNMP采用UDP作为传输协议，Get,GetNext,用于NMS Manager（一般即网管主机）以轮询（Polling）的方式向SNMP Agent（一般运行在网络设备或服务器上）发出获取MIB（Management Information Base）节点信息的请求，GetResponse则是SNMP Agent的回应,Set用于写操作（实际中很少使用），这4个报文都通过161端口传输；当SNMP Agent端发现所监控的对象（MIB节点）出现故障，则主动向NMS Manager的162端口发出Trap告警。（详细的SNMP协议介绍不在本文内容之内，有兴趣的话可以另贴讨论）
SNMP的协议特点使得"网管软件"能够及时地被动接收网络上的各种告警(Trap)信息,并根据告警信息的内容和级别触发响应的程序进行处理。例如Nagios提供了超过50个各类插件（plugin）用于监控常用的网络设备，服务器系统资源，后台服务进程和软件等，也可以根据需要自行开发相应的客户化插件用于监控特定的资源和事件。
Flickr将告警分为以下几类：
1）Up/Down,例如定期检查Apache Server和一些后台服务的状态，发现响应失败则自动重起服务进程，并通知管理员(根据级别采用事后邮件或实时短信、寻呼等)。对于一些服务或应用，有必要检查每一个子进程或服务的Up/Down的状态；而对另一些服务和应用，则可能需要“整体”来看，比如，几十台Web Server中的一台故障，一般不需要马上处理，而MySQL Master Server故障，则要马上通知DBA。
2）资源不足，例如硬盘空间或网络带宽不足时邮件提醒管理员考虑购买新的硬盘或增加网络带宽。
3）超过或低于阀值，例如CPU利用率，DISK I/O长时间过高等；或者某台Web Server处理的交易请求突然大幅度降低等。
一开始困难往往在于不知道哪些事件需要告警，哪些则可以忽略。Flickr的经验是先定义尽可能多的事件，然后随着运营的稳定和经验数据的积累再逐步减少。另外，定义完善的告警级别和上报流程也有助于减少不必要的人工和尽快排除故障。
网管软件的功能当然不只是“告警”，性能管理和“趋势”管理也越来越成为“企业基础架构管理”的重要组成部分。不过尽管网管软件可以通过扩展来提供一定程度上的此类功能，但SNMP协议本身的效率并不高，而且当网络达到了一定规模时，主动轮询的方式也限制了它的扩展性和采集大量的数据，一般常见的轮询间隔往往只能限定为10－15分钟甚至更长，这样的采样颗粒度有时很难满足精度和精确分析的要求，因而在大型网络环境下，人们通常更倾向于专门的“数据采集和趋势分析“软件，而这其中的佼佼者就是大名鼎鼎的Ganglia
性能管理与容量规划Ganglia诞生于著名的伯克利大学，最早专用于高性能计算（HPC）环境中的cluster和Grid的监控，经过精心设计的数据结构和算法，使得Ganglia能够以较小的开销同时监视数千台节点。
Ganglia的数据流如下图：
外链图片需谨慎，可能会被源头改gmond进程,运行在各个节点负责收集数据，并通过multicast或unicast向运行于后台服务端的gmetd进程发送数据，gmetd汇聚数据并存入RRDTool所管理的Round Robin Database.
Round Robin Database是一种特殊的数据库，它对于存储于其中的数据根据时间的远近而保存不同的数据“分辨率”，比如对于较近时间段数据保存每分钟一个采样点，而对于一年以前的数据则只保留每天一个采样点，超过用户指定的期限如几年则自动将过期数据删除。RRD的理论出发点是人们一般较关心近期数据的精确性，而对于长期数据，则只关心大的趋势。RRD的特点使得它能够将数据库的规模限制在一定大小，而不是随着时间的持续而无限增长，这就解决了在相对长的时间内保存大量趋势数据的关键问题，因而在数据采集和趋势分析软件中得到了广泛的应用。
虽然gmond本身可以采集操作系统一级的大量系统信息，如CPU，内存，硬盘和网络I/O等，但光有这些信息是远远不够的，对于一个网站来说，更重要的是了解这些系统信息所代表或对应的业务信息的含义，比如CPU利用率40％时，网站的平均响应时间是多少，网站同时能够支持的并发用户是多少。这些信息更多的来自于应用或基础构件（如MySQL，Web Server,Memcache,Squid等），而Ganglia提供的另一个程序gmetric，则可以通过cron定期调用script的方式来采集这些客户化的应用层数据并发送到gmetd。例如下面的代码分别用于获取disk util和memcache的命中率,
#!/bin/sh
/usr/bin/iostat -x 4 2 sda | grep -v ^$ | tail -4 > /tmp/
disk-io.tmp
UTIL=`grep sda /tmp/disk-io.tmp | awk '{print $14}'`
/usr/bin/gmetric -t uint16 -n disk-util -v$UTIL -u '%'
。。。。。。
/usr/bin/gmetric -t uint32 -n memcachced_hitratio -v$HITRATIO -u ’%’
Apache,MySQL,Memcache,Squid等一般都可以某种方式提供一定程度上的实时统计信息，通过对这些数据的定期采样（如每分钟），可以很清楚的显示整个系统近乎实时的运营情况，找出各个数据相互之间的关系及其规律，并以此作为容量规划的依据。下面是Flickr的运营主管在一次会议上展示的Flickr的Ganglia系统。
外链图片需谨慎，可能会被源头改除了这些子系统本身提供的一些实时的统计数据外，Web Server的Access Log是另一个重要的统计和性能数据来源。一行典型的Access Log包括：用户的IP地址，访问时间，执行时间（time-taken),网页的URL，HTTP的响应码，数据包大小等。通过对这些Log的分析，我们可以得到很多有用的信息。一个最常见的困难是，如何按照时间顺序汇总几十台甚至数百台Web Server的Log。传统的手工COPY和处理不仅费时，而且COPY的时候占用网络资源较大。所幸的是Spread Toolkit帮我们解决了这个问题，采用Spread toolkit进行开发,我们可以将多台Web Server的Log以multicast的方式实时传输到一台或几台（用于Fail-over）集中的Log Server。特别的对于Apache,可以直接下载和使用一个基于Spread的现成模块mod_log_spread，采用mod_log_spread,Apache避免了本地Log的读写，据说可以提高运行效率20-30%。 对于Log的分析，网上虽然有很多软件，如Report Magic等，但这些软件并不懂你的应用，只能做一些基本的分析，Flickr对于这些Log进行了基于应用的分析和处理，并将结果也导入Ganglia。
Access Log的分析是基于Web页面的，Flickr的技术团队认为这还不足够，因而进一步对于页面的每个task进行计数，比如总共有多少访问是memcache的，多少是直接调用数据库的。最常见的想法是利用数据库，每次访问则更新数据库的记录，这对于每秒访问量成千上万的繁忙网站来说基本上是不可行的，因为连接和更新数据库的开销太大。Flickr使用的是UDP，PHP的相关代码如下：
$fp = fsockopen("udp://$server", $port, $errno, $errstr);
if ($fp){
fwrite($fp, "$value\n");
fclose($fp);
}
$value即是所要计数的counter的名称。一个后台的Perl进程每收到一个counter,就在相应的counter的计数上加1，并定期存入RRD。
计数之外，Flickr还对一些任务计时。一些后台程序定期执行这些特定任务并记录这些任务所花费的时间。
外链图片需谨慎，可能会被源头改由于环境的影响，每次计时可能都会不同，获得标准偏差比简单的取平均值更要有意义。例如下图：
外链图片需谨慎，可能会被源头改此项示例任务平均时间为250ms，75%的任务时间大约340ms，25%的任务在 190ms以内，最下面的浅绿线则是剩下的25%。
Flickr公开了这段代码，有兴趣的可以在这里下载。
最后简单讲一下Flickr如何确定系统的“边界”，即在可接受的性能条件下的最大负载。Flickr并不太看重在测试系统所作的benchmark或者是压力测试。在大多数情况下，测试环境很难完全100%的模拟真实的投产环境，即使软硬件环境完全一致，并完全复制投产系统的数据，因为大量用户的行为是无法完全模拟的。虽然有一些Log replay软件（如Httperf，Siege）可以根据Web Access Log作一定程度的模拟，但一般来说Access Log不包括HTTP POST的请求参数，无法replay,而且replay软件也无法模拟由于地理位置和网络不同而造成的网络迟延等问题。Flickr采用的是“controlled production load testing"，即直接在投产系统测试来取得特定配置下Server的最大负载。这其中的关键是Load Balancer,通过调节Load Balancer的负载分配，逐渐增加指定Server的访问量，直到达到临界值为止。
推荐一本书《The Art of Capacity Planning》,这是Flickr运营主管写的一本关于大型网站容量规划的书，书中没有什么高深的数学公式，完全从实战的角度出发，值得一看。
祝大家新年快乐，虎年吉祥。
元宝推荐：铁手, 通宝推：小豆豆,白开水,大黄,家园 用UDP来更新计数器那个 现在我一下子想不起来要干什么了，但是有个想法也许和这个更新有关系。是早上在上班的路上想的，所以有点记不清了。
应该是记录某种状态，然后再作分析有一定的关系。当时也是有考虑到数据库链接和更新的开销。不过，我在想，比如说我设定一个表，表的名字和日期关联，没有index，只往里面写，不读，然后过一天后换一个表，并将前一天的表拿出来作分析，那样是不是不会有太大的拖累？
不知道为什么用UDP速度会快一些？
多谢好文，要慢慢参考。
另外，关键词用逗号分隔。
也祝新年快乐，虎年吉祥。
家园 UDP肯定比数据库快，但不是总比TCP快 数据库的好处是查询方便，而且安全可靠。其实还是要看流量，比如Flickr一秒中有4万笔照片访问，如果都记数据库的话，不算connection的开销，那么至少要4万笔更新或者插入，这个开销是相当可观的。
UDP是“无连接传输”，即有数据立即传输，不需要象TCP那样先建立连接，而且没有TCP那样的数据流控制，如ACK，“三次握手”，checksum等,因而不能保证100%的可靠传输，但也正是因为没有这些TCP的overhead，因而对系统的资源消耗较少，在数据报文较大时，网络情况较好（比如LAN)时，效率比TCP要高。
在数据报文较小的情况下，也可以考虑试试TCP的Nagle's algorithm，即通过设置TCP_NODELAY的系统参数，可以缓存多个TCP数据包而后一起发送，这时TCP反而可能会比UDP要快，具体环境下最好要测一下才能知道。
以Flickr的情况，TCP不见得比UDP慢，但系统开销肯定要大一些了。
谢谢提示，已修改了关键词。
家园 【原创】Flickr 网站架构研究（6） "Flickr File System"探秘（下）最后来说一说"Stoage Manager"。最早的Flickr系统是没有这一层的，Web/PHP Server在收到用户上载的照片后直接通过NFS协议将照片文件写入后台的NetApp存储。这样带来的问题是：
１。NFS协议的“文件传输”效率成为瓶颈。高效网络文件传输的要点在于使用尽可能大的数据报文和尽量减少传输控制报文的开销，不幸的是，NFS在这两点上都差强人意。
早期的NFS version 2.0使用UDP作为传输协议，但一次最大只能传输8KB.NFS version 3.0消除了这个8KB的限制，并引入了“异步写”的概念，理论上可以将多个小的“写”缓存在“cache”中再合并成一个大的写操作而提高效率，但在实际中往往要看协议的实现情况和操作系统内核的支持，比如至少在早期的LINUX实现中并不理想。
2004年初，University of Massachusetts & IBM Almaden Research Center & University of California联合做了一项关于比较NFS和iSCSI应用于IP存储性能的研究，“A Performance Comparison of NFS and iSCSI for IP-Networked Storage”。在这份研究中，其中一项是在网络协议层比较两者“顺序和随机读写“的效率，结果见下图
外链图片需谨慎，可能会被源头改(Sequential and Random reads and writes: completion times, number of messages and bytes transferred for reading and writing a 128MB file.)我们看到NFSv3的“读”效率和iSCSI基本相当，但在写效率上则有数量级上的差距。从网络协议报文的数量上看，iSCSI远远小于NFSv3，这是因为iSCSI能够以较大的数据包（大约128KB）执行异步写操作，而NFSv3的平均数据包只有4.7KB，其原因是NFSv3在Linux上的实现受到了Linux 内核2.4 cache最大“pending write"数量的限制因而不能充分利用异步写所带来的好处。
在另一项应用层的测试中，研究人员使用PostMark测试了两者在创建，删除，读和附加(append)文件的效率，结果如下：
Completion time (s) Messages
Files NFSv3 iSCSI NFS v3 iSCSI
1,000 146 12 371,963 101
5,000 201 35 451,415 276
25,000 516 208 639,128 66,965
(Completion times and message counts are reported for 100,000 operations on 1,000, 5,000 and 25,000 files)这项测试表明NFSv3协议在文件相关操作中有非常高的"meta-data related overhead",研究人员在分析上面的测试结果发现这一类message占全部message数量的65%。
同样是在2004年，一些操作系统包括Linux等开始部分支持NFSv4。NFSv4除了采用了TCP之外，引入了一些新的特性，其中之一是“Compound RPCs"，即可以一次发送多个RFC请求并取得结果，这样无疑可以大大减少"meta-data"相关的开销，显著的提高协议的总体效率。另一方面，随着Linux内核2.6的成熟并得到逐步采用,Linux在NFS的实现上也有了很大的提高，例如消除了"pending write" 数量的限制等。
然而不幸的是，这些提高对于Flickr所需的“大文件传输”并没有帮助。根据“NFSv4 Test Project”的测试结果
外链图片需谨慎，可能会被源头改在异步模式下，对于小于512KB的文件，NFSv4(红线)大约是NFSv3 (绿线)效率的３倍,但对于大文件和同步模式，则几乎相当或略有提高。
另一项2008年的测试表明，在File Creation操作上，NFSv4甚至要慢于NFSv3.
外链图片需谨慎，可能会被源头改究其原因，NFS是以支持"文件共享"为主要目的，侧重于多路并发访问条件下文件内的修改和同步控制。但是对于"文件传输"为主要目的的应用来说，这些额外的同步和锁机制就成为多余和不必要的开销。
那么Flickr为什么不用ＦＴＰ呢？FTP的主要问题是FTP需要两个端口，一个用于传输实际的文件，另一个用于传输控制命令。我们知道一台机器的端口（0-65535）是有限的，除去保留的系统端口外，真正能用的不过6万３千多个，而在一个高负载的，每秒成千上万访问的环境中，操作系统很容易出现“端口耗尽“的情况而拒绝新的连接。笔者曾经作过一个测试，在200个线程并发访问，每个线程平均５-10秒一笔交易下，30分钟左右,一台缺省配置的Windows 2003 Server就提示端口用尽。虽然可以通过调整Windows注册表或UNIX内核参数即减少tcp wait time的值来加快tcp端口的释放，但毕竟不如只用一个端口。
２。Web/PHP Server直连NetApp的另一个坏处我想大家都应该想到了，那就是应用层和存储管理层绑定的太紧。在直连的情况下，每一台Server都要Mount全部的NFS卷，而任一个NFS卷的故障都可能会影响到所有的Web服务器，或者至少每一个服务器在写操作之前，都要检查目标卷是否可用，如果标记为故障的话要选择并写到另一个卷；而且还要监控所有卷的使用情况，在卷剩余空间小于阀值或者文件数多于阀值时报警并将此卷置为”只读“等。
这些最终导致了专门负责存储管理和写操作的Storage Manager层的出现。Flickr为Web/PHP Server和Storage Manager之间专门设计了”轻量文件传输协议“。协议的主要编码规则如下：
请求：
|STORE|number files|{file1}|{file2}|{file3}|...
每一个{file}块的格式：
|filename|leading byte|file content byte length|file content|
leading byte的值是”file content byte length"字符串的长度。例如１MB的文件，file content byte length 是1048576,则leading byte的值是"1048576"的长度７.
响应：
|OK|volume number of where the file store| or
|Failed|the reason of failed|
协议本身是非常简单的，而且可以在一个报文里传输多个文件。而接受程序则根据文件长度直接截取文件内容，省去了诸如base64等编解码的开销。整个协议代码约600行PHP,包括opening，closing sockets, hot failover to redundant servers, and safe read and writes等.
Web/PHP端的调用示例如下：
function store_file($storage_hosts, $filename){
shuffle($storage_hosts);
foreach($storage_hosts as $host){
$result = store_file_2($host, $filename);
if ($result){ return $result; }
}
return 0;
}
function store_file_2($host, $filename){
...
if ($connection_failed){
return 0;
}
...
if ($operation_failed){
return 0;
}
return $result;
}
代码中的storage_hosts既是Farm中的几台Storage Manager,和前面介绍过的db_query一样，上述代码也实现了简单而有效的load balance.
Storage Manager接受到文件后，将文件放入Offline Queue队列，再由专门的图像处理服务器进行整理，压缩和格式转化（如果需要的话），生成不同尺寸大小的文件，并通过NFS写入NetApp存储。虽然这一步仍然要通过NFS,但此时的操作已是非实时，效率的影响已经不大了。
应当指出，除非不得已，在绝大多数情况下，放弃成熟的公共协议而构建自己的私有协议并非上策。而笔者在文中列出的NFS和FTP的不足，也只是说明当前版本的NFS和FTP不适合于Flickr的特殊应用要求而已。 （NFS的优化不在本文讨论范围内，有兴趣的读者可以参考以下连接：[URL=http://media.netapp.com/documents/tr-3183.pdf
]NetApp的关于NFS Linux白皮书[/URL]和NFS-HOWTO）
那么有没有协议可以满足此类要求呢？个人认为值得关注的有：一。NFS4.1：NFS4.1版本将支持pNFS，即并行NFS,pNFS是近20年来NFS首次在性能上的重大升级,将可能成为高性能、共享文件存储的未来；另一个是SAN+Cluster FileSystem（如RedHat的Global File System和IBM的General Parallel File System)。传统上的SAN协议不直接支持多路并发写，而Cluster FS则弥补了这一缺陷为底层的共享块设备在文件系统级别提供并发的读写功能，因此更能发挥SAN存储架构的协议性能优势。有兴趣的话，大家可以看看这篇文章Red Hat GFS vs. NFS: Improving performance and scalability
元宝推荐：铁手, 通宝推：isamu,家园 什么时候写完？写完后搞个PDF合集，方便反复阅读。 眼看要放假出游了，最好搞个PDF合集，方便随身携带，有空就拿出来翻翻。
家园 花赞好文。 楼主好文， 解释的相当清楚。
有时间是不是再讲讲当前最流行的facebook一类的sns网站的架构？
感觉这类sns网站因为数据之间的相关联系复杂的多，设计架构可能
难度更大。
- 复 花赞好文。
家园 支持此提案:) 之前找到一个基于django的sns框架pinax，在看Flickr架构分析时不自觉地将Flickr和django/pinax作对比，有很多不同之处。希望能听听楼主对sns类架构的分析。
- 复 支持此提案:)
家园 【讨论】大概看了一下pinax，说说自己不成熟的想法 pinax自己的定位是"Pinax is an open-source platform built on the Django Web Framework."，个人感觉是一个快速开发网站的“应用框架”，而我主要的兴趣和强项是“系统架构”，对于应用层的东西没有太多的研究，不敢乱讲。
不过你若是发原创帖介绍pinax的话，我倒是可以趁机学习学习。
。Flickr的应用主体开发于2005年，是最早的一批web2.0网站之一，功能相对是比较单一的，研究它的目的，主要是从大型网站系统架构的“可扩展性”出发的；如果只考虑应用层的框架，功能涵盖，模块设计和可重用性，通用性，易用性等方面来讲，可能比不上pinax。但两者的设计目标不同，这样的比较是否有意义？另一方面，pinax也许较适合刚起步的中小网站，可以快速建站，但网站达到一定规模后是否还适用，似乎尚存疑问。
下一个系列，我会在facebook和amazon之间选一个，目前正在收集资料中。
家园 您说的没错 对，pinax是应用层的，我是初学者，对架构的概念理解很浅，因为pinax/django看上去简单些，所以才从这里入手学习。因为脑子里只有这么一个模型，所以才将Flickr与pinax去比较，倒不是两者有什么值得比较的地方。看了您的文章后，我感觉已经入门了，呵呵。