InfoQ

新闻

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

作者 Gavin Terrill 译者 郭晓刚 发布于 2007年12月16日 下午3时4分

社区
Architecture
主题
交付价值,
商业,
领导能力
标签
管理,
架构评估

最近在博客世界中有一个有意思的讨论:应该花多少时间去预先为可伸缩性而进行设计。讨论始自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?
很棒 发表人 ma michael 发表于 2007年12月16日 下午9时46分
Re: 很棒 发表人 Xiaogang Guo 发表于 2007年12月16日 下午10时14分
mysqlconf2007上的一份文档 发表人 ma michael 发表于 2007年12月16日 下午11时52分
我是倾向于把伸缩性作为基础进行考虑的 发表人 Jeffrey Zhao 发表于 2007年12月22日 上午4时7分
  1. 返回顶部

    很棒

    2007年12月16日 下午9时46分 发表人 ma michael

    很棒的一篇文章,flickr分享的一篇文章对这个问题我觉得阐述的比较好。

  2. 返回顶部

    Re: 很棒

    2007年12月16日 下午10时14分 发表人 Xiaogang Guo

    请问是哪一篇,能不能分享一下?

  3. 返回顶部

    mysqlconf2007上的一份文档

    2007年12月16日 下午11时52分 发表人 ma michael

    http://www.kitchensoap.com/talks/MySQLConf2007-Capacity.pdf

  4. 返回顶部

    我是倾向于把伸缩性作为基础进行考虑的

    2007年12月22日 上午4时7分 发表人 Jeffrey Zhao

    可是这个“度”是需要把握的……

深度内容

和Google互补的搜索引擎Wolfram|Alpha

Wolfram|Alpha与Google究竟是什么关系,Wolfram|Alpha自己是如何定位的?Wolfram|Alaph在多大程度上是语义网搜索呢?InfoQ中文站就等等这些问题采访了Wolfram研究公司中国区商务经理王翔。

SOA契约成熟度模型

本文说明了所推荐的契约版本管理设计策略是如何与SOA成熟度模型发生联系的。文章目的是为实现版本管理和可组合性提供一个路线图。

数据服务简介

Vijay Narayanan在这篇文章中对数据服务的几个方面进行了介绍,它们都是SOA实践者和数据架构师感兴趣的内容。本文对数据服务的几个方面进行了介绍,包括需求定义,基本原理和好处、范围、开发以及消费模式。

分块云计算

在本文中,Jimmy Nilsson描述了一种他在过去数年间观察到的一种正在缓慢成长的架构风格,他把这种风格称为“分块云计算”。

豆瓣网技术架构变迁

罗马不是一天建成的,豆瓣的技术架构也是随着用户规模的增长一直在持续变化中。在本次演讲中,豆瓣的首席架构师洪强宁将与大家一起分享从上线时的单台服务器架构开始一直到现在的豆瓣架构变迁历程。

融合思想:深入探索S#arp架构

Billy McCafferty展示了S#arp架构,它在ASP.NET MVC框架的基础上,荟萃了当今的最佳实践,应用在ASP.NET Web应用程序的架构设计中。

王雷谈开源以及新兴市场计划

中国作为新兴市场中的新兴市场,是Sun在美国之外实施SSE(SUN Startup Essentials)项目重点关注的地区。在QCon Beijing 2009期间,InfoQ中文站有幸对此项目的负责人王雷先生进行了采访,探讨了关于开源、新兴市场、SSE等话题。

使用HTML5构建下一代的Web Form

HTML5 是由 WHATWG发起的,最开始的名称叫做Web Application 1.0,而后这个标准吸纳了Web Forms 2.0的标准,并一同被W3C组织所采用,合并成为下一代的HTML5标准。