各大网站架构简单总结[分享]

1、Facebook架构
大体层次划分,Facebook的架构可以从不同角度来换分层次。一种是:一边是PHP整的经典的LAMP stack;另外一个是非PHP整的各种service。
--Web 前端是由 PHP 写的。Facebook 的HipHop会把PHP转成C++并用g++编译,这样就可以为模板和Web逻贺业务层提供高的性能。
--业务逻辑以Service的形式存在,其使用Thrift。这些Service根据需求的不同由PHP,C++或Java实现(也可以用到了其它的一些语言……)
--持久化由MySQL, Memcached, Facebook的Cassandra, Hadoop的HBase完成。Memcached使用了MySQL的内存Cache。Facebook工程师承认他们的Cassandra使用正在减少,因为他们更喜欢HBase,因为它的更简单的一致性模型,以到其MapReduce能力。

2、Flickr网站架构总结

Flickr.com是网上最受欢迎的照片共享网站之一,还记得那位给Windows Vista拍摄壁纸的Hamad Darwish吗?他就是将照片上传到Flickr,后而被微软看中成为Vista壁纸御用摄影师。

--Pair of ServerIron's做负载均衡

--Squid做html和照片的缓存

--Memcached做数据缓存

--尤其是mysql数据库采用master-slave和shards技术实现了mysql数据库的负载均衡,解决了数据库的瓶颈,达到了数据库横向扩展的目标。

3、YouTube架构总结

这个貌似在国内是被和谐的,要fan qiang才能访问(不知到底何故)。看看他的架构
--NetScaler用于负载均衡和静态内容缓存
--使用lighttpd作为Web服务器来提供视频服务
--CDN在多个地方备份内容,这样内容离用户更近的机会就会更高
--使用Google的BigTable,一个分布式数据存储、数据库分成shards,不同的用户指定到不同的shards、使用BigTable将图片备份到不同的数据中心,代码查看谁是最近的

4、PlentyOfFish架构总结

这个我觉的最神奇了,一个人每天花2个小时,可以维护一个每天3000W PV的,而且是基于.NET的(呵呵,终于给我们.net程序员一个好榜样了)。简述他的架构
--用Microsoft Windows操作系统作为服务器

--使用ASP.NET技术

--使用IIS作为Web容器

--用Akamai CDN来缓存网页

--用Foundry ServerIron 来做负载均衡

--sqlserver采用master-slave架构,两台负责read操作,master那台负责写操作

--所有的request数据都使用了gzip压缩

5、WikiPedia架构总结

维基百科(Wikipedia)是一个基于Wiki技术的全球性多语言百科全书协作计划,同时也是一部在网际网路上呈现的网路百科全书,其目标及宗旨是为全人类提供自由的百科全书——用他们所选择的语言来书写而成的,是一个动态的、可自由和的全球知识体。

--GeoDNS让用户能够访问离他地域最近的Web服务器

--用LVS实现负载均衡

--用Lighttpd做图片服务器

--使用MediaWiki软件

--大量缓存(Cache),Squid作为反向代理,Memcached做数据缓存

--用Mysql数据库集群

6、Google架构

Google的架构大概地整理一下:

--GFS,Google的强有力的面向大规模数据密集型应用的、可伸缩的分布式文件系统

--MapReduce,Google的分布式并行计算系统,GFS存储数据,而MapReduce则是以最快最可靠的方式处理数据。

--BigTable,Google基于GFS和MapReduce之上的用来存储结构化数据的解决方案,有了它,不仅可以存储结构化的数据,而且可以更好的管理和做出负载均衡决策。

7、优酷网架构

在国内,上不了YouTube,只能看看优酷了,说实在优酷在国内算是做的不错了,视频加载速度明显比土豆什么的要快,那就看看他的架构吧:

--自建的一个模块化的CMS系统,前端十分灵活

--mysql数据库从单台MySQL服务器(Just Running)到简单的MySQL主从复制、SSD优化、垂直分库、水平sharding分库,解决数据库服务器的灵活横向扩展。

