可伸缩系统的设计模式

过去十年所取得的一个主要成就就是面向大众的可伸缩系统的广泛应用,尤其是云系统和某些高可伸缩的Web应用。比如说,Facebook平均每秒可以处理1300万个请求,峰值达到了450 M/s。即便如此,可伸缩系统背后的概念与架构仍然在快速发展着。大约3年前,来自加利福尼亚洲的软件架构师Ricky Ho曾撰写博文详细分析了可伸缩系统的现状。3年后,他认为是时候重新谈谈这个话题了。

Ricky将可伸缩性定义为

可伸缩性解决的是在持续增长的性能、花费、维护代价以及众多其他因素的情况下如何降低系统的负面影响。

在其最新的博文中,他列举了如下模式:

  • 负载平衡
  • 分散与聚集
  • 结果缓存
  • 共享空间(又叫做Blackboard)
  • 管道与过滤
  • Map Reduce
  • 大块的同步并行
  • 执行编排

如果说负载平衡、结果缓存和Map Reduce已经得到了广泛应用,那么某些模式现在正面临着社会化媒体所带来的新问题。比如说,上个世纪80年代所提出的大块同步并行现在就作为Google Pregel Graph Processing项目的一部分,支持3种常见的处理模式:

  • 捕获(比如说John通过社交网络联系到了Peter,那么在这两个Person结点间就会建立一个连接)
  • 查询(比如说找到John的朋友当中年龄小于30且已婚的那些朋友)
  • 挖掘(比如说找到硅谷中最有影响力的人)

Ricky还介绍了执行编排模式:

该模型基于智能的调度者/编排者,用于跨越集群调度准备运行的任务(基于依赖图)。

他说该模式已经在微软的Dryad项目中得到了应用,程序员可以“使用成千上万台机器而无需了解并发编程”。

Dryad程序员会编写几个顺序程序,然后使用单向通道将其连接起来。计算是结构化的,以有向图的方式进行:程序是图形顶点,而通道则作为图的边。Dryad job是个图形生成器,可以合成任意方向的无圈图。这些图甚至可以在执行期间改变来响应计算中的重要事件。

我们今天所使用的可伸缩性模式仅有10年的历史。接下来会有什么限制呢?你有构建可伸缩系统的经历么?忽略了哪些东西呢?

查看英文原文:Scalable System Design Patterns

This entry was posted in Achitecture. Bookmark the permalink.

发表评论

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / 更改 )

Twitter picture

You are commenting using your Twitter account. Log Out / 更改 )

Facebook photo

You are commenting using your Facebook account. Log Out / 更改 )

Google+ photo

You are commenting using your Google+ account. Log Out / 更改 )

Connecting to %s