| Subcribe via RSS

[转载]大型网站运维探讨和心得

11月 6th, 2008 | 1 Comment | Posted in 系统监控, 网站架构, 读书笔记, 集中存储 < by Michael Field >

看到一篇不错的心得体会;相信我们做技术的都会有或多或少的担忧自己的未来职业发展:

今天看到一篇心得体会,转过来和大家一起探讨一下:

一、什么是大型网站运维?
首先明确一下,全文所讲的”运维“是指:大型网站运维,与其它运维的区别还是蛮大的;然后我们再对大型网站与小型网站进行范围定义,此定义主要从运维复杂性角度考虑,如网站规范、知名度、服务器量级、pv量等考虑,其它因素不是重点;因此,我们先定义服务器规模大于1000台,pv每天至少上亿(至少国内排名前10),如sina、baidu、QQ,51.com等等;其它小型网站可能没有真正意义上的运维工程师,这与网站规范不够和成本因素有关,更多的是集合网络、系统、开发工作于一身的“复合性人才”,就如有些公司把一些合同采购都纳入了运维职责范围,还有如IDC网络规划也纳入运维职责。所以,非常重要一定需要明白:运维对其它关联工种必须非常了解熟悉:网络、系统、系统开发、存储,安全,DB等;我在这里所讲的运维工程师就是指专职运维工程师。
我们再来说说一般产品的“出生”流程:
1、首先公司管理层给出指导思想,PM定位市场需求(或copy成熟应用)进行调研、分析、最终给出详细设计。
2、架构师根据产品设计的需求,如pv大小预估、服务器规模、应用架构等因素完成网络规划,架构设计等(基本上对网络变动不大,除非大项目)
3、开发工程师将设计code实现出来、测试工程师对应用进行测试。
4、好,到运维工程师出马了,首先明确一点不是说前三步就与运维工作无关了,恰恰相反,前三步与运维关系很大:应用的前期架构设计、软/硬件资源评估申请采购、应用设计性能隐患及评估、IDC、服务性能\安全调优、服务器系统级优化(与特定应用有关)等都需运维全程参与,并主导整个应用上线项目;运维工程师负责产品服务器上架准备工作,服务器系统安装、网络、IP、通用工具集安装。运维工程师还需要对上线的应用系统架构是否合理、是否具备可扩展性、及安全隐患等因素负责,并负责最后将产品(程序)、网络、系统三者进行拼接并最优化的组合在一起,最终完成产品上线提供用户使用,并周而复使:需求->开发(升级)->测试->上线(性能、安全问题等之前预估外的问题随之慢慢就全出来了)在这里提一点:网站开发模式与传统软件开发完全不一样,网站一天开发上线1~5个升级版本是家常便饭,用户体验为王嘛,如果某个线上问题像M$ 需要1年解决,用户早跑光了;应用上线后,运维工作才刚开始,具体工作可能包括:升级版本上线工作、服务监控、应用状态统计、日常服务状态巡检、突发故障处理、服务日常变更调整、集群管理、服务性能评估优化、数据库管理优化、随着应用PV增减进行应用架构的伸缩、安全、运维开发工作:
a 、尽量将日常机械性手工工作通过工具实现(如服务监控、应用状态统计、服务上线等等),提高效率。
b、解决现实中服务存在的问题,如高可靠性、可扩展性问题等。
c、大规模集群管理工具的开发,如1万台机器如何在1分钟内完成密码修改、或运行指定任务?2000台服务器如何快速安装操作系统?各分布式IDC、存储集群中数PT级的数据如何快速的存储、共享、分析?等一系列挑战都需运维工程师的努力。
在此说明一下其它配合工种情况,在整个项目中,前端应用对于网络/系统工程师来说是黑匣子,同时开发工程师职责只是负责完成应用的功能性开发,并对应用本身性能、安全性等应用本身负责,它不负责或关心网络/系统架构方面事宜,当然软/硬件采购人员等事业部其它同事也不会关心这些问题,各司其职,但项目的核心是运维工程师~!所有其它部门的桥梁。
上面说了很多,我想大家应该对运维有一些概念了,在此打个比方吧,如果我们是一辆高速行驶在高速公路上的汽车,那运维工程师就是司机兼维修工,这个司机不简单,有时需要在高速行驶过程中换轮胎、并根据道路情况换档位、当汽车速度越来越快,汽车本身不能满足高速度时对汽车性能调优或零件升级、高速行进中解决汽车故障及性能问题、时刻关注前方安全问题,并先知先觉的采取规避手段。这就是运维工作~!
最后说一下运维工程师的职责:”确保线上稳定“,看似简单,但实属不容易,运维工程师必须在诸多不利因素中进行权衡:新产品模式对现有架构及技术的冲击、产品高频度的升级带来的线上BUG隐患、运维自动化管理承度不高导致的人为失误、IT行业追求的高效率导致流程执行上的缺失、用户增涨带来的性能及架构上的压力、IT行业宽松的技术管理文化、创新风险、互联网安全性问题等因素,都会是网站稳定的大敌,运维工程师必须把控好这最后一关,需具体高度的责任感、原则性及协调能力,如果能做到各因素的最佳平衡,那就是一名优秀的运维工程师了。
另外在此聊点题外话,我在这里看到有很多人要sina、QQ、baidu,51.com等聊自已的运维方面的经验,其实这对于它们有点免为其难:
a、各公司自已网络架构、规模、或多或少还算是公司的核心秘密,要保密,另外,对于大家所熟知的通用软件、架构,由于很多公司会根据自已实际业务需要,同时因为原版性能、安全性、已知bug、功能等原因,进行过二次开发(如apache,php,mysql),操作系统内核也会根据不同业务类型进行定制的,如某些应用属于运算型、某些是高IO型、或大存储大内存型。根据这些特点进行内核优化定制,如sina就在memcache上进行过二次开发,搞出了一个MemcacheDB,具体做得如何我们不谈,但开源了,是值得称赞的,国内公司对于开源基本上是索取,没有贡献;另外,服务器也不是大家所熟知的型号,根据业务特点,大部份都是找DELL/HP/ibm进行过定制;另外,在分布式储存方面都有自已解决方案,要不就是使用现成开源hadoop等解决方案,或自已开发。但90%都是借鉴google GFS的思想:分布式存储、计算、大表。
b、各公司业务方向不一样,会导致运维模式或方法都不一样,如51.com和baidu运维肯定区别很大,因为他们业务模式决定了其架构、服务器量级、IDC分布、网络结构、通用技术都会不一样,主打新闻门户的sina与主打sns的51.com运维模式差异就非常大,甚至职责都不大一样;但有一点,通用技术及大致架构上都大同小异,大家不要太神化,更多的公司只是玩垒积木的游戏罢了,没什么技术含量。
c、如上面所讲,目前大型网站运维还处于幼年时期理念和经验都比较零散,没有成熟的知识体系,可能具体什么是运维,大家都要先思索一番,或压根没想过,真正讨论也只是运维工作的冰山一角,局限于具体技术细节,或某某著名网站大的框架,真正运维体系化东西没有,这也许是目前网上运维相关资料比较少的原故吧。或者也是国内运维人员比较难招,比较牛的运维工程师比较少见的原因之一吧。