--为了避免内存拷贝和内存锁,没有(很少)用内容缓存。

--最核心的是构建了比较完善的CDN网络,就近原则,让你看视频时从离你最近的服务器上获取视频信息,所以我们看优酷比土豆要快,原因就在这里。

8、Twitter架构

twitter,怎么说呢,说他简单么还真简单,但又是那么复杂,真是纠结。话说这140个字的鼻祖让国内的某某某非常风骚,算了不跑题了,说说他的架构吧:

--平台比较广泛:

-Ruby on Rails:web应用程序的框架
-Erlang:通用的面向并发的编程语言,开源项目地址:
http://www.erlang.org/
-AWStats:实时日志分析系统:开源项目地址:http://awstats.sourceforge.net/
-Memcached:分布式内存缓存组建
-Starling:Ruby开发的轻量级消息队列
-Varnish:高性能开源HTTP加速器
-Kestrel:scala编写的消息中间件,开源项目地址:
http://github.com/robey/kestrel
-Comet Server:Comet是一种ajax长连接技术,利用Comet可以实现服务器主动向web浏览器推送数据,从而避免客户端的轮询带来的性能损失。
-libmemcached:一个memcached客户端
-使用mysql数据库服务器
-Mongrel:Ruby的http服务器,专门应用于rails,开源项目地址:
http://rubyforge.org/projects/mongrel/
-Munin:服务端监控程序,项目地址:http://munin-monitoring.org/
-Nagios:网络监控系统,项目地址:http://www.nagios.org/
--细化memcached,同时建立向量缓存Vector Cache、行缓存Row Cache、碎片缓存Fragmeng Cache、缓存池Page Cache
--给力的消息队列,用Ruby写的一个分布式队列 Starling

9、Yupoo网站架构

一个试图做国内最好的图片服务提供商,虽然和Flickr还有点差距,但也不错了,话说搞图片和视频的是很烧服务器和带宽的,在国内这么贵的带宽也挺不容易的,好了,一起看看他的架构吧:

--Squid,这个貌似做图片缓存挺好使的,而且还是分布式的,可以硬盘命中和内存命中,速度都还不错。

--MogileFS图片存储

--mysql分库设计,垂直分库,水平sharding,跨库关联查询

--透明的缓存设计

10、Amazon网站架构

这个Amazon从小书店开始现在成了全球商品品种最多的网上零售商和全球第2大互联网公司,貌似很风光嘛,那架构一定很犀利的,下面一起来看看:

--平台,Linux、oracle、C++、Perl、Mason、Java、Jboss、Servlets

