转自：http://www.itivy.com/ivy/archive/2011/11/24/something-that-architecture-must-be-aware-of.html

对于大多数架构师而言，“可扩展性”在软件架构方面是最虚无缥缈的说法。这毫不奇怪，因为可扩展性正是如今软件设计领域最值得优先考虑的要素。然 而，计算机科学家们还无法了解一套单独的架构如何才能扩展至各类应用环境当中。相反，我们在数量繁多的方案中所设计出的可扩展性架构，往往以业界较为通用 的已知可扩展模式及个人偏好为标准。简单来讲，打造一套具备可扩展性的系统已经变得更像是一门艺术而不单单是技术。

我们常常会通过观摩杰作体会并学习艺术的精髓，而可扩展性也应该遵循同样的路线！

在这篇文章中，我将列出数款为大家所耳熟能详的可扩展性架构。通常情况下，架构师们完全可以借鉴已知的可扩展架构模式，进而创造出新的可扩展架构。

1. LB (负载平衡器) + 无共享单位 - 该模型中包含一系列单元，各单元彼此间不共享任何内容，且一致指向一个将输入文讯按一定条件发往单元处的负载平衡器（这构成一个循 环，以负载等情况为基础）。每个单元可以是一个单独的节点或是紧密耦合的节点所构成的集群。用户可以使用DNS循环、硬件负载平衡器或者软件负载平衡器达 成负载平衡效果。创建一套负载均衡的层次结构，并在其中结合前面提到的各种负载平衡器也是可行的。在由Michael Stonebraker撰写的《 无共享体系架构实例 》一文中，专门讨论了此类架构。
    
2. LB + 无状态节点 + 可扩展存储 - 传统的 三层式Web架构 使用的就是这种模型。该模型包括数个与可扩展存储交互的无状态节点以及一个分布于节点间负载中的负载平衡器。在这一模型中，存储通常作为限制因素存在，但NoSQL存储则可以利用这套模型创建出具备相当可扩展性的系统。
    
3. 点对点架构 (分布式Hash列表 (简称DHT)以及内容寻址网络(简称CAN)) -这套模型提供了一些传统的 可扩展算法，这些算法的各个方面几乎全部按对数进行了等比例增加。举例来说，像Chord、Pastry（特指免费版）以及CAN都属于此类。而以 Cassandra为代表的、基于P2P架构的几款NoSQL系统也是其中的成员。《 展望P2P系统中的数据 》一文就深入探讨了这类模型的各种细节。
    
4. 分布式队列 – 这种模型以将队列实施（即先进先出交付机制）作为网络服务处理为基础。该模型通过JMS队列而广泛得到采用。一般会遵循这种做法的有任务队列以及通过保持队列分级体系实现扩展性的任务队列版本，后者在负载无法及时处理时，任务会由低级层面向高级层面传递。
    
5. 发布/订阅模式 - 一般用于通过网络向彼此发布订阅讯息。《 发布与订阅的多面性 》这一经典论文中详细的介绍这一模型，该模型方面最典型的例子即 NaradaBroker与 EventJava 。
    
6. 小道消息与自然灵感式模型 - 这种模型源自日常生活中小道消息的传播途径，也就是每个节点将随机选择后续节点以交 换信息。正如现实生活中的实际反馈，这种八卦型算法在信息传播方面出奇地迅速。该模型的另一大分支则是受到生物学影响的启发式算法。自然世界中存在着大量 协调及扩展方面极为卓越的固有算法。举例来说，蚂蚁、人类以及蜜蜂等等，都能够以最简洁的交流方式协调好扩展性方面的需要。模型中的算法正是借鉴了这些实 际存在的现象。在论文《 从流行病的蔓延到分布式计算 》中对这种模型有着详尽的叙述。
    
7. 地图缩小/数据流 - 这一概念首先由谷歌公司提出，地图缩小为工作的描述及执行提供了一套可扩展的模式。虽然内容 简单，但它仍然成为联机分析处理方面的首要处理模式。数据流则是一种更先进的方式，用来表达执行信息；而像Dryad及Pig这样的项目为数据流的执行提 供了可扩展的框架。论文《 地图缩小：大型集群上的简化数据处理 》中设置了专门的主题，详细讨论这一内容。Apache的Hadoop就是这种模型的代表性产品。
    
8. 责任树形图 - 这种模型打破了递归问题的束缚，将整个流程以树状形式加以处理；每个父节点将工作下放至子节点。这种模型扩展性强，并已经被应用于数款可扩展性架构当中。
    
9. 流处理 - 这种模型被用于处理源源不断的数据流及数据。这种处理方式通过网络中的处理节点获得支持（例如Aurora、Twitter Strom以及Apache S4等）。
    
10. 可扩展存储 – 该模型的应用范围从数据库、NoSQL存储、服务注册到文件系统都有体现。 链接中的这篇文章 以可扩展性为切入点对其进行了深入讨论。

综上所述，可扩展性的实现只有三种方式，即：分布、缓存及异步处理。前文所提到的各种架构事实上都是把这三种方式进行不同组合并加以实施。而另一方 面，不利于可扩展性的因素，除了糟糕的编码本身，全局性协调也起到了重要的影响。简单来说，任何一种全局性协调都会限制系统的可扩展性。本文中所提到的各 种架构也只是在做好了本地性协调，而非全局性协调。

然而，将它们有机地结合起来以创建一套极具可扩展性的架构可不像说起来那么容易，除非我们能找到一种全新的扩展模式。不过经验告诉我们，比起搞一套全新的架构，采用为我们所熟知且更易驾驭的可扩展性解决方案永远是更好的选择。