二、运维工作师需要什么样的技能及素质
做为一名运维工程师需要什么样的技能及素质呢,首先说说技能吧,如大家上面所看到,运维是一个集多IT工种技能与一身的岗位,对系统->网络->存储->协议->需求->开发->测试->安全等各环节都需要了解一些,但对于某些环节需熟悉甚至精通,如系统(基本操作系统的熟悉使用,*nix,windows..)、协议、系统开发(日常很重要的工作是自动运维化相关开发、大规模集群工具开发、管理)、通用应用(如lvs、ha、web server、db、中间件、存储等)、网络,IDC拓朴架构;
技能方面总结以下几点:
1、开发能力,这点非常重要,因为运维工具都需要自已开发,开发语言:c/c++(必备其中之一)、perl、python、php(其中之一)、shell(awk,sed,expect….等),需要有过实际开发经验,否则工作会非常痛苦。
2、通用应用方面需要了解:操作系统(目前国内主要是linux、bsd)、webserver相关(nginx,apahe,php,lighttpd,java。。。)、数据库(mysql,oralce)、其它杂七八拉的东东。。。系统优化,高可靠性。。。这些只是加分项,不需必备,可以边工作边慢慢学,这些东西都不难。当然在运维中,有些是有分工偏重点不一样。
3、系统、网络、安全,存储,CDN,DB等需要相当了解,知道其相关原理。
个人素质方面:
1、 沟通能力、团队协作:运维工作跨部门、跨工种工作很多,需善于沟通、并且团队协作能力要强;这应该是现代企业的基本素质要求了,不多说。
2、工作中需胆大心细:胆大才能创新、不走寻常路,特别对于运维这种新的工种,更需创新才能促进发展;心细,运维工程师是网站admin,最高线上权限者,一不小心就会遗憾终生或打入十八层地狱。
3、主动性、执行力、精力旺盛、抗压能力强:由于IT行业的特性,变化快;往往计划赶不上变化,运维工作就更突出了,比如国内各大公司服务器往往是全国各地,哪里便宜性价比高,就那往搬,进行大规模服务迁移(牵扯的服务器成百上千台),这是一个非常头痛的问题;往往时间非常紧迫,如限1周内完成,这种情况下,运维工程师的主动性及执行力就有很高的要求了:计划、方案、服务无缝迁移、机器搬迁上架、环境准备、安全评估、性能评估、基建、各关联部门扯皮,7X24小紧急事故响应等。
4、其它就是一些基本素质了:头脑要灵光、逻辑思维能力强、为人谦虚稳重、亲和力、乐于助人、有大局观。
5、最后一点,做网站运维需要有探索创新精神,通过创新型思维解决现实中的问题,因为这是一个处于幼年的职业(国外也一样,但比国内起步早点),没有成熟体系或方法论可以借鉴,只能靠大家自已摸索努力。