--Dynamo Key-Value存储架构

  • 0
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
大型网站架构演化 大型网站软件系统的特点 大型网站架构演化发展历程 初始阶段 应用服务和数据服务分离 使用缓存改善网站性能 缓存类型 本地缓存 分布式缓存 缓存产品 redis 业界主流 memcached 解决问题 数据库访问 使用应用服务器集群改善网站的并发处理能力 问题: 负载均衡情况下session状态的保持? 解决方案: 基于DNS的负载均衡 反向代理 ngix JK2 数据库的读写分离 问题: 读库与写库的数据同步 解决方案: 不同的数据库都有自己的数据库的主从复制功能 使用反向代理与CDN加速网站响应 反向代理产品 ngix 使用分布式文件系统和分布式数据库系统 使用no-sql和搜索引擎 站内搜索 lucene nutch 分词器 no-sql库 mongodb hadoop 业务拆分 web service restful 分布式服务 大型网站架构演化的价值观 核心价值:随网站所需灵活应对 驱动力量:网站的业务发展 网站架构设计误区 一味追随大公司的解决方案 为技术而技术 企图用技术解决一切问题 大型网站架构模式 架构模式 分层 分割 分布式 分布式应用和服务 分布式静态资源 分布式数据和存储 分布式计算 集群 缓存 CDN 反向代理 本地缓存 分布式缓存 异步 冗佘 冷备份 主从分离,实时同步实现热备份 灾备数据中心 自动化 发布过程自动化 ant maven. 自动化代码管理 svn cvs github 自动化测试 loadrunner hudson. 自动化安全测试 自动化部署 自动化报警 自动化失效转移 自动化失效恢复 自动化降级 自动化分配资源 安全 密码和手机校验码 数据库中的密码加密后存 -> 不可ni -> md5 加密 子主题 1 验证码 防止机器登录 对于攻击网站的XSS攻击,SQL注入,进行编码转换 对垃圾信息,敏感信息进行过滤 对交易转账等重要操作根据交易模式和交易信息进行风险控制 Sina微博的应用 大型网站架构要素 性能 可用性 伸缩性 扩展性 安全性 瞬时响应:网站的高性能架构 网站的性能测试 不同的视角 用户的视角 开发人员的视角 运维人员的视角 性能测试指标 响应时间 并发数 吞吐量 性能测试方法 性能测试 负载测试 压力测试 稳定性测试 web 前端性能优化 浏览器优化 减少http请求 使用浏览器缓存 启用压缩 css上,js下 减少cookie传输, 静态资源使用独立域名访问 CDN加速 反向代理 应用服务器性能优化 分布式缓存 缓存的原理 合理使用缓存 频繁修改的数据 没有热点的访问 数据不一致和脏读 缓存可用性 缓存预热 缓存穿透 缓存架构 jboss cache为代表的需要更新同步的分布式级缓存 以memcached为代表的不互相通信的分布式缓存 异步操作 使用集群 代码优化 多线程 资源复用 单例 对象池 数据结构 垃圾回收 存储性能优化 固态硬盘 RAID与HDFS 万无一失:网站的高可用性 高可性的度量与考核 度量 考核 高可用的网站架构 高可用的应用 高可用的服务 高可用的数据 CAP原理 数据备份 失效转移 高可用网站的软件质量保证 网站发布 自动化测试 预发布验证 代码控制 自动化发布 灰度发布 网站运行临控 临控数据采集 临控管理 永无止境:网站的可伸缩性 网站架构的伸缩性设计 不同功能进行物理分离实现伸缩 单一功能通过集群规模实现伸缩 应用服务器集群的伸缩性设计 http重定向负载均衡 DNS域名解析负载均衡 反向代理负载均衡 ip负载均衡 数据链路层负载均衡 负载均衡算法 分布式缓存集群的伸缩性设计 memcached分布式缓存集群的访问模型 memcached分布式缓存集群的伸缩性挑战 分布式缓存的一致性hash算法 数据存储服务器集群的伸缩性设计 关系数据库集群的伸缩性设计 nosql数据库的伸缩性设计 随需应变:网站的可扩展性 构建可扩展的网站架构 利用分布式消息队列降低系统耦合性 事件驱动架构 分布式消息队列 利用分布式服务打造可复用的业务平台 web service与企业级分布式服务 大型网站分布式服务的需求与特点 分布式服务框架设计 可扩展的数据结构 利用开放平台建设网站生态圈 固若金汤:网站的安全架构 网站应用攻击与防御 XSS攻击 反射型 持久型 防御方法 消毒 httponly 注入攻击 SQL注入攻击 攻击前提 获取数据库结构的方法 防御方法 消毒 参数绑定 OS注入攻击 CSRF攻击 防御方法 表单token 验证码 referer check 1. 网络流量统计 2. 防盗链 error code html注释 文件上传 web应用防火墙 modsecurity NEC的 siteshell 网站安全漏洞扫描 信息加密技术及密钥安全管理 案例: CSDN 信息加密技术分类 单项散列加密 对称加密 非对称加密 密钥安全管理 将密钥和算法放在一个独立的服务器上,对外提供加密和解密服务 密钥放在独立服务器中,算法放在应用程序中。 信息过滤与反垃圾 文本匹配_敏感词过滤 正则表达式 trie树 双数组trie树 多级Hash表 信息降噪 分类算法_内容识别 黑名单 电子商务风险控制 风险 账户风险 买家风险 卖家风险 交易风险 风控 人工 自动 规则引擎 统计模型 案例 网购秒杀系统架构 网购秒杀系统架构
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值