各个大公司系统架构汇总：google，amazon，linkedin，淘宝，新浪微博，百度（注：相关文献百度文库可搜索）

《转：初步介绍》浅谈大型网站动态应用系统架构

浅谈大型网站动态应用系统架构

动态应用，是相对于网站静态内容而言，是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件，比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。

大型动态应用系统平台主要是针对于大流量、高并发网站建立的底层系统架构。大型网站的运行需要一个可靠、安全、可扩展、易维护的应用系统平台做为支撑，以保证网站应用的平稳运行。

大型动态应用系统又可分为几个子系统：

l        

l        

l        

l        

l        

l        

l        

Web前端系统

结构图：

为了达到不同应用的服务器共享、避免单点故障、集中管理、统一配置等目的，不以应用划分服务器，而是将所有服务器做统一使用，每台服务器都可以对多个应用提供服务，当某些应用访问量升高时，通过增加服务器节点达到整个服务器集群的性能提高，同时使他应用也会受益。该Web前端系统基于Apache/Lighttpd/Eginx等的虚拟主机平台，提供PHP程序运行环境。服务器对开发人员是透明的，不需要开发人员介入服务器管理

负载均衡系统

负载均衡系统分为硬件和软件两种。硬件负载均衡效率高，但是价格贵，比如F5等。软件负载均衡系统价格较低或者免费，效率较硬件负载均衡系统低，不过对于流量一般或稍大些网站来讲也足够使用，比如lvs/nginx/haproxy。大多数网站都是硬件、软件负载均衡系统并用。

数据库集群系统

结构图：

由于Web前端采用了负载均衡集群结构提高了服务的有效性和扩展性，因此数据库必须也是高可靠的才能保证整个服务体系的高可靠性，如何构建一个高可靠的、可以提供大规模并发处理的数据库体系？

我们可以采用如上图所示的方案：

1)        使用 MySQL 数据库，考虑到Web应用的数据库读多写少的特点，我们主要对读数据库做了优化，提供专用的读数据库和写数据库，在应用程序中实现读操作和写操作分别访问不同的数据库。

2)        使用 MySQL Replication 机制实现快速将主库（写库）的数据库复制到从库（读库）。一个主库对应多个从库，主库数据实时同步到从库。

3)        写数据库有多台，每台都可以提供多个应用共同使用，这样可以解决写库的性能瓶颈问题和单点故障问题。

4)        读数据库有多台，通过负载均衡设备实现负载均衡，从而达到读数据库的高性能、高可靠和高可扩展性。

5)        数据库服务器和应用服务器分离。

6)        从数据库使用BigIP做负载均衡。

缓存系统

缓存分为文件缓存、内存缓存、数据库缓存。在大型Web应用中使用最多且效率最高的是内存缓存。最常用的内存缓存工具是Memcachd。使用正确的缓存系统可以达到实现以下目标：

1、   使用缓存系统可以提高访问效率，提高服务器吞吐能力，改善用户体验。

2、   减轻对数据库及存储集服务器的访问压力

3、 Memcached服务器有多台，避免单点故障，提供高可靠性和可扩展性，提高性能。

分布式存储系统

结构图：

WEB系统平台中的存储需求有下面两个特点：

1) 存储量很大，经常会达到单台服务器无法提供的规模，比如相册、视频等应用。因此需要专业的大规模存储系统。

2) 负载均衡cluster中的每个节点都有可能访问任何一个数据对象，每个节点对数据的处理也能被其他节点共享，因此这些节点要操作的数据从逻辑上看只能是一个整体，不是各自独立的数据资源。

因此高性能的分布式存储系统对于大型网站应用来说是非常重要的一环。（这个地方需要加入对某个分布式存储系统的简单介绍。）

分布式服务器管理系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，原来基于单机的服务器管理模式已经不能够满足我们的需求，新的需求必须能够集中式的、分组的、批量的、自动化的对服务器进行管理，能够批量化的执行计划任务。

在分布式服务器管理系统软件中有一些比较优秀的软件，其中比较理想的一个是 Cfengine。它可以对服务器进行分组，不同的分组可以分别定制系统配置文件、计划任务等配置。它是基于C/S 结构的，所有的服务器配置和管理脚本程序都保存在Cfengine Server上，而被管理的服务器运行着 Cfengine Client 程序，Cfengine Client通过SSL加密的连接定期的向服务器端发送请求以获取最新的配置文件和管理命令、脚本程序、补丁安装等任务。

有了Cfengine 这种集中式的服务器管理工具，我们就可以高效的实现大规模的服务器集群管理，被管理服务器和 Cfengine Server 可以分布在任何位置，只要网络可以连通就能实现快速自动化的管理。

代码发布系统

结构图：

随着网站访问流量的不断增加，大多的网络服务都是以负载均衡集群的方式对外提供服务，随之集群规模的扩大，为了满足集群环境下程序代码的批量分发和更新，我们还需要一个程序代码发布系统。

这个发布系统可以帮我们实现下面的目标：

1) 生产环境的服务器以虚拟主机方式提供服务，不需要开发人员介入维护和直接操作，提供发布系统可以实现不需要登陆服务器就能把程序分发到目标服务器。

2) 我们要实现内部开发、内部测试、生产环境测试、生产环境发布的4个开发阶段的管理，发布系统可以介入各个阶段的代码发布。

3) 我们需要实现源代码管理和版本控制，SVN可以实现该需求。

这里面可以使用常用的工具Rsync，通过开发相应的脚本工具实现服务器集群间代码同步分发。

linked in 的构架

2008年09月25日 星期四 11:04

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); they 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程序，也就是就是说java的的垃圾搜集性能不太好
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。所有的操作都是异步的。

新浪微博架构设计：

人人网feed设计 http://news.csdn.net/a/20100726/277273.html

新浪微博设计 http://www.slideshare.net/iso1600/cache-4842490

新浪杨卫华：谈微博Cache设计 http://john521.iteye.com/blog/779695

微博架构与平台安全演讲稿  http://timyang.net/architecture/weibo/

web缓存 http://www.slideshare.net/jeffz/web-2026379

微博后台架构浅析 http://hi.baidu.com/leolance/blog/item/79870ba9d7d2c4134b36d6ab.html

LRU缓存算法实例分析 http://www.cnblogs.com/onlytiancai/archive/2009/07/22/wawa_lru.html

赵振平：项目成败取决于数据库架构设计 http://tech.chinaunix.net/a2011/0416/1178/000001178961.shtml

常用缓存算法简介 http://www.blogjava.net/DL88250/archive/2011/01/21/343327.html

基于LRU淘汰的高性能缓存简单实现 http://www.cnblogs.com/yiway/archive/2011/07/15/High_Performance_Cache.html

用Twitter的cursor方式进行Web数据分页 http://timyang.net/web/pagination/

 关于outbox缓存，最近200条记录总是被缓存而不删除(HOT CACHE)，以及历史记录的LRU缓存(ARCHIVE CAC