三、怎样才算是一个合格的运维工程师
1、保证服务达到要求的线上标准,如99.9%;保证线上稳定,这是运维工程师的基本责职所在。
2、不断的提升应用的可靠性与健壮性、性能优化、安全提升;这方面非常考验主动性、和创新思维。
3、网站各层面监控、统计的覆盖度,软件、硬件、运行状态,能监控的都需要监控统计,避免监控死角、并能实时了解应用的运转情况。
4、通过创新思维解决运维效率问题;目前各公司大部份运维主要工作还是依赖人工操作干预,需要尽可能的解放双手。
5、运维知识的积累与沉淀、文档的完备性,运维是一个经验性非常强的岗位,好的经验与陷阱都需积累下来,避免重复性范错。
6、计划性和执行力;工作有计划,计划后想法设法达到目标,不找借口。
7、自动化运维;能对日常机械化工作进行提炼、设计并开发成工具、系统,能让系统自动完成的尽量依靠系统;让大家更多的时间用于思考、创新思维、做自已喜欢的事情。
以上只是技术上的一些层面,当然个人意识也是很重要的。

四、运维职业的迷惘、现状与发展前景
运维岗位不像其它岗位,如研发工程师、测试工程师等,有非常明确的职责定位及职业规划,比较有职业认同感与成就感;而运维工作可能给人的感觉是哪方面都了解一些,但又都比上专职工程师更精通、感觉平时被关注度比较低(除非线上出现故障),慢慢的大家就会迷惘,对职业发展产生困惑,为什么会有这种现象呢? 除了职业本身特点外,主要还是因为对运维了解不深入、做得不深入导致;其实这个问题其它岗位也会出现,但我发现运维更典型,更容易出现这个问题;

针对这个问题我谈一下网站运维的现状及发展前景(也在思考中,可能不太深入全面,也请大家斧正补充)

运维现状:
1、处于刚起步的初级阶段,各大公司有此专职,但重视或重要承度不高,可替代性强;小公司更多是由其它岗位来兼顾做这一块工作,没有专职,也不可能做得深入
2、技术层次比较低;主要处于技术探索、积累阶段,没有型成体系化的理念、技术。
3、体力劳动偏大;这个问题主要与第二点有关系,很多事情还是依靠人力进行,没有完成好的提练,对于大规模集群没有成熟的自动化管理方法,在此说明一下,大规模集群与运维工作是息息相关的如果只是百十来台机器,那就没有运维太大的生存空间了。
4、优秀运维人才的极度缺乏;目前各大公司基本上都靠自已培养,这个现状导致行业内运维人才的流动性非常低,非常多好的技术都局限在各大公司内部,如google 50万台机器科学的管理,或者国内互联公司top 10 的一些运维经验,这些经验是非常有价值的东西并决定了一个公司的核心竞争力;这些问题进而导致业内先进运维技术的流通、贯通、与借签,并最终将限制了运维发展。
5、很多优秀的运维经验都掌握在大公司手中;这不在于公司的技术实力,而在于大公司的技术规模、海量PV、硬件规模足够大,如baidu可怕的流量、51.com海量数据~~~~这些因素决定了他们遇到的问题都是其它中/小公司还没有遇到的,或即将遇到。但大公司可能已有很好的解决方案或系统。
发展前景:
1、从行业角度来看,随着中国互联网的高速发展(目前中国网民已跃升为全球第一)、网站规模越来越来大、架构越来越复杂;对专职网站运维工程师、网站架构师的要求会越来越急迫,特别是对有经验的优秀运维人才需求量大,而且是越老越值钱;目前国内基本上都是选择毕业生培养(限于大公司),培养成本高,而且没有经验人才加入会导致公司技术更新缓慢、影响公司的技术发展;当然,毕业生也有好处:白纸一张,可塑性强,比较认同并容易融入企业文化。
2、从个人角度,运维工程师技术含量及要求会越来越高,同时也是对公司应用、架构最了解最熟悉的人、越来越得到重视。
3、网站运维将成为一个融合多学科(网络、系统、开发、安全、应用架构、存储等)的综合性技术岗位,给大家提供一个很好的个人能力与技术广度的发展空间。
4、运维工作的相关经验将会变得非常重要,而且也将成为个人的核心竞争力,具备很好的各层面问题的解决能力及方案提供、全局思考能力等。
5、特长发控和兴趣的培养;由于运维岗位所接触的知识面非常广阔,更容易培养或发挥出个人某些方面的特长或爱好,如内核、网络、开发、数据库等方面,可以做得非常深入精通、成为这方面的专家。
6、如果真要以后不想做运维了,转到其它岗位也比较容易,不会有太大的局限性。当然了,你得真正用心去做。
7、技术发展方向、网站/系统架构师。

