计算机系统的历史也是错误的历史，包括史诗性的，灾难性的错误 ，这些错误已导致数百万美元的损失， 毁灭甚至死亡 ，以及许多其他不那么引人注目但昂贵的系统和项目故障。 其中一些似乎是小而愚蠢的错误，例如臭名昭​​著的Ariane 5火箭坠毁 ，是由于单行编程错误引起的。 但是，单行编程错误或任何其他孤立的错误或故障，不会在没有架构和设计上的基本故障以及管理上的故障的情况下对大型系统造成严重损害。

波音787梦幻客机无处可去

经济学家，2013年2月26日

这些问题就是Barry Boehm所称的“ 体系结构破坏者 ”：当您首先面对基本的弱点或对使用这种方法可能发生的事情进行严格限制时，系统的设计在现实世界中就不会成立。您选择的技术平台。

架构破坏者发生在设计的边缘（或超出边缘），偏离正常，正常， 愉快的道路 。 该系统正常工作，除了“百万分之一”的特殊错误，除非每隔几天就发生“百万分之一”的问题，否则没人会认真对待。 否则，系统会在需求激增的情况下崩溃，除非您无法找到一种方法来快速扩展系统以保持正常运行，否则需求将不会消失–如果无法解决，您将没有解决方案。不再有需求问题，因为这些客户不会再回来了。 或者看似很小的操作问题原来是系统中基本可靠性或安全性问题的第一个迹象。

有关安全性的问题使Dreamliner陷入困境

纽约时报，2013年1月10日

寻找架构破坏者

它以讨厌的错误或孤立的操作问题或安全事件开始。 随着研究的深入，您会发现更多的情况，设计上的漏洞，对系统功能的严格限制或无法解释且无法阻止的故障。 随着每个问题引发另一个问题，设计开始瓦解。 正确地解决它会花费时间和金钱，甚至可能要花些时间重新审视基础架构决策和技术选择。 看起来像是随机故障或丑陋的错误变成了丑陋得多的东西，而且价格昂贵得多。

波音787危机加深

纽约时报，2013年1月17日

使这些问题特别糟糕的是，通常在系统已经投入生产并且您有很多真正的客户使用它来完成实际工作时，发现它们的时间很晚，超过设计甚至是验收测试。 这是您最无法承受遇到严重问题的时间。 当某件事确实出现问题时，可能很难立即意识到它的严重性。 您可能需要经历两三个或三个以上的失败，然后才能意识到并接受真正的糟糕情况，并且您没有足够的模式来了解问题可能出在哪里。

波音电池在事故发生前十次失效

彭博社，2013年1月30日

到那时，您可能会失去客户并损失资金，并且承受着巨大的压力来提出解决方案，而没人想听到您必须停下来回去重写系统的一部分，或者重新架构它然后重新开始–或者您需要更多时间思考和测试并了解问题所在以及所采取的措施，然后您甚至可以告诉他们可能需要花费多长时间以及花费多少钱才能解决问题。

波音787飞机在全球各地的监管机构

纽约时报，2013年1月18日

有什么可以破坏您的体系结构？

大多数体系结构破坏者是系统重要非功能性方面的基本问题：

• 稳定性和数据完整性：系统运行了数小时，数天或数周后，系统的某些部分将无法承受负载或间歇性故障，或者丢失了重要的客户数据，或者无法足够快地恢复和恢复服务操作失败后。
• 可扩展性和吞吐量：平台（语言，容器，通信结构或数据库，或所有这些）使用起来很漂亮，但即使有更多的硬件投入，也无法跟上更多客户的需求。 向Twitter查询有关尝试扩展Ruby或Facebook的有关PHP扩展或任何曾经尝试扩展Oracle RAC的人员的信息。
• 延迟-实时响应时间/截止日期满意度的要求不断提高，或者您陷入不可接受的抖动和可变性中（选择Java作为运行时平台，GC启动后会发生什么？）。
• 安全性：您刚刚被黑客入侵，并且发现攻击者利用的一个错误只是需要发现和修复的数百个或数千个错误中的第一个，因为您的设计或所选择的语言和框架（或您的使用方式）就像瑞士奶酪一样充满安全漏洞。

