火龙果-大型网站架构设计与分析的经验总结

•平台：NET,+NHibernate+SQLSERVER2008•开发模式：MVC模式三层都右A方开发，A方的査询业务呆本上依赖于SP,SP由B方方而开发。・农现：-B方对需求的理解不完善，导致SP经常改动。但是SP的每次改动了之后，A方开发应用程序的程序人员却不知道，除1FA方程序员去调试以前己经开发好的程序，不然很难发现B方修改了存储过程。-存储过程的修改，带來的不仅是页面表现层的数据绑定的问题，在模型层的domain和dto很有可能都要随Z改动<>即使B方修改ZSP第一时间通知A方，A方修改相应的模型层对彖，重新构造层与层之间的访问参数以及返回类型也足相X费时的事情。•问题：-该项HH前的开发方式和现状，效率相当低数据库与SP是星础，SP的修改血接影响上层建筑。而SP的控制权在B方,II1B方完全控制业务。A方需要做领域业务，但只能按照B方的文档來开发，其至都不用知道业务。1分析、建议•分析：-主要是项目管理组织的问题。两个团队无法协调。B方变更带來A方的变更是必然，问题在于A根木不知道B方的变更。加之双方没有持续集成,很可能变更了很久才知道,修改的时候B対A也无法给支持.时间长了对能Bfl己也忘了。-技术上，业务的变动必然带來领域模型的变动。A方其实只是充当一系列存储过程的外观。这个系统的领域模型其实是用数据咋农和存储过程衣示的。实际上，谁控制了业务谁就控制了领域模型。・建议：-两个团队组合成一个团队（熄拟的，相当于远程协同开发）.要共7需求任务列农。每次变更需要双方在匚作前进行协调,确认各fI需要调整的地方和需要消耗的时间O•背尿：在ATM和银行主机之间，通常冇个前置机器.主耍用來做•些预处理工作，传统的金融半台人多采用C來处理•现在想接入网银，想改用j2ee來架构，也为以后的sop（标准操作程序）做准备。・问题：在这种实时交易系统里丿M该用什么的架构。ATM®便用TCP/IP协议的，而网银是http协议的。如呆web方面采用jsp+struts做页|何层.Spring+hibenate做业务层.ifijATM的接入采用application同样接入到到Spring的业务层。由于交易量较人，必须1分钟处理1000笔交易（单ATM）•这样的架构是否合适？2分析•卷芻薔養繁靈漩席帶無噺些'作'足否有复朵的业务逻辑•对于这样实时性•Sprina+hibernate傲实时件祁较刀.Spring会产生人吊"圾.频歆门动垃圾1审收机制.系统的响应就衍种停.Spring的鬲态代理Proxy对猱足得个洁求伫兮郁公产牛的•1分钟处理1000生交易.那么•分钟内至少1000个Proxy对象.还仃其他附带对彖.内存可能不展支持.•比较好的笫略：分析系统在应付如此人访问虽F的瓶颈所在。•如果确咲需耍业务绍件.《台机器组成的分布式EJB系统可能更适合这样的系统：ATM机需尖很K的Session存活期.Spring对Session的行理圮默认・次调用会开启一个session,调用结束时关闭.血果保扌『一个Session-H：不断Open.乂占用内存.-分钟内如果II常多的ATM*八端接过來.对内存消耗太夭•EJB的Stateful对Session町以在现定内祚丙逸行替理.・劭吊褰锣有数据库,只是-个broker,转接者，使用JMS比多线程强,不MySpace・第•代架构：添:E史多的Web服务器•MySpaceAi初的系统很小，只仃两台Web服务器（分担处理用八请求的匸作战）利一个数据库服务器（所冇数据都存储在这一个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace呈木是通过添遥更多Web服务器來対付用户拡增问题的。但到在2004年早期,在MySpace用户数增长到五十刀•后,苴数据咋服务器（2经开始疲「•奔命了。MySpace•第••代架构：増加数据库服务器与增加Web服务器不同，增加数据库并没那么简单。如果•个站点由多个数据库支持，役订者必须考虑的足,如何在保证数执:•致性的询提卜比多个数据库分押加力。MySpace•MySpace运行•在三个SQLServer数据库服务器上：一个为主，所有的新数据都向它提交,然后由它复制到其它两个;另两个数据炸服务器全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好——只要增加数据库服务器，加人破盘，就可以应对用户数和访问量的増加。这一次的数据库架构按照垂何分割模式设计.不同的数据库服务丁•站点的不同功能.如直录、用户资料和博客。垂11分割策略利J：多个数据库分担访问压力，当用八耍求增加新功能时，MySpace只需要投入新的数据咋加以支持。在账八到达力后，MySpace还从行储设备与数据咋服务器立接交斤的方式切换到SAN（存储区域网络）—用高带宽、专门设计的网络将大虽磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极人提升了系统件能、正常运行时间和可靠性。然而，当用户继续增加到三白力后，垂曲分割策略也变得难以维持卜去。MySpace•第三代架构：转到分布式计算架构・儿经折腾，瑕终，MySpace将口光移到分布式计伴架构——它在物理I:分布的众多服务器.幣体必须逻辑上等同于单台机器。拿数据序來说，就不能再像过去那样将应用拆分,再以不同数据库分别支持,而必须将整个站点看作个丿卫用。现在.数据库模型里只冇个用八衣.支持博客、个人资料和貝他核心功能的数据都存储在相同数据弄。•既然所仃的核心数据逻辑上都组织到一个数据库•那么MySpace必须找到新的办■分担负荷—显然,运行在普通破件上的单个数据库服务器是无能为力的。这次.不再按站点功能和应用分割数据库，MySpace幵始将它的用户按每白力一组分割.然后将各组的全部数拥分别存入独立的SQLServer实例。结果屆MySpace的每台数据序服务器实际运行两个SQLServer实例，也就是说每台服务閹服务人约二订万用广。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从『U优化负荷分扣。MySpace•第四代架构：求助丁•微软方案2005年早期，账户达到九AJj,MySpace廿始用微软的C#编吗ASP.NET程序。在收到•定成效后，MySpaceJF始大规模迁移到ASP.NETo•账八达到一「力时，MySpace再次逍遇存储瓶颈问题。SAN的引入解决了早期一止《性能问题，但站点訂前的耍求U经开始周期性超越SAN的I/O容灵一一即它从磁盘心储系统读写数据的极限速度。MySpace•第五代架构:増加数据缓存层并转到支持64位处理器的SQLServer2005・2005年春天，MySpace账八达至ij*T*七FT万，MySpace又丿訂川了新的策略以减轻存储系统压力，即增加数据缓存层——位于Web服务器和数据库服务器2间，其唯•职能足在内〃屮建立被频緊请求数据对彖的副木，如此一来，不访问数据库也町以向Web应用供给数据。・2005年中期，服务账户数达到两「六百万时，MySpace因为我们对内心的渴求向切换到了述处于beta测试的支持64位处理器的SQLServer2005-升级到SQLServer2005和64位WindowsServer2003后，MySpace每台服务器配条了32G内存，后丁2006年再次将配置标准提升到64GoMySpace・事实上，MySpace的Web服务器和数据府仍然经常发丫超负荷,其用户频繁遭遇“意外错谋”和“站点离线维护”等告示，他们不得不在论坛抱怨…・MySpace1E是在这样不断眞构站点软件、数据库和冇•储系统中,才一步步走到今天。・事实上，MySpace己经成功解决了很多系统扩展性问题，其中仃在相円的经验值須我们借鉴。MySpace系统架构到R询为ik保持了相对稳定，但其技术人员仍然在为SQLServer支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。Amazon•亚马逊IM；无疑足电了商务发展的世程碑。2000年到现在，ttt界网络业腥风血雨。・Amazon曾经成为网络泡沐的头号代农。如今，当这个“故人的泡沫"用儿经易改的数字把白己变成了坚咲的IT巨人。・丿力览Amazon发展过程，其成功经验在于，它创造杵地进行了电/商务中每环节的探索，包扌忑系统、卜台的建设，程序编写.网站设立、配送系统等等方面。用Amazon为家人贝索斯的话说就思“在现实壯界的商丿占垠有力的武器就是地段，地段，地段，而对于我们來说最亟要的三件牛就是技术，技术.技术。”大型网站开发时的儿点建议•搭建科学的系统架构・构建大型的商业网站不町能像构建泮通的小型网站一样一蹴而就，需耍从严格的软件工程管理的角度进行认宾观划，仃步骤竹逻辑地进行开发。对于大型网站來说.所采用的技术涉及面极其广泛.从硕件到软件.编程语言.数据库、Web服务器.防火墙等各个领域都仃了很髙的要求，C经不是原來简单的html静态网站所能比拟的。以著名的Yahoo!为例.他们的毎・个大世网站I刑部需要大試相应专•业人员的参与。大型网站开发时的儿点建议大型网站开发时的儿点建议•页而静态化・不要小看纯舲态化的HTML页面！其实在很多情况2HTMLft往意味着“效率最高-消耗最小”,所以我们尽町能使我们的网站上的页而采用欝态页而來实现。们足.对于大昂:内容并」1频繁更新的网站,我们无法全部手动实现，因此可以开发相应的口动化更新工貝，例如我们常见的信息发布系统CMSo像我们经常访问的各个门八站点的新闻频道，其至他们的其他频道,都是通过信息发布系统來符理和实现的。信息发布系统可以实现最简单的信息录入口动生成静态页而，还能具备频道菅理、权限管理、门动抓取等功能，对于…个大空网站來说，拥冇-套高效.町管理的CMS是必不町少的。大型网站开发时的儿点建议•存储问题・存储也是一个大问题.一种是小文件的存储.比如图片这类：另一种是人文件的存储，比如捜索引擎的索引。人家知道，対于Web®务器來说，不管是Apache.IIS还是具他容器，图片是最消耗资源的.J：足我们伺必要将图片与页面进行分离，这是基木上大世网站都会采用的策略，他们都仃独立的图片服务器,甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统丿衣力，并IL町以保证系统不会肉为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证史高的系统消耗和执行效率。大型网站开发时的儿点建议大型网站开发时的儿点建议•数据库技术一集群和库衣散列对于人型网站|伯言，使用人型的数据库服务器是必须的爭情。但足，在而对大量访问的时候，数据咋的瓶颈仍然会显现出來,这时•台数据咋将很快无法满足应川.于是我们需耍借助于数据库集群或者库衣散列技术。在数据库集群方面，很多数据库厂商都有自己的解决方案，Orac1°.Sybase^SQLServer智都冇很好的方案，（MvSQL提供了类似的Master/Slave）。因此，使用了什么样的数据库，就参考相应的解决方案來实施即叮。大型网站开发时的儿点建议•上而捉到的数据库集群由于在架构.成木、扩张性方而都会受到所采用数据用类型的限制,J•是我们需要从应用程序的角度來考虑改善系统架构，其中，库农散列足常丿TJ并11圾冇效的解决方案。我们在应用程序中安装业务和应用或吿功能模块将数据库进行分离，不同的模块对应不同的数据库或咅衣，再按照一定的策略对某个页1何或者功能进行更小的数据咋散列.比如川八农，按照用户ID进行表散列•这样就能够低成木的捉JI系统的性能并且有很好的扩展性。・一个现成的例子足sohou。它的论坛采川了类似的架构，将论坛的用户、设宜、帖子等信息进行数抑:库分离，然后对帖子、用八按照板块和ID进行散列数据库和表,最终可以在配置文件中进行简中的配置便能止系统随时增加•台低成木的数据序进來补充系统性能。大型网站开发时的儿点建议大型网站开发时的儿点建议•缓存策略不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服务器、数据库服务器的各层级的缓冲策略,故肩才足低级的缓冲技术的编程。不同的服务器.数据咋服务益及Web编程语苕都仃门C不同的缓冲策略。例如数执;库存储方面・SQLServe20()6中的主动式缓心机制.Oracle数据的cachegroup技术•Hibernate的缓存包括Session的缓存和SessionFactorv的缓V/；Web服务器方而,Apache捉供\口(2的缓存模块，也町以便用外加的Squid模块进行缓存，这两种方式均叮以冇效的捉AApache的访问响应能力，IIS缓冲器技术：至Fweb开发语言，所用缓存技术更存在很大不同,例如ASP.NET2.o中捉出r两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pea工的Cache模块，等等。大型网站开发时的几点建议・镜像镜像是人型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带來的用户访问速度差异。大型网站开发时的儿点建议大型网站开发时的儿点建议大型网站开发时的儿点建议大型网站开发时的儿点建议•负载均衡•M他UU4心撤•・如萨纠衡将足人型网站解决高负荷访问和人呈并发请求采用的终极餉•M他UU4心撤•协议寒种多样•有HTTP.FTP.NFS、Telnet或其他协议。这些业务在物理服务器基础上.需要复杂的载量平衡算法•在IP世界,业务奚盘山终端TCP或UDP瑞II地址*决处，在第四层交换中的应用区间则山源端和终端IP地址.TCP和UDP端口人同决止。•在蚁件四用交换产品领域.克_些知名的产品可幼加理'比如Alteon.F5象这此产鳥很昂贵,但是物有所尿.能够捉供邹帝优莠的性能和很乂活的管理能力。Yahoo中国当初接近2000台服务猛使用\三四台Alteon就搞怎To网站问题•半投资和流战都不足问题的时候，技术上需耍关注什么。・例如：SNS网站，半一笔笔投淡砸进去的时候，为流挝上去的时候,困惑在什么地方?除了页血挣态化，缓存和代码女全等问题，讨论一下发展Z后的问题。A公司•A公祠做的是SNS网站.程序是两个毛头小伙了做的，II标代指5仁程序幵发是•帆风顺.功能也比51牛多了，推广也是•帆风顺（A公司有自己独到的推广方式。但是卅ALEXA到2W的时候问题出来了•每天卜午4点左右，网站速度慢的惊人,基本上打不开,公司三台服务器CPU100%.讣人郁泅的是公司的网绍配罟方式•屈然址双WEB的集拼•而单独一台DB数据库。整个瓶颈在数拯库，于足咨询公司建议做DB的集粘分析了卜数抑;结构：是典型的WEB程庁员的作品.没有点数据库设计规范,功能实现是可以,如果要扩展,不可能.巢群基本匕是不可能的，怎么办?•解决方案：个丿J的时间修改私序，数据结构基木上换了•遍前期砸进去的儿十万打了水飘，用户走光了。・结论：WEB2.0询期设计的时候不应该只考虑功能，应该认真考虑一下底y和数据结构。•B公司也是做的SNS网站.稈序是3•B公司也是做的SNS网站.稈序是3个人开发的.CEO是某名牌人学側蹲警崩遗，据丢失，件系统的"晰百I褊廉in、错，Feo獗融爆能虢感吐血編,絮统架构还行.但是…但是系统崩溃了.为什么?系统没有考虑到用户有个海量的说法,文件收奇个海量的说法,用八的相册」片伞妙存贮在WEB服务器的怀分KL,每木用八个n录,而打廿桂能益视器，磁盘的IO高的惊人，基木上无暇响应。众所周知，文件系统也是•个数抓库，单独人文件无所谓.側蹲警崩遗，据丢失，件系统的"晰百I「厂这址•个卄•常沉重的山血嚟^18?-?

电独文件很榨易•们是海吊龙件I丨前还没仃一个软•澀翳滤鍍融鬻翠探歆件鸚綽離勰!咲・黠曲羅•测粘履藤翩鶴炉蒙’林涉及了

C公司SqIServer,而微•C公4是•个值得尊敬的公4,CEO技术出身.和比尔盖茨样.k学木乍业出來做网络.01到03年做短信狠賺了•笔.后來做的小项I也小右所成'公司做的是校友方Ifibfn是也偏車myspace风格，汴豆个A>jr貳广方而也卜了大于笃，系緞1、徹的页因共实很简也F1F•菜用陥是薇软俯SqIServer,SqIServer,而微畀呀罩F辻只匸孟盘I紬捕盘留）床hit徧a孩cplt系笛，但是系统还足朋溃r…畀呀罩F辻只匸孟盘I紬捕盘留）床hit徧a孩cplt系笛，但是系统还足朋溃r…高直动注定门苗负妙。•解决方案：现从基木入手.解决抻儿个程序样能人户.对数坷库采用横向切割，将用八每10力进行分仏同时对数扌居咋系统进行腋列，将罢个衣乖is分「同吋进行文件分绅'解决冋题.i人i为修改rsffiis构.耙户也比木I:人动了Ko好汪系统没右岀人错，损失不m艮人,不过对用广休验追成J'很坏的话响。•繇黑鄴關翻翅良好蹄列考虑’程序应该能有配仟D公司•D公司足•个各个方而做的比较好的公司.做了CDN加速；图片也独立分出了N个服务器：数据库不错（CTO是数据库&家），系统崩溃的原因在于WEB,按道理说WEB很容易做集群的，但是发现集群并解决不掉问题，他们的集群只允许做4台的WEB集群,但是4台都当掉了。仔细分析，原因估计也是大部分CTO容易犯的个错谋，或者说他们没右想到的问题，就是WEB上传的问题■上传的时候由于时间的原因,线程是保持链接的，300个线程就町以把一个WEBServer当掉了。・解决方案：这个最简单，把上传和其他耗能人八分离出独立山來。程序改动不是很大，但是之前丫•个月速度满对用户体验的损失也不町小视。（育海量访问经验的CTO不多）。网站问题•总结：・模仿是容易的，随便找儿个WEB程序员就能做到，并丨1•很简单,速度可能还很启效，因为WEB2.0无非就足跟数据炸打交道.会操作数据库就会做。但是真正做大并不容易，I人1为能应付海呆访问的程序并不简单。儿个建议・一.找DBMS的专家设计好数据库，很多程序员只知道Sql,不知道分区视图，数据散列的概念。•二设计好程序架构,找个高人指导•下，保持良好的扩展性,考虑节约成木的话可以找兼职的系统架构设计师做好系统架构,确定将來的发展瓶颈。・三.考虑好文件存贮的问题。文件存贮的技术含駅看起來很低，其实是很高的，可以考虑反向代理的方案。文件存贮出问题了,站点族本上就垮了，RAID的问题和存贮服务器的问题。儿个建议•四冲国国情考虑,这个最致命,需要考虑电信和网通的问题,CDN并不能解决所有问题。互动性的东西CDN并不是很仃效。最关键的是，现自的双线机房遇到DDOS攻由基本I:都会当掉.原因很简单，双线机房都是私人机房.本少就不会仃太高的带宽，随便攻击•下就可以D掉。•仏网络延迟的问题，分布式系统必须要考虑网络延迟问题，程序茨能容忍0到100秒的数据延迟的功能，也就是同步的问题。不耍小看这几十秒，问题很人的，如果站点右•交4式功能，比如IM,可以想彖一下是个什么结果。此外,如果系统为了健壮做了缓存和筋态化的时候，网络延迟是灾难件危害。对TIM,可以用反向代理来解决（成本较高）o对于留言和评论,延迟的问题影响不大。儿个建议•递總魁気喘褊釦澈麵构繆嘟赠务器’建•七•看好你的程序员,如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码,而这个四•能就站将來的人孙程序架构定下来后要修改町能就雯费牛劲r。威好feincTo能对你ioo%的忠心.ioo%的负责。•八•文件冋步的问题，这个问遷可備党得没有必咯但行一下网通和电值的TTL＜明白了,同步要绎纟強恂不能是持续Mb否则成本会高出N倍.不要期叫能通过你的软件实现.仝给你的程序员吧.把上面的话告诉他他就知道怎么做了。・九•吃〒赧人的问题，不管您跟网警的关系多好,看好你的用户,审核好你的东西.一被停机可能就致命。绿坝•在Vista 常被用户账户挖制杀掉。•网站过滤功能，只能在IE下生效，同属IE内核的邀游等不起作用。火狐，谷歌这类非IE内核浏览器不起作用。•四个进程除了以两个为•组.冇交圧保护（为其中个被结束，另・个将会垂新运行它）Z外，其他无任何防护。•管理密码，通过类似于MD5的加密之启.储存在WINDOWSsystem32kwpwf.dll文件中•该文件并没仃受到任何程序的保护,可用记事本就改其中内容。例如•把知道密码的绿坝的WINDOWSsystem32kwpwf.dll文件中的内容殳制到不知道密码的那个绿坝的WINDOWSsystem32kwpwf.dll卜••就和为于改变見幣码\.可把WINDOWSsystem32kwpwf.dll的内容改为“D0970714757783E6CF17B26FB8E2298FS则绿坝的俗理密码就变回了默认的112233-•成本高。电影资讯/社区网站•X网站足大利的电影资讯，电影社区，向外提供电影相关信息服务,以及用户社|心其中信息服务部分,其中大部分页面属于信息呈现页,读取虽比较大币力级别pv備息上耍山编辑在后台发布，更新较少，但其页面上有大呈的交互性的内容，比如评论，收藏列农,同时许多内容允许用户创造，比如上传图片，添加注秤•交互内容的数杲和交互的频繁程度•都超过了普通的咨询页面，这次调整,准备将其中访问量最大的几块:电影资料页膨人资料页勉行弊态化，如果成功，还将运川到更多的频道，呈木实现个站静态化。优化调整时的问题页面生成的触发条件复杂-般论坛中的帖了或者blog,更新方式比较单•：匸更足「1］冋复进彳亍他发还有少数的修改动作淀而及网站•个页血上盂要根抑;不M触发条件就仃20务个，比如光一级菜小:川户发仿紺;，删除图儿发仿或者删除彩片信息，发布或者修改视频,后台修改电彩伫息,都右对能触发-一个动作触发生成的页|何町能很多而H+II1L交為-何个动作都会触发系列的生成，并11不同动作町能都会涉及同一个页面或者区域侖生成.-比如:用户给一步电影评分，需要生成评分更多页，评分统计更多几首页右侧谁还关注竝片小区域，等等•用户收藏一个影片,乜需耍史新首页右侧谁还关注此影片小区域触发频紧：-虽然不及杲些夏大规模的网站丄但是由于涉及众多用户参与的内容,评论■收藏等等，触发点钦发牛•颇度相T频聯优化调整时的问题页Ift1多,结构K杂,空间人用人：-通常，需要牛•成的页而规模是这样粗略估舁的,Rn*P,Rn为资源数尸

为何个资源的页面数，所谓资源,对以石做•个卞成屮•位，其页血畅

町以简車看做发布个资源，就需要生成其所冇相关页面数员,比如:

发布•个blog,就石要T| •个Blog几同时述蛊蜜1或者更新个人】：页的blog列艮算I:个人1顶侧的分类文“数的小块,也祖足垠釦0來个员面或者区域，但是发布•个电敗真相关的页山I至少白50个以匚而且看耐页面还带有分页■一个為息比较卡高的电影，其页而竞町以达到T个以匕空间10〜20MMHL资源总数也不少，电影80000圧仏电彤人虽然P血校少，但足总吊:确冇儿I•万之"佔计挣态页而磁盘占用屋几冇个G向下兼容计。优化调整时的问题・多台前端Web-这种结构要求牛成的文件町能需要分布到多个服务器（另一个方案是放在几台专用的机器上，等前端*取）・任务紧迫-架构讨论结束肩，所冇底层框架实现，页而模板幵发，凋试测试,动作的整理，必须接看完成。架构必须耍右的特点・综介考虑上述因素,架构必须要冇以下儿个方面的特点-动作可以灵活扩展配胃，某个动作对应哪些牛成，应该可以配置，并IL可以分组-文件必须有分发机制-分发和生成必须独立出來，并且支持分布式-各种的动作，必须转化为消息，发送到