五、运维关键技术点解剖
1、 大规模集群管理问题
首先我们先要明确集群的概念,集群不是泛指各功能服务器的总合,而是指为了达到某一目的或功能的服务器、硬盘资源的整合(机器数大于两台),对于应用来说它就是一个整体,目前常规集群可分为:高可用性集群(HA),负载均衡集群(如lvs),分布式储、计算存储集群(DFS,如google gfs ,yahoo hadoop),特定应用集群(某一特定功能服务器组合、如db、cache层等),目前互联网行业主要基于这四种类型;对于前两种类似,如果业务简单、应用上post操作比较少,可以简单的采用四层交换机解决(如f5),达到服务高可用/负责均衡的作用,对于资源紧张的公司也有一些开源解决办法如lvs+ha,非常灵活;对于后两种,那就考验公司技术实力及应用特点了,第三种DFS主要应用于海量数据应用上,如邮件、搜索等应用,特别是搜索要求就更高了,除了简单海量存储,还包括数据挖掘、用户行为分析;如google、yahoo就能保存分析近一年的用户记录数据,而baidu应该少于30天、soguo就更少了。。。这些对于搜索准备性、及用户体验是至关重要的。
接下来,我们再谈谈如何科学的管理集群,有以下关键几点:
I、监控
主要包括故障监控和性能、流量、负载等状态监控,这些监控关系到集群的健康运行,及潜在问题的及时发现与干预;
a、服务故障、状态监控:主要是对服务器自身、上层应用、关联服务数据交互监控;例如针对前端web server,我们就可以有很多种类型的监控,包括应用端口状态监控,便于及时发现服务器或应用本身是否crash、通过icmp包探测服务器健康状态,更上层可能还包括应用各频道业务的监控,常用方法是采用面业特征码进行判断,或对重点页面进行签名,以网站被黑篡改(报警、并自动恢复被篡改数据)等等,这些只是一部份,还有N多监控方式,依应用特点而定,还有一些问题需解决,如集群过大,如何高性能的进行监控也是一个现实问题。
b、其它就是集群状态类的监控或统计,为我们合理管理调优集群提供数据参考、包括服务瓶颈、性能问题、异常流量、攻击等问题。
II、故障管理
a、硬件故障问题;对于成百上千或上万机器的N多集群,服务器死机、硬件故障概率是非常大的,几乎每时每刻都有服务硬件问题,死机、硬盘损坏、电源、内存、交换机。针对这种情况,我们在设计网站架构时需要充分考虑到这些问题,并将其视为常态;更多的依靠应用的冗余机制来规避这种风险,但给系统工程师足够宽裕的处理时间。(如google不是号称同时死800台机器,服务不会受到任何影响吗);这就是考验运维工程师及网站架构师功能的地方了,好的设计能达到google所描述自恢复能力,如gfs,糟糕的设计那就是一台服务器的死机可能会造成大面积服务的连锁故障反映,直接对用户拒绝响应。
b、应用故障问题;可能是某一bug被触发、或某一性能阀值被超越、攻击等情况不一而定,但重要的一点,是要有对这些问题的预防性措施,不能想当然,它不会出问题,如真出问题了,如何应对? 这需要运维工程师平时做足功夫,包括应急响应速度、故障处理的科学性、备用方案的有效等。

