• Feeds

  • 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这样的巨无霸更受欢迎,我们拭目以待。

    如想及时阅读Tim Yang的文章,可通过页面右上方扫码订阅最新更新。

    « | »

    25 Comments  »

    1. 作为第一个留言支持你的人,我看好 Python,如果 Google 真的能够把 Python 的解析效率提高10倍的话,它的简洁和优雅会吸引不少人,至少 ROR 已经让 Ruby 有了飞跃 …

    2. Tim

      如果这篇有关Google Python的流言( http://groups.google.com/group/unladen-swallow/browse_thread/thread/4edbc406f544643e) 是真的话,python在Google内部应该部分会被go取代。10x python在2010未必乐观。

    3. 开源项目魅力无限啊

      数据库的作用在web2.0里面的作用的确是有减少的迹象了

    4. Good~

      我在期待 Scala 2.8 的 continuation, 它为真正脱离 JVM 的限制, 实现高并发, 易编程 (而不是使用半吊子 react 方案) 的关键, 再加上丰富的 Java 库, 口水中… 另一方面作为一个 scheme fans, continuation 对我来说有太多可玩的东西了 :-)

      Key-Value 方面, 我的想法是可以分开两方面讨论.
      一是本机存储的功能, 性能, 并发, 事务支持等方面. 我认为要超越 BerkeleyDB 已经很难很难 (单项超越还是容易的). 没什么特别 BT 的需求, 直接用就是. 如果我没记错, Dynamo 的本地存储就是 BerkeleyDB

      二是分布式设计, 这跟本机存储是另一个问题, 这个还是要根据需求选择. 我觉得在机器少于 30 台的情况下, 简单解决就好, 用不着 dynamo 这样的做法. 我只有 4 台机, 就算每次扩容要翻倍其实也能再扩个一两次再说. 类似 Dynamo 的模式在实际运维上也有问题, 如果没有很强很细致的自动化运维, 结果可能会很惨, 例如我可能要对数据做冷备, 在某个柜停电挂掉 N 台机的盘, 某些数据永久丢失的灾难下, dynamo 的模式如果没做细致, 会很难指出我现在具体丢了哪些数据, 要用哪些冷备盘恢复. 这会很惨的.

      两方面综合, 就是: 本地存储用成熟的开源项目很靠谱. (Dynamo 用 berkeleydb, PNUTS 用 MySQL Inoodb). 分布式方案需要根据需求选择, 量体裁衣, 保持简单.

    5. 个人比较喜欢LAMP。

      虽然PHP的运行效率大家也都知道,不是很高,但是对于一些非巨型应用来说,一秒内的延迟还是可以接受的。
      MySql这东西以后的发展趋势不好说,不知道Sun和甲骨文到底会怎么样,如果到时候没了,还真不知道该怎么办……

    6. Leechael

      2009我觉得 NoSQL 很火热。个人认为这火热会持续,但对于 NoSQL 和传统 DBM 之间的选择,在2010年会趋向于更为理智。我猜想这一年会有更多关于两者间做抉择、比较、甚至互补的文章。

    7. Leechael

      同理,对于语言,我认为多语言混合使用进行互补将会是一个新的趋向。例如 Google,我认为不会放弃使用 Python,或者他们会考虑将数个数据中心抽象为一个主机,而 Python 的角色就是对着一个“主机”进行操作。主机底层或者会是用 Go、或者其他。单纯转换编程语言不是提升性能的重点,良好的分层和抽象(或者说,思想)才是提升性能的关键。

    8. 严重关注!

    9. grant

      key-value确实用的越来越多了。

      非常看好,分布式存储的一些方案。可运营和简单是非常重要的考量因素。

    10. 面对海量数据,我想主要是三个层面的解决方案:
      1、存储,如典型的GFS
      2、计算,如典型的MapReduce
      3、用户编程接口,如典型的Hive

      前两个是基础,后一个是发扬光大的保证,但是都还不太成熟,GFS等主要还是针对非结构化数据,但实际上结构化数据的需求也是非常浩大,类似于DTS的实现也将会诞生(或者已经有了,只是还未了解到),DTS就是Distributed Table System,单一的DTS意义不如GFS大,它必须和计算绑定在一起,共同发力,才显神通。

    11. Tim

      eejian:
      “结构化数据的需求也是非常浩大”, 结构化的有bigtable, dynamo 等,相关实现也已经是百花齐放了。

    12. 我更期待虚拟化,云计算以及 NoSQL.

    13. 新的数据库存储,以及基于数据的cache将变得越来越重要

    14. ywenbo

      Hi Tim,
      您认为ruby脚本语言和ROR框架会成为将来流行的趋势吗?如果不会,主要障碍或原因会有哪些?谢谢!

    15. Gary

      “目前阻碍很多key value产品推广很大一个障碍是运维的顾虑,而不是它们本身的性能。”
      理论来说,似乎很多nosql产品都可以替代传统数据库.且成为一种趋势,但实际情况却不可能,因为最终nosql产品,会限制在一些很特殊的,海量的应用.而传统数据库会逐渐增加对一些特性的支持,历史的发展,多次出现这样的情况.
      目前再先进的再强大再激进的一些公司,也会把关键的核心的业务,用传统数据库存储,片面强调用nosql产品替代传统数据库往往会失败,这种案例许多, 因为初衷是好的,但过程是艰难的,各种稳定性,灾难恢复性,速度持久性,高可用性的解决,以及硬件的发展,还需要一个漫长的过程.

    16. kerwin

      Hi Tim:
      回想今年系统构架领域的发展,再来回顾这篇发表于年初的文章。我觉得您的判断非常准确,分布式框架和nosql技术从09年的崛起到10年的广泛应用,有了不少的发展。现在的系统框架经历的这么多的实际应用以后变得更加成熟和稳健。能否对今年的系统框架领域的变化给予一个客观的总结呢?或者是对于明年的发展趋势?:)

    17. erlang +1

    18. erlang 最近发现很多牛人都在搞这个

    19. 更看到Erlang!

    20. grayhound

      我觉得架构的路线需要辩证的来看待。楼主应该是互联网行业的,站在的视角应该是从网站的高性能角度出发的。但是站在行业软件开发的角度,架构还是比较侧着越应对不断变化的业务变更来考虑。

    Leave a Comment