学习构建社交网站之一：技术框架概述

    最近老板安排了个项目要做一个大的社交网站，小组成员都是新手（当然我也是），对于构建一个大的社交网站在技术上可以说是一无所知。前一阵用SSH实现过一个简单的应用网站，小规模应用并且尚处于部分用户测试阶段。为下一步开发做技术准备，最近在网上搜搜大型网站的技术架构之类的东东，放在这儿算个总结。

1. Facebook的网站架构

    谈社交网站当然首先参考的就是巨头Facebook。据2008年统计，Facebook有1.2亿活跃用户，每月500亿+页面浏览量，100亿+照片，10亿+连接，5万+Apps，40万App开发者....

    在QCon 2008旧金山会议上，Facebook的技术主管Aditya Agarwal讨论了Facebook的网站架构（视频和幻灯片），讨论主要集中在运行的软件方面。Facebook采用的是典型的LAMP（Linux、Apache、MySQL和PHP）架构，后台服务器是使用C++和Java编写的，其它主要组件包括Memcache缓存管理, Thrift RPC框架和Scribe分布式日志服务器。部分中文介绍可参见DBA notes。

•     *　LAMP部分。。。待编辑   
•  
•     *　Memcache缓存管理。。。待编辑
• 
  
•     *　Thrift RPC框架。

    RPC（Ｒｅｍｏｔｅ　Ｐｒｏｃｅｄｕｒｅ　Ｃａｌｌ　Ｐｒｏｔｏｃａｌ，远程过程调用协议） 在大规模的互联网应用后端技术中非常常见，我们熟悉的搜索引擎、门户、网游服务器等，后端实现中都有涉及。主要原理是基于内网 socket 解决多机多模块之间的数据通讯问题。或者可以简单理解为，将单机的进程间通讯 (IPC) (wiki)，扩展到多机通讯，解决可扩展性问题。
　　
　　Thrift 是由 Facebook 开源的一个 RPC 框架，现在已经挂在 apache.org 下了。主要的几个好处：
　　支持非常多语言，包括在 WEB 开发中很常用的 PHP，以及最重要的 C++/Python/Java 等 WEB后端常用语言，当然，还包括很 cool 的 Ruby、Erlang。
　　完整的 RPC 框架实现，用脚本生成通讯相关的框架代码，开发者只需要集中精力处理好业务逻辑。比如搭建一个 Hello World Service 只需要几分钟。
　　拥有被 Facebook、Last.fm 等不少大规模互联网应用验证过的性能和可用性。
　　
　　在 PRC 通讯方面，其实已经成熟多年。比如百度内部是自己定制的二进制协议，比如C++下使用较多的 ACE 框架。而 Thrift 在最近两年脱颖而出，也的确和其跨语言、方便的代码生成框架、以及适于目前高速发展的互联网应用而出名。另外许多人拿 Thrift 和 google 推动的 Protocol Buffer 比较，有不少文章可以参考。
　　国内从目前的状况看，Thrift 相关的讨论和应用还不太多。一方面国内的寡头大型互联网企业多数使用自己的协议，没有动力开源，也没有引入的需求。一方面小型互联网公司虽然不少，但规模较大的还很少，大部分公司的业务量，还不太需要 RPC 这类多模块多机的架构去支撑。
　　另一方面，Thrift 的确系出名门，它的代码实现的很优秀，逻辑层次清楚，易于定制扩展。框架代码生成方便，节省很多通讯方面的开发和调试时间。

２．LinkedIn网站技术架构

在JavaOne 2008的会议上，著名社交网站LinkedIn的开发者做了2个关于LinkedIn网站的架构技术的演讲

可以看一下LinkedIn网站的基本情况：

1. 2千2百万用户
2. 每个月4百万独立用户访问
3. 每天4千万Page View
4. 每天2百万搜索流量
5. 每天25万邀请发送
6. 每天1百万的回答提交
7. 每天2百万的Email消息发送

这是一个世界顶尖级别流量的网站了，看看LinkedIn的系统架构：

• 操作系统：Solaris (running on Sun x86 platform and Sparc)
• 应用服务器：Tomcat and Jetty as application servers
• 数据库：Oracle and MySQL as DBs
• 没有ORM，直接用JDBC No ORM (such as Hibernate); th** use straight JDBC
• 用ActiveMQ在发送JMS. (It's partitioned by type of messages. Backed by MySQL.)
• 用lucene做搜索Lucene as a foundation for search
• Spring做逻辑架构Spring as glue

下面是随着流量增加，LinkedIn的架构演化：

2003~2005

1 一个整体的web程序，
2 一个核心数据库，
3 在Cloud中缓存所有network图，Cloud是用来做缓存的独立server。
4 用Lucene做搜索，也跑在Cloud中。

2006年

1 复制另外一个数据库，减少直接Load核心数据库，另外一个Server来管理非只读数据库的数据更新。
2 把搜索从Cloud中移出来，单独一个Server跑搜索
3 增加Databus数据总线来更新数据，这是通过分布式更新的核心组件，任何组件都需要Databus

2008年

1 Webapp不再任何事情都自己做，把业务逻辑分成很多部分，通过Server群来做。Webapp仍然提供用户界面给用户，但是，通过Server群来管理用户资料，小组等等。
2 每个服务有自己的域数据库
3 新的架构允许其他应用链接LinkedIn，比如增加的招聘和广告业务。

The Cloud

1 Cloud是整个架构最重要的部分，整个LinkedIn的网络图都缓存在Cloud里面
2 Cloud大小：22M nodes, 120M edges
3 需要12GB RAM
4 在生产环境要跑40个实例
5 从硬盘重建Cloud一个实例需要8个小时
6 Cloud通过databus实时更新
7 关闭时持久化到硬盘
8 缓存通过C++实现，用JNI调用，LinkedIn选择C++而不是Java有两个原因：

1）尽可能的减少RAM的使用
2）垃圾收集暂停会杀死整个系统，LinkedIn用了最新的GC程序

9 将所有东西放在缓存里面是一种限制，但是LinkedIn指出，分割业务图将更麻烦
10 Sun提供了2TB的RAM

Communication Architecture交流架构包括：

Communication Service

Communication Service是用来提供永久信息的，比如收件箱里面的消息和email

1 整个系统通过JMS异步通讯
2 客户端用JMS发送消息
3 消息通过路径服务器来到达相应的邮箱或者直接放到email进程中
4 消息发送：同时使用Pull主动寻求信息(如用户需要信息)和Push发送信息(如发email)
5 使用Spring和LinkedIn专业Spring插件完成，使用HTTP-RPC

Scaling Techniques

1 通过功能来划分：发送，接受，文档等。
2 通过类别来划分：用户信箱，访问者信箱等
3 等级划分：用户ID等级，Email等级等
4 所有的操作都是异步的。

参考：
１．http://hi.baidu.com/lfqiang/blog/item/5bb6f013fba2db0e5baf5338.html
２．http://www.20ju.com/content/V83376.htm

３．http://www.kuqin.com/system-analysis/20090508/50430.html