III、自动化
自动化:简而言之,就是将我们日常手动进行的一些工作通过工具,系统自动来完成,解放我们的双手及枯燥的重复性劳动,例如:没有工具前,我们安装系统需要一台一台裸机安装,如2000台,可能需要10人/10天,搞烂N张光盘,人力成本更大。。。而现在通过自动化工具,只需几个简单命令就能搞定、还有如机器人类程序,自动完成以往每天人工干预的工作,使其自动完成、汇报结果,并具备一定的专家系统能力,能做一些简单的是/非判断、优化选择等。。。这些好处非常明显不再多说。。。应该说,自动化运维是运维工程师职业化的一个追求,利已利公,虽然这是一个异常艰巨的任务:不断变更的业务、不规范化的应用设计、开发模式、网络架构变更、IDC变更、规范变动等因素,都可能会对现有自动化系统产生影响,所以需要模块化、接口化、变因参数化等因此,自动化相关工作,是运维工程师的核心重点工作之一,也是价值的体现。
五、运维中关键技术点解剖(比较实际,现实中的案例,今天先想出这几条,如大家有其它感觉兴趣的,可以提出,一起交流~)

1 大量高并发网站的设计方案
2 高可靠、高可伸缩性网络架构设计
3 网站安全问题,如何避免被黑?
4 南北互联问题,动态CDN解决方案
5 海量数据存储架构

转自chinaunix

阅读内文

网站架构收集-2

10月 9th, 2008 | 2 Comments | Posted in 网站架构 < by Johnny Woo >

BLOG程序有点不好,默认修改的文章不会变到最上面.
所以其实以前的文章有很多更新的.但是大家估计都不会看到
那就只能用连载的方式了
网站架构文章的收集.又更新了很多
主要是有个NB的老外.里面的文章又多又好
而且还有的lesson lean的内容
是他自己总结的内容.非常的棒

2008-10-09
Cocolog 从 PostgreSQL 迁移到 MySQL 的经验
http://www.dbanotes.net/arch/cocolog_postgresql_mysql.html

疯狂代码:大型网站架构系列(未完待续)收藏
http://blog.csdn.net/heiyeshuwu/archive/2008/10/01/3006964.aspx

Amazon Architecture
http://highscalability.com/amazon-architecture

Scaling Twitter
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

37signals Architecture
http://highscalability.com/37signals-architecture

Digg Architecture
http://highscalability.com/digg-architecture

Flickr Architecture
http://highscalability.com/flickr-architecture

YouTube Architecture
http://highscalability.com/youtube-architecture

Google Architecture
http://highscalability.com/google-architecture

LiveJournal’s Backend
http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf

LiveJournal Architecture
http://highscalability.com/livejournal-architecture

eBay Architecture
http://highscalability.com/ebay-architecture

LinkedIn Architecture
http://highscalability.com/linkedin-architecture-0

上一期的链接
http://www.hiadmin.com/%E7%BD%91%E7%AB%99%E6%9E%B6%E6%9E%84%E6%94%B6%E9%9B%86/

阅读内文

nginx0.6.31+php(fast-cgi)5.2.5+discuz试运行上线

5月 25th, 2008 | 3 Comments | Posted in Nginx, 网站架构 < by Michael Field >

之前看了网上关于nginx的介绍,倍受鼓舞和感召,决定在公司的论坛进行一下尝试和试运行,以实际结果来验证网上所公布的数据是否真的那么神奇和有效率;

周五用了一天的时间,进行了nginx+php架构的编译和部署工作;(稍后公布编译文档和相关软件包二进制包下载)

实测结果并不像网上描述的那样有效率,不过在高并发的情况下,nginx却是再有一定的优势,但领先的性能优势也只是在10%左右而已;系统资源的占用较apache稍低。(测试数据待公布)

在测试中发现为更好的配合nginx和discuz的工作方式,在fast-cgi开启在24个线程的时候处理的速度是最快的任务是最多的,且占用的系统资源也是最为合理的,并非与内存多少或者是越多越好。但彼此性能的差距并不明显。

实际运行服务器配置:

CPU:Xeon 2.8×2
Mem:4G
Harddisk:73G×2 (Raid1)

使用webbench压力测试工具:
测试服务器二台:分别使用apache和nginx

根据现有运营环境的5台web架构为 1台nginx+4台apache;实际运行结果还需要继续观察;

?

阅读内文

8w同时连接数的DISCUZ论坛结构改进

