预先设计的大架构——过早考虑伸缩性之一例？

最近在博客世界中有一个有意思的讨论：应该花多少时间去预先为可伸缩性而进行设计。讨论始自 OnStartUps 的 Dharmesh Shah，他撰文讨论“过早考虑伸缩性（Premature Scalaculation）”的危险：

在初创企业中，技术奠基人常常把自己作为一个可伸缩系统的架构师所拥有的技能当作是荣誉的勋章。团队中的每个人都把公司日后取得惊人的成功看作是理所当然的，因此花费大量的时间和金钱去保证到时候系统（软件和基础设施）能够应付得了。这样的想法常常都是误入歧途。

这篇文章的立论前提是，宝贵的资源应该投向更紧迫的业务需要，而不是基础设施：

这些资源应该用来尝试可行的方案，而不是消耗到错综复杂的软件设计、代码优化和基础设施升级。

设计一个可伸缩的系统更加昂贵，这个假设是否仍然成立？（换个说法：设计一个不可伸缩的系统是否成本较低？）Todd Hoff 不这么认为：

即使我以前相信这个说法，现在也不相信了。世界已经变了，从 2005 年开始。得益于许多讨论如何伸缩的论文和书籍，关于伸缩的知识不再是稀罕、珍贵的资源。自从 Nicolas Cage 挺身而出，从一小撮专家攥紧的干瘪手指里把伸缩性的秘密刺探出来，这些知识就不再只被一小撮人掌握。现在任何一个计算机业的熟练工人都能设计出一个过得去的可伸缩系统。

Kevin Johnson 不同意可伸缩性属于“优化问题”的说法，他还指出了“预先的投入会反咬你一口”这类说法中应当考虑的一些因素：

把可伸缩性归类为优化问题存在基本的错误。可伸缩性属于非功能性需求的类别。它让公司处在一些特质的荫庇之下——安全性、可维护性、可用性，以及其他某某性等等。非功能性需求的主要挑战是，如果不尽早在项目的架构和设计阶段纳入考虑，它们很容易招致大规模返工的风险。

公平起见， Sinclair Schuller 指出了 Dharmesh 在后续评论中补充的理论基础：

我在文中本应说明这一点：当就可伸缩性进行权衡时，你是在某种程度上承受技术负债。负债并不总是坏事——它常常可以帮助你成长。关键是保证负债的“利率”不会超过换来的收益。因此，如果在可伸缩性上的一项妥协交易很可能会导致你要重写整个系统，那么可能是不值得的。但是，如果只是“现在付 X 或者以后付 1.2X”，那么在有些情况下选择“以后付 1.2X”会更好。

Jamie Flournoy 就“处理能力 vs. 可伸缩性（Capacity vs. Scalability）”提出了一个有趣的观点，他认为根据处理能力的需求，存在一个拐点可以决定对可伸缩性的投入是否有意义：

可伸缩性和能力是非常不同的两个概念。一个系统的可伸缩性并不是用有 / 无来衡量的；可伸缩性有不同的程度，可以用一个二维坐标图来表示，X 轴是在可接受的响应时间内系统能承受的并发请求数，Y 轴是满足这些请求所需的资源。这个 y=f(x) 方程的图像所显示出来的 f 函数，就是你的应用的伸缩能力。如果它是一条直线，那就是非常好的“线性伸缩性”。即使有更多的请求，每个请求所需的资源仍然和你现在的情况是一样的。客户翻倍，你的利润也翻倍。

如果曲线向下方弯曲，那比线性伸缩性更好：你可以获得规模效益，也就是说两倍的请求所需的开销比你现在开销的两倍要少。

如果曲线向上弯曲，那就糟糕了。因为更多的负载意味着每请求的成本更高。每个新客户都比上一个客户让你赚更少的钱。最终会到达一个让你开始赔钱的点，生意就失败了。

他继续说：

更有意义的问题是，你增加处理能力要花费多少，是否存在一个特定的请求数，只要超过它你就开始赚钱或者亏钱。

在项目发端时软件设计和架构通常涉及很多在很深入的业务和技术层面上的权衡之间维持平衡。平台、数据库、语言和工具的选择等等因素都在其中扮演着角色。要想让项目顺利进行，架构师的挑战是要运用自己的经验和直觉去引导决策过程，使之合乎环境的要求。是的，“作为一个可伸缩系统的架构师所拥有的技能”确实是“荣誉的勋章”，但它会妨碍架构师扮演 Ted Neward 所说的同时关注“客户 / 业务价值和技术细节”的角色。

我们是否可以信任架构师去作出对业务有显著影响的技术决策呢？对于应该花费多少精力去预先进行架构设计，你又根据什么样的指导原则去确定呢？

查看英文原文： Big Architecture Up Front - A Case of Premature Scalaculation?