InfoQ

InfoQ

新闻

我的书签

登录注册 以永久保存书签。

该内容已经被标记书签!

标记书签错误,请重试!

敏捷,架构和凌晨5点的产品问题

作者 Deborah Hartmann Preuss 译者 李剑 发布于 2007年6月26日

领域
过程 & 实践
主题
架构 ,
敏捷 ,
质量交付
标签
重构 ,
补充实践 ,
测试驱动开发 ,
测试 ,
评论
Michael Nygard把自己列为那些仍然相信有架构这种东西存在的人之一。他在InfoQ发表的文章敏捷,架构和凌晨5点的产品问题(Agile, Architecture and the 5am Production Problem)中抛出了一个神秘的问题,并引导读者走完了从发现到解决的全过程。他在文章的最后总结道,当我们为真实的世界而非QA来构建产品应用时,需要有面向失败的思维和扎实的防御性编程策略。该文向敏捷社区中那些关于“够用就好”的架构组成的思想提出了挑战。

Nygard在Pragmatic Programmers出版的新书:“交付!设计和部署生产就绪软件”,在上个月牢牢占据了Amazon“热点新书发布”排行榜的首位。该文基于书中的一个故事进行了扩展,并把它与作者曾经经历过的敏捷过程——在那个时候,它们还被称为“轻量级方法学”——进行了结合:
敏捷方法告诉了我们很多关于如何构建能够灵活面对变化的功能性软件的方式。程序员们创建出一些诸如单元测试和 重构之类的技术来供其他程序员使用,并且将这些技艺完善推广。但是大多数情况下,敏捷方法只是关注于系统边界内的行为。在敏捷社区中,关于应该为系统边界 外的事物投入多大精力的争论一直在持续着。那些最极端的拥护者(他们算是“极限”的拥护者么?)声称,“让架构从持续的重构和强壮的单元测试中消失吧!”

我是一个敏捷开发者和架构师,但是你应该把我算入……那些坚信系统实现中仍然存在架构的人中。一个好的架构可以在真实世界中存活下来。而一个坏的架构只会 在运行时发出吱吱嘎嘎的响声和艰难的呻吟,对人和计算机都是一种摧残。我常常都能看到一些架构师沉迷于自己的抽象中,创造出一些根本无法成功构建的架构。
文章中讲述的那个神奇的问题只会在凌晨的一两个小时内,当网站的访问趋近於无了一段时间以后出现:一个应用每天早上5点都会宕掉,同时宕掉的还有一个只用于 查询的数据库。引发这个问题的地方——同时也是受害者——包括一个Web服务器,一个数据库服务器和一个防火墙。如果有些人的第一个想法就是:“如果你只 是查询的话,那根本不会导致死锁啊!”这些人就应该去看看Nygard到底发现了什么。

Nygard用这个故事来阐述被他称之为“面向失败思维”的观点,这并不是说他期待着项目会失败,而是在他构建系统的时候,就一直在假设由于某种原因,在 某一天,架构中的任何一个地方都有可能出现问题。他在书中强力推荐大家在构建一套测试体系时要充满各种恶意,从简单的网络连接断掉,到使用错误的协议来发 出响应,这样才能更全面地模拟各种失败的场景。

Nygard在文中向敏捷社区发起了挑战,因为社区中那些成天为“够用就好的架构”唱颂歌的人到现在还不知道这种想法在实际应用中意味着什么。同样,在不知多少文章和书籍中推荐过的特征驱动开发和极限编程,在解决这种问题的时候还是鞭长莫及。Nygard相信,在敏捷,架构和凌晨5点的产品问题一文中提出的问题领域内,敏捷方法只能保持明显的缄默。

敏捷已经敞开了双臂拥抱测试纪律,而且最近也在努力和技术文档(译者注:特指那些说明如何使用软件的文档)和可用性等其他纪律靠拢。那么有关架构的纪律也是敏捷实践要与之融合的候选之一吗?还是敏捷中已经收录了足够多的原则和实践,完全可以构建出一个强壮的架构了?

查看英文原文:Agile, Architecture and the 5am Production Problem

译者 李剑 李剑──ThoughtWorks高级咨询师,在持续集成、重构等领域具有丰富的经验;多次为国内大型企业敏捷组织转型提供咨询和培训服务。