5月 21st, 2008 | 4 Comments | Posted in 网站架构 < by Johnny Woo >

魔力游的论坛达到8w同时连接数
原有的架构已经无法满足如此巨大的访问请求
原有结构
原有结构
前端使用F5进行负载均衡
将负载分摊至4台WEB SERVER
然后WEB SERVER同时连接后端的MYSQL服务器
瓶颈很明显在于MYSQL服务器

第1次改进
使用LVS和NFS进行MYSQL负载分摊
增加两台WEB SERVER
由于WEB的CPU负载也非常高.所以增加WEBserver的量来分摊CPU LOAD.
在后端使用LVS分发读写请求到后面的两台MYSQL服务器
然后MYSQL的表数据从同一的集中存储中获取
这次改进的问题很明显
锁表
由于MYSQL在执行写操作时会进行锁表
所以运行没多久,MYSQL的库文件就损坏了

第2次改进
改进后的结构
接下来我们考虑过使用NDB作为存储后端代替NFS
但是由于数据库量太大
在进行数据导入时,超出内存
无法将原有的数据库导入到NDB中
所以我们只能使用Mysql proxy + master/slave的方式
进行读写分离
以求分摊负载
由于没有时间进行discuz的程序段的改造
所以只能使用对程序透明的mysql proxy方式进行负载分摊
这次改进的缺点在于对于只读服务器的分摊仍旧是在配置里手工写的
而不能通过程序来进行自动分发.

第3次改进
LVS+PROXY
由于考虑到服务器的自动维护性
以及服务器数量的限制
我们把LVS加在两台read only的mysql服务器上
加上heat beat之后.任何一个只读节点的故障都不会影响
今后如果扩展mysql的IO能力
只要在mysql机群内加入新的mysql slave服务器
加入LVS之后便可以了

阅读内文

网站架构收集

5月 6th, 2008 | No Comments | Posted in 网站架构 < by Johnny Woo >

DBA notes上果然好东西很多
许多大型(只是访问量,而不是公司规模)的web 2.0的网站架构
上面都有
现在收集整理一下有关网站架构的资料,其中许多来自DBA notes
这种资料.向来可遇不可求啊

WikiPedia 技术架构学习分享
http://www.dbanotes.net/opensource/wikipedia_arch.html

YouTube 的架构扩展
http://www.dbanotes.net/opensource/youtube_web_arch.html

Internet Archive 的海量存储浅析
http://www.dbanotes.net/database/internet_archive_storage.html

LinkedIn 架构笔记
http://www.dbanotes.net/arch/linkedin.html

Tailrank 网站架构
http://www.dbanotes.net/review/tailrank_arch.html

Twitter 的架构扩展: 100 倍性能提升
http://www.dbanotes.net/arch/twitter_arch.html

财帮子(caibangzi.com)网站架构
http://www.dbanotes.net/arch/caibangzi_web_arch.html

Yupoo! 的网站技术架构
http://www.dbanotes.net/arch/yupoo_arch.html

37Signals 架构
http://www.dbanotes.net/arch/37signals_arch.html

Flickr 的访问统计实现以及其他
http://www.dbanotes.net/arch/flickr_stats_and_dathan.html

PlentyOfFish 网站架构学习
http://www.dbanotes.net/arch/plentyoffish_arch.html

Yahoo!社区架构
http://www.dbanotes.net/arch/yahoo_arch.html

有关 Alexa 与 AOL 部署集群文件系统
http://www.dbanotes.net/arch/alexa_ibrix_san_file_system.html

eBay 的存储一瞥
http://www.dbanotes.net/arch/ebay_storage.html

eBay 的数据量
http://www.dbanotes.net/database/ebay_storage.html

eBay 的数据库分布扩展架构
http://www.dbanotes.net/database/ebay_database_scale_out.html

eBay 的数据层扩展经验
http://www.dbanotes.net/arch/ebay_db_scale_out.html

eBay 的应用服务器规模
http://www.dbanotes.net/web/ebay_application_server.html

性能扩展问题要趁早
http://www.dbanotes.net/arch/scaling_an_early_stage_startup.html

Scaling an early stage startup
http://www.scribd.com/doc/429986/Scaling-an-early-stage-startup

Facebook 的 PHP 性能与扩展性
http://www.dbanotes.net/arch/facebook_php.html

Skype 用 PostgreSQL 支撑海量用户
http://www.dbanotes.net/arch/skype_postgresql.html

闲谈 Web 图片服务器
http://www.dbanotes.net/web/web_image_server.html

