Amdahl's Law与伸缩性（scalability）

读到这篇博客：Hitting the Scalability Wall - Amdahl's Law。

Amdahl's Law指出，如果您的系统中的任一部分要求串行化处理，而不能并行化，那么系统就会撞上伸缩性之墙，不能再提升性能，不论您再投入多少硬件。

关于Amdahl's Law的细节，请参考Wikipedia的条目。

伸缩性是架构设计中考虑的一个重要方面。基本上，我们是在讨论如何提高系统的吞吐量。这让我想到《目标》一书中的约束理论（TOC），扩大系统吞吐量方法是找到瓶颈并消除。书中有一个例子，新购买的一台强大的加工机器取代了原来的两台旧机器，但不幸却成为了系统的瓶颈，因为大多数零件需要“串行地”经过这台机器的加工。解决办法？找回原来的两台旧机器，让工作能够“并行的”进行！

Prevayler在主页上声称比MySQL快3000倍，比Oracle快9000倍。但不管怎样，它也会撞上伸缩性之墙，因为它的事务是“串行”处理的。硬盘的访问也是串行的。这是否意味着我们无法设计出高伸缩性的系统？

不是的。我们可以通过硬盘阵列，数据库表分区（Sharding），让硬盘访问能够并行地进行。我们也可以用Prevayler实现LDAP的后端，利用LDAP协议本身的复制和分子树的能力，化解串行访问对伸缩性的影响，构造高伸缩性的系统。（做一个支持大量并发的身份证查询系统？）

开发方法学也有伸缩性问题。我们曾听说过，许多敏捷方法“don't scale very well”。不能支持大型团队，在短时期内交付大量的特征（客户价值）。究其原因，很大程度上是因为“隐式的知识”沟通是串行式进行的。

传统开发方法学也存在沟通问题。团队加入新成员后，短期会出现产能下降。因为新成员需要学习，老成员要抽出时间来教他们。

提高产能的方法就是把串行消除掉，让项目能够并行地开发。这一点恰恰是特征驱动开发（FDD）做得比较好的地方。前期经过尽可能短的串行处理（整体建模、特征列表、优先级）之后，后续的开发就可以并行展开了。所以搞FDD的人声称，可以实现可重复的成功，可以适应大型的开发项目。新加坡项目就是50个人15个月的银行项目。

FDD是一系列最佳实践的组合。并行开发的另一个关键在于组件化。使用同样的组件化架构风格，处理子系统、系统、和“众系统之系统”。让开发者熟悉了系统的一个部分，就很容易熟悉系统的另一个部分。这就是Fred Brooks所谓的“概念完整性”。将不同粒度的业务事件，开发成不同粒度的组件，用Peter Coad的话来说，实现了“模型的伸缩性”。

开发完了再测试（瀑布式）还是开发一点测试一点（迭代增量式）？Amdahl's Law告诉我们，要并发！得到详细的需求规格说明书后再开始设计和编码，还是像FDD那样把局部的详细需求放到迭代开发之中去？Amdahl's Law告诉我们，要并发！各模块开发好了之后再集成，还是持续集成？Amdahl's Law告诉我们，要并发！

由此我甚至进一步想到，FDD的前面三项串行工作也不是必须的。在实践中也遇到了这样的情形，特别是在创新的业务领域中。新加坡项目刚好是成熟的业务领域。我们可以让业务模型一点点长出来。清楚一部分，做一部分，但要在同一种架构风格（如彩色UML或5w and an H）指导下，确保整个系统的概念完整性。

和这些前辈高人神交，人生一大快事也！