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

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

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

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

猜你喜欢