说说北京奥运购票系统瘫痪这事儿
http://www.dbanotes.net/review/beijing_olympic_ticketes_system_crash.html

Architectures You’ve Always Wondered About
http://qcon.infoq.com/london-2008/tracks/show_track.jsp?trackOID=82

eBay’s Architectural Principles
http://www.eos1.dk/qcon-london-2008/slides/RandyShoup_eBaysArchitecturalPrinciples.pdf

Building a large scale SaaS app
http://www.eos1.dk/qcon-london-2008/slides/Dan_Hanley_Building_a_large_scale_SaaS_app.pdf

Scaling an early stage startup
http://www.scribd.com/doc/429986/Scaling-an-early-stage-startup

互联星空播客架构(原文在张宴blog上,但是后来文章撤下,很可惜.此为转载)
http://www.flashmov.com/blog_1632.html

QQ游戏百万人同时在线服务器架构实现
http://www.libing.net.cn/read.php?41

大型Web2.0站点构建技术初探
http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1890793.aspx

Web站点数据库分布存储浅谈
http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1891639.aspx

QQ的架构讨论
http://groups.google.com/group/dev4server/browse_thread/thread/0d72668d11c4886b/a6d202489cabf285#a6d202489cabf285

Notes from Scaling MySQL - Up or Out
http://venublog.com/2008/04/16/notes-from-scaling-mysql-up-or-out/

Yapache-Yahoo! Apache 的秘密
http://www.dbanotes.net/web/yapache_yahoo_apache.html

LinkedIn 架构与开发过程
http://www.dbanotes.net/arch/linkedin_soa.html

Scalability Best Practices: Lessons from eBay
http://www.infoq.com/articles/ebay-scalability-best-practices

看 Twitter 人谈架构扩展问题
http://www.dbanotes.net/arch/twitter_interview.html

Facebook 海量数据处理
http://www.dbanotes.net/arch/facebook_photos_arch.html

web 2.0海量小文件cache集群探讨
http://www.ourlinux.net/operation-tips/web20-small-file-cache-cluster/

2008-10-09
Cocolog 从 PostgreSQL 迁移到 MySQL 的经验
http://www.dbanotes.net/arch/cocolog_postgresql_mysql.html

疯狂代码:大型网站架构系列(未完待续)收藏
http://blog.csdn.net/heiyeshuwu/archive/2008/10/01/3006964.aspx

Amazon Architecture
http://highscalability.com/amazon-architecture

Scaling Twitter
http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

37signals Architecture
http://highscalability.com/37signals-architecture

Digg Architecture
http://highscalability.com/digg-architecture

Flickr Architecture
http://highscalability.com/flickr-architecture

YouTube Architecture
http://highscalability.com/youtube-architecture

Google Architecture
http://highscalability.com/google-architecture

LiveJournal’s Backend
http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf

LiveJournal Architecture
http://highscalability.com/livejournal-architecture

eBay Architecture
http://highscalability.com/ebay-architecture

LinkedIn Architecture
http://highscalability.com/linkedin-architecture-0

阅读内文

同时连接数需求量计算公式

4月 11th, 2008 | No Comments | Posted in 网站架构 < by Johnny Woo >

从张宴兄的一篇文章中获取
但是不知何故.他的blog中把那篇文章删除了.非常可惜
这个公式还是很有用的

每日PV数 / 86400秒 * 10个派生连接数 * 5秒内响应 * 5倍峰值) / Web服务器台数 = 同时连接数

阅读内文

固态存储动向

4月 11th, 2008 | No Comments | Posted in 网站架构 < by Johnny Woo >

一方面是NAND为主的SSD固态硬盘
一个方向是以内存为主的I-RAM系统
两种方向基于不同的应用为主
SSD今后主要目的将是提供现有机械性硬盘的替代.
在速度方面,SSD并不会很大程度的提高,可能早期会用于笔记本硬盘的替换.
而I-RAM系统.则会更多作为服务器的CACHE SYSTEM来应用
作为低端服务器的性能提升手段.简单的扩展内存就能极大的提高数据存取速度
这点的诱惑是非常大的.
使用I-RAM系统加上后台应用程序
我们可以大大提高上传类网站的响应速度
也可以用来对数据库服务器提供cache服务
透过I-RAM系统构建的数据库平台
将会使得数据库的IO瓶颈随之消失
真正发挥CPU的工作效用.

阅读内文

nginx + tmpfs 替代缓冲服务器

4月 11th, 2008 | 8 Comments | Posted in Nginx, 网站架构 < by Johnny Woo >

