可伸缩系统的设计模式

过去十年所取得的一个主要成就就是面向大众的可伸缩系统的广泛应用，尤其是云系统和某些高可伸缩的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