很好,很和谐 发表人 小刀 凉粉 发表于
Re: 很好,很和谐 发表人 霍 泰稳 发表于
Re: 很好,很和谐 发表人 Guo Xiaogang 发表于
所有的痛苦都是类似的 发表人 zhou qiang 发表于
Re: 所有的痛苦都是类似的 发表人 霍 泰稳 发表于
Re: 所有的痛苦都是类似的 发表人 张 浩 发表于
  1. 返回顶部

    很好,很和谐

    发表人 小刀 凉粉

    这是多么彪悍的一篇文章啊

  2. 返回顶部

    Re: 很好,很和谐

    发表人 霍 泰稳

    够用就好有时带来的问题是对前面所有的功能推翻重来,或者有时会造成难以收拾的后果,所以说按照中庸的思想,还是前期充分考虑架构,然后逐步敏捷实现比较好一些。

  3. 返回顶部

    Re: 很好,很和谐

    发表人 Guo Xiaogang

    事后再回头看会觉得当初如果怎样怎样就好了,而忘了事前要正确地预测几乎是不可能的。试错的价值很难测量也很容易被忽略。在经过试错之前,正确完成的成本可能是无穷大,却很容易被当成是零。

  4. 返回顶部

    所有的痛苦都是类似的

    发表人 zhou qiang

    我现在也被类似的问题困扰,20台机器突然从JMS的服务器上断掉。几分钟以后会自动恢复。也是个拔头发的问题

  5. 返回顶部

    Re: 所有的痛苦都是类似的

    发表人 霍 泰稳

    楼上的宕机原因找到了吗,有什么解决的办法?分享一下。这是个非常有意思的话题。

  6. 返回顶部

    Re: 所有的痛苦都是类似的

    发表人 张 浩

    一旦流量开始升高,另外三十九个连接马上就锁定了。尽管剩余的一个连接还可以生成页面,但它迟早会被某一个线程占用,该线程阻塞在其余资源池的连接上。因此,唯一好使的连接也被阻塞线程占用了,整个网站也就掛了。


    据我所知,一个线程同时拥有两个以上资源池是完全应该避免的。如果有这个现象,在一般场合也会导致资源池竞争。

深度内容

应用云平台的可用性——从新浪SAE看云平台设计

云计算平台的可用性,相比传统互联网服务而言,更加复杂和困难,也更具有挑战性。本文借助新浪SAE云平台为读者讲述了云平台可用性的定义、如何打造高可用的平台,以及对云计算的用户提出了建议。

JVM定制改进 @ 淘宝

淘宝高度重视Java平台的健康发展,组建了一个团队专注于Java平台的底层部分的性能、功能与稳定性改进;工作主要基于OpenJDK中的HotSpot VM开展,其中一些通用的功能随后也会逐渐反馈给OpenJDK社区。希望能与使用Java平台开发应用的大家交流经验。
本次演讲视频录制于QCon杭州2011

"伤得起"的云计算应用——对云端应用之架构的思考

2011年4月21日至22日是值得云计算从业者纪念的日子。Amazon的IaaS服务出现故障,导致许多商业网站的服务中断,影响非常严重。作为云计算用户,我们需要思考的是,如何保证即便在云服务不可用的情况,我们的应用架构仍然能够屹立不倒?本文正是站在云计算用户的角度试图探讨这一问题。

让交付的速度跟上思考的速度

12人的技术团队,4组刀片服务器,每月20亿的访问量,每日1次准时部署,99.9%的可用性。这可能吗?当然。想知道如何做的吗?百姓网将与您分享他们在DevOps实践过程中的经验和技巧。
本次演讲视频录制于QCon杭州2011

架构之路——穿行在产品和业务之间

篱笆作为一家起源于社区的电子商务公司,反映到技术层面就是同时要面对产品和业务,以及经营战略的变化调整。如何在产品和业务的夹缝之间完成技术架构的抽象与平衡,寻找更有效的价值定位,这当中有些经验教训和个人感悟愿与众人分享。
本次演讲视频录制于QCon杭州2011

特性注入:成功三部曲

本文将对特性注入以及相关方法做一个扫盲性的介绍。我们会解释这个框架的关键要素,并附上实例来证实它们。为了让文章保持相对较短,我们不会深入到某个工具或方法中,而是会给出一些参考资料,以便大家做进一步的研究。

解析JDK 7的动态类型语言支持

随着JDK 7的发布,字节码指令集终于迎来了第一位新成员——invokedynamic指令。这条新增加的指令是JDK 7实现“动态类型语言(Dynamically Typed Language)”支持而进行的改进之一,也是为JDK 8可以顺利实现Lambda表达式做技术准备。在这篇文章中,我们将去了解JDK 7这项新特性的出现前因后果和它的意义。

Java Remoting远程服务(下)

随着互联网应用的发展,Java分布式远程服务技术受到越来越多的关注,本文将对各种相关实现以示例的形式逐一介绍,并总结其中的优缺点,使读者能够在技术选型时有所准备。这是文章的下篇。