• Feeds

  • Archive for the ‘架构’ Category


    构建可扩展的微博架构(qcon beijing 2010演讲)

    在使用Twitter几年的时间里面,经常思考微博如何更好的实现,恰好最近几个月也参与了相关工作,大部分都是工程实践,总结实践会促生更具实际价值的理论。因此在QCon Beijing 2010这次演讲参考了不少网友的意见后选择了《构建可扩展微博架构》的题目。
    由于在决定选题时知道来自Twitter总部有30万followers的@nk也会讲一个类似的题目,心中当时有点忐忑,最大的顾虑就是要讲的领域更他重叠,如果他讲得更深入,我就没必要班门弄斧了。后来考虑到以下几个原因还是决定继续

    • Twitter架构是单IDC设计,从它递增的tweet id就可以看出,后来当面向@nk提问也得到了证实。
    • 中美网络环境差异,单IDC和多IDC有很多设计上的不同
    • 大部分参会人员未必能对英文演讲有深入理解及感悟,中文的演讲可以讲一些细节解释更透彻。
    • Twitter对故障的容忍度大,国内公司对服务故障通常更敏感。因此国内架构师会考虑设计方案尽量简单可靠,服务需要更稳定。国外开发团队更倾向追求在工作中应用技术创新,因此会导致架构设计理念的不少差异。

    演讲的slide如下,登录slideshare之后可以下载。

    这里再补充在qcon演讲未来得及考虑成熟的一个方面,用户规模影响设计,具体是指用户数每上一个数量级,许多设计需要重新考虑。

    10万用户级别

    • 单服务器,前端、后端、cache、db在一起。

    百万级

    • db和cache单独部署服务器,db或按业务进行拆分(sharding)
    • cache或使用一致性hash扩展。
    • 前端后端还是在一起,但是根据业务拆分,每个业务可分配不同数量的服务器

    千万级

    • 开始重视架构设计,有专门技术架构师
    • 需跨机房部署,前端在远程增加反向代理加速,数据库在异地机房使用slave数据库副本
    • 后端拆分出来,系统内部需要远程调用,内部需远程调用协议。

    亿级

    • 架构更细分,或增加数据架构师,cache架构师,分布式架构师
    • 数据库sharding碰到烦恼,开始考虑分布式数据服务
    • 数据访问需要根据业务特点细分。
    • 开发、运维、测量、调优具备有自己的专有工具。
    • 所有服务需要地理多机房分布,具备IDC容灾设计。
    • 服务可降级

    上面的数字仅供理解“用户规模影响设计”,数字本身并无具体指导价值。

    另外在slide中也提到了,目前新浪微博团队急需人才,对上面相关技术领域感兴趣的架构师及各层次开发人员(熟悉PHP,Java, C或数据架构任意一种)可随时跟我联系,工作地点为北京,联系方式见博客首页。

    FarmVille(美版开心农场)谈架构:所有模块都是一个可降级的服务


    在2009年Facebook Developer Garage Shanghai活动上,Five Minutes程延辉 介绍开心农场架构,让大家了解了SNS game的一些挑战和设计模式。

    由于农场游戏风靡全球,最近highscalability.com网站采访了美版开心农场FarmVille的Luke Rajlich,他介绍了FarmVille的部分架构资料(1)。

    所有模块都是一个可降级的服务

    For any web application, high latency kills your app and highly variable latency eventually kills your app.

    由于大型的网络应用需要依赖各种底层及内部服务,但是服务调用的高延迟是各种应用的最大问题,在竞争激烈的SNS app领域更是如此。解决此问题的方法是将所有的模块设计成一种可降级的服务,包括Memcache, Database, REST API等。将所有可能会发生大延迟的服务进行隔离。这可以通过控制调用超时时间来控制,另外还可以通过应用中的一些开关来关闭某些某些功能避免服务降级造成的影响。

    上面这点我也有一些教训,曾碰到过由于依赖的一些模块阻塞造成服务不稳定的现象。

    1. 某Socket Server使用了ThreadPool来处理所有核心业务。
    2. 不少业务需要访问内网的一个远程的User Service(RPC)来获取用户信息。
    3. User Service需要访问数据库。
    4. 数据库有时候会变慢,一些大查询需要10秒以上才能完成。

    结果4造成3很多调用很久才能执行完,3造成2的RPC调用阻塞,2造成1的ThreadPool堵塞,ThreadPool不断有新任务加入,但是老的任务迟迟不能完成。因此对于最终用户的表现是很多请求没有响应。部分用户认为是网络原因会手工重复提交请求,这样会造成状况并进一步恶化。上面的问题根本是没有意识到远程服务可能会超时或失败,把远程服务RPC调用当成一个本地调用来执行。

    解决思路一:RPC增加Timeout
    解决思路二:将RPC改成异步调用。

    另一分布式大牛James Hamilton谈到(2)上面这种做法就是他论文Designing and Deploying Internet-Scale Services中的graceful degradation mode(优雅降级)。

    FarmVille其他数据

    • FarmVille基于LAMP架构,运行在EC2上。
    • 读写比例是3:1。
    • 使用开源工具来做运维监控,如nagios报警,munin监控,puppet配置。另外还开发了很多内部的程序来监控Facebook DB, Memcache等。
    • 到Facebook接口的流量峰值达到3Gb/s,同时内部的cache还承担了1.5Gb/s。
    • 另外可动态调整到Facebook与Cache之间的流量,Facebook接口变慢时,可以利用cache数据直接返回,终极目的是不管发生了那个环节的故障,能够让用户继续游戏。

    小结

    尽管FarmVille公布了上面一些技术资料,凭借上面这些资料无法全部了解FarmVille的架构。但是所有模块都是一个可降级服务的概念值得设计大规模应用的同行参考。

    Resource

    1. How FarmVille Scales to Harvest 75 Million Players a Month
    2. Scaling FarmVille

    2010年的技术架构建议

    在 2009年最后一天,根据自己小小的视角提出一些技术建议,供同行参考。

    编程语言

    首先要能跳出语言之争及语言偏见,架构师需要在中立的角度选择最合适团队的语言,避免在技术决策中加入过多个人喜好。在系统语言层面,主要可关注以下几种
    Erlang, 会继续在小圈子内流行,业界应用Erlang技术最大的障碍不是Erlang技术本身,而在于缺乏这方面专业人才。
    Scala, 和Erlang不同,Scala有成熟JVM及丰富的周边library,在异构系统中集成也很容易,新项目使用Scala风险很小,所以Scala在新语言中应该有较大的提升优势。
    Go, 由于刚开始推出,不适合正式项目使用,2010年会稳步上升,可适当关注。
    其他语言基本保持现状。

    架构

    LAMP中的Linux, Apache, MySQL会受到云计算中的App Engine模式的冲击,因为App Engine在分布式处理,可扩展性,稳定性方面都有很大的优势。 在App Engine模式中,MySQL作用会降低,退化成一种存储服务。而且App Engine的存储服务含义会更广泛,传统架构中的MySQL, Memcached, 及key value store在App Engine框架下都会以底层的服务方式提供。存储不再是软件,而是一种可靠服务,因此也会带来分布式存储相关技术的繁荣。

    Web 2.0的设计中,Cache会成为一个中心元素。传统的web应用cache只是一个可选的锦上添花层,即使去掉,PHP + MySQL这种模式也可正常运行。但随着未来应用social化及realtime的趋势,从facebook及twitter的设计来看,cache已经从可选层成为核心层。cache设计的好坏直接决定架构的成败。

    由于web发展的趋势会使应用更realtime化,体现到技术层面是HTML5(websockets)及类似技术具有更高的价值。但由于阻碍生产力的IE存在,HTML5无法一步到位。建议关注能解决HTML5及旧ajax自适应的框架。

    网络模型方面,由于多核的硬件环境,轻量级的进程模型值得采用。如传统的C++ boost的asio, 各公司自己实现的coroutine, Erlang的process, go的goroutines, Java/Scala的Netty/Mina框架等。但C++框架的代码优雅性可维护性欠佳,性能也没有突出的优势,可关注后面几种方案。

    分布式方面,Dynamo及Chubby的思想会逐渐在国内的项目等到更广泛的应用,架构师会逐步丢弃双写,双机心跳等山寨式的容错设计思想,可靠的分布式设计思想会更普及。

    存储

    2009是key value/nosql产品百花齐放的年代。到2010年,它们之中优秀的会脱颖而出逐步主流化,主流化的产品周边的工具会更丰富,运维相关经验也会更成熟。目前阻碍很多key value产品推广很大一个障碍是运维的顾虑,而不是它们本身的性能。究竟会是Memcachedb/Tokyo Cabinet/Redis这样的小巧软件走向主流,还是Cassandra这样的巨无霸更受欢迎,我们拭目以待。