这些问题可能来自对底层平台技术或框架实际上可以做什么的误解—该架构或技术的设计公差是多少。 或者是由于完全丢失，忽略，忽略或误解了设计的重要方面。

这些并不是您可以编写出自己的方法的问题，至少不容易。 有时，问题不是您的代码以任何方式出现的：它是第三方平台技术无法跟上或不会跟上。 语言本身，或堆栈的重要组成部分（如容器，数据库或通信结构），或者群集和故障转移或执行其他操作所依赖的语言。 在现实世界中，几乎任何其他人编写的软件都可能并且将无法满足您的实际需求或供应商的承诺。

波音公司787电池供应商的修复可能性不高

华尔街日报，2013年2月27日

您将不得不花费时间与供应商（或有时与多个供应商）合作，帮助他们理解您的问题，并使他们同意这确实是他们的问题，他们必须解决它，如果可以的话不能解决它，或者不能足够快地解决它，您需要快速提出计划B，并希望您的新选择不会遇到其他可能同样或什至更糟的问题。

如何避免架构破坏者

破坏体系结构是由您做出的决策过早而出错–或您做得不够早或根本没有做出决定的。 勃姆（Boehm） 谈到架构破坏者是反对简单设计的论点的一部分–许多团队， 尤其是敏捷团队 ，花太多的时间专注于幸福的道路 ，建立新的功能以使客户满意，而没有足够的时间进行前期的架构和思考关于可能出问题的地方。 但是Architecture Breakers比敏捷和简单的设计要长得多：在制作软件 （第10章架构设计：多少和什么时候）中，Boehm可以追溯到1980年代，当时他第一次意识到这些问题，当时是结构化编程，后来是Waterfall。是做事的“正确方法”。

Boehm的解决方案是通过Spiral软件开发获得越来越多的体系结构定义和技术风险管理：一个具有体系结构的生命周期，可以预先识别风险区域，然后通过迭代，风险驱动的设计，原型开发和多个阶段进行探索。 螺旋开发就像今天的基于类固醇的迭代增量开发方法一样 ，使用基于风险的体系结构峰值 ，但是迭代开发和技术原型开发周期更长，更加正式的风险管理，更多的计划，更多的书面工作以及更高的成本。

通过在架构和技术风险管理上花更多的时间，不能解决所有这些问题，无论是通过螺旋开发还是加强， 纪律严明的敏捷开发方法。 如果您对可伸缩性，响应性，可靠性或安全性做出过幼稚的假设，那么花在前端的更多时间将无济于事。 或者如果您对这些问题的理解不够深刻，无法确定风险。 不会在设计评论中找到“体系结构破坏者”-因为您将不会寻找自己不知道会出现问题的东西-除非您正在运行诸如FMEA（故障模式和效果分析）之类的结构化故障建模练习或FMECA（故障模式，影响和严重性分析） ，这迫使您提出一些棘手的问题，但是，受监管行业之外很少有人听说过。

而且，即使即使以这种方式发现的所有错误都被认真对待（因为这些），架构破坏者也无法全神贯注于测试 ，甚至无法进行 长寿/浸泡测试 ，广泛的模糊 测试和模拟故障以及故障注入，破坏性测试和压力测试。各种极端测试通常被认为是不现实的）。

您必须准备好应对Architecture Breakers。 预见问题并使用类似分区的架构稳定性模式在迈克尔·尼加德的优秀图书版本吧！ 至少可以防止严重的运行时错误扩散并破坏整个系统（这些策略也将有助于扩展并遏制安全攻击）。 而且，如果在检查，测试或生产中确实看到“一次百万分之一”的错误，请了解它的严重性并立即采取行动-在Dreamliner变成噩梦之前。

翻译自: https://www.javacodegeeks.com/2013/04/architecture-breaking-bugs-when-a-dreamliner-becomes-a-nightmare.html