在nginx服务器上划分一块内存作为tmpfs
然后将网站数据全部复制到tmpfs内
将nginx的document root指向这个分区

varnish或者squid都是利用内存和它的连接数来做到加速服务.
但是如果是squid->nginx->fastcgi->mysql
这样当中很多连接是开销在内部的连接之中
而且如果客户端请求php.squid还需要将请求再转发至nginx,然后nginx再转发至fastcgi
对于动态内容的多加了一个步骤.
考虑到nginx有了不低于squid以及varnish的连接能力
那么可以将网站程序直接放在tmpfs中
这样如果是静态的.就会直接从内存读取后返回给用户(和其他缓冲服务器的效果一样)
如果是PHP就丢给后面的fastcgi处理
这样更快.

至于程序同步的问题.
在程序更新的时候使用svn或者rsync去同步tmpfs里面和文件服务器中的内容就可以了

至于服务器重启tmpfs清空的问题
只需要在服务器重启之前,需要将内存中的程序复制到本地硬盘
然后启动之后,将硬盘数据再复制到tmpfs中然后启动服务即可

至于服务器宕机以后无法事先保存tmpfs内容
既然服务器都挂了.在它启动之后用10分钟20分钟把程序全部重新同步过来也不是什么大的开销.
如果是多节点的负载均衡或者HA,那就更没必要担心tmpfs内容丢失的问题.

至于上传文件
如果你都用这么样的架构来加速了.
你的图片还会直接上传到web服务器么?
肯定是直接传到图片服务器了.

至于内存需求过大
一个网站的实际网页和网站程序量不会超过500MB
而使用varnish或者squid等作为缓冲服务器
也绝对是内存大户
所以这种方式不会比varnish或者squid要求更多的内存.

阅读内文

近期主要研究的问题以及方向

4月 11th, 2008 | No Comments | Posted in 网站架构 < by Johnny Woo >

1.不同网络之间数据同步或者共享数据访问
例如在网通,电信之间不通过专线或者多线机房等物理措施进行数据同步或者共享访问,
主要问题在于数据量大情况下数据传输速度问题.
首先要做到尽量减少需要同步或者共享的数据传输量
其次就是尽量减少突发传送量改为持续传输量

2.用户上传数据的缓冲方法.
反向代理解决了用户下载数据时候的加速.
但是用户上传数据,以及针对数据库的insert以及update操作
暂时无法进行区域性的加速
大致方向可以测试一下memcache对上传文件进行缓冲.
数据库的操作.只能从程序方面进行改进.使用memcache对写进行缓冲.
还有一个可能的方法
用户上传至边缘节点服务器
边缘节点服务器同时将内容加入到缓冲服务器
同时将文件传送至中心服务器.
这样可以加速此用户的访问速度
而跨区用户对其他用户上传数据更新的实时性并不关心

3.游戏服务器分区加速
主要方面是将用户登录数据进行分布处理
加快用户登录体验
由于分区之间用户的速度问题用户能够理解
所以只需要保证同一分区用户之间的游戏流畅性即可

4.动态程序的缓冲
缓冲动态程序的结果.
目前暂时无思路
如果对程序进行分布式分发
瓶颈可能依旧在于数据库的更新上

5.反向代理无法将session传送至应用服务器
如果方向代理缓冲动态程序的结果
则使用到session或者cookie的程序
由于应用程序只能够接收到缓冲服务器转发的请求
导致无法保存实际用户发起的session
可以参考NAT方式
让缓冲服务器对session或者ip等进行重新打包转换
以此解决session粘连问题.

阅读内文

对于PHP动态网站负载均衡思路

4月 11th, 2008 | No Comments | Posted in 网站架构 < by Johnny Woo >

前端使用Nginx作为web服务程序
后台将PHP服务调用通过LVS分发到各台FastCGI服务器上
这样具体程序的执行将和web服务器分离
web服务器的资源和负载统统用于对http请求的处理和响应上
一旦程序处理速度降低,可以通过增加FastCGI集群节点的方式扩容.
优势在于这样就不用处理不同web服务器之间的程序同步问题

阅读内文

一个分布式视频存储系统的结构

4月 11th, 2008 | 2 Comments | Posted in 网站架构 < by Johnny Woo >

基本构架与GFS相同
采用master主表进行文件登记
实现也非常简单
两个mysql表加上一句php的header就完成了
基于大文件的实际服务时间要大大超过前端分发服务器的点击量
实际计算下来1G带宽的用户量,只需要一台分发服务器即可
详细PPT下载
Dynamic File System

阅读内文