|
软件架构的重要性在于它会影响整个软件系统。只有审慎地选择软件架构，才能降低风险，避免失败。 架构扮演着系统骨架的角色。无论开发者是否有意选择架构，所有系统皆有架构。对于软件系统而言，世上虽不存在唯一正确的架构，不过或多或少都有适合的系统骨架。 软件架构师 架构影响质量属性。质量属性是外部可见的，例如，安全性、可用性、延迟时间或可修改性。不同的系统骨架在处理不同的系统负荷时，会有优劣之分，因此，挑选恰当的架构会更容易满足质量属性。架构与功能(基本上)是正交的对于同一系统而言，既可能构建为三层架构，也可能构建为对等网络系统。然而一旦架构与功能匹配欠佳，开发者就要努力克服之。 架构是对系统的约束。架构是对系统恰如其分地施加约束，以便系统获得我们所需质量属性的一门艺术。例如，为了确保可伸缩性，或许就会要求一些组件是无状态的。下面将依次阐述这些观点。 架构是对系统的约束 架构是系统的骨架。骨架作为架构的隐喻，虽有不足却很有用。骨架为动物提供了整体结构，以支撑其行动。鸟之所以善飞，袋鼠之所以善跳，完全得益于它们各自的骨架。大多数行动迅捷的动物都拥有四条腿，而两条腿的动物虽然行动会慢些，却更善于使用工具。除非你说跳比飞好，否则就不能说一种骨架优于另一种骨架。你可以说一种骨架是否很好地适合其功能，例如，要让袋鼠的骨架适于飞翔，势必要大费周章。 软件亦如是。三层架构使得信息技术系统可以把变更限制在局部范围，并能处理事务性的负载。之所以协作进程架构更适合操作系统，是因为它能够隔离故障。很难想象，类似Skype的分布式VOIP网络系统若不使用对等网络架构，会是怎样的情形。 然而，之所以说骨架的隐喻存在不足，是因为架构并不仅仅是那些外部可见的主体部分(即骨骼)，某些不可见部分(如约束)通常更重要。例如，锁策略、内存管理策略或者集成第三方组件的技术，都可以是架构的一部分，而在运行的系统或源代码中，这些内容都是不可见的。 架构师 架构影响质量。开发者必须关注其软件做了什么，即软件的功能。要是财会软件不能管理账务，动画软件不能制作动画，对于这样的软件，只能弃之如履。此外，系统还包含许多与功能无关的额外需求，通常称之为质量属性需求。同样，开发者必须重视质量属性需求，因为要是财会软件如果让别有居心的家伙读取到保密账户，或者动画软件的运行速度异常缓慢，都会让人选择放弃。 系统架构不仅要支持所需的功能，同时还能够促进或抑制诸如安全或性能等系统质量。尽管人和马的身体骨架都支持运输苹果到市场的功能，但在运输效率和数量上却相差甚远。选择一种架构使得系统能够工作并非难事，但在满足质量属性方面，有的选择是事半功倍，有的选择则会事倍功半。 功能随着时间的推移而演化，这对于任何一个系统都是一种挑战，而质量属性的演化却会迫使系统产生剧变。设计一个系统，使其从支持一百名用户扩展到十万名，要想不改变架构，几乎不可能做到。我们经常可以看到，应用系统持续不断的变迁与波动，导致旧有的架构无法满足其增长，这有些像螃蟹的躯体变得越来越大，超过了它所寄居的蟹壳。 架构与功能(基本上)是正交的。没有一个放之四海而皆准的最佳架构，就像动物的骨架一般，各有所长，各有所短。要是袋鼠拥有了中空骨骼，那跳跃时就非常容易折断，要是鸟儿拥有了强壮的双腿，那飞起来就会像鸵鸟一样笨拙。另一方面，可能会选定一种骨架，并迫使其在不适宜的环境下工作。例如，鱼类可以在水中呼吸，哺乳动物却不能。然而，鲸尽管属于哺乳动物，却能打破这一约束而生活在水中，虽然要费些周折。 软件架构师需要不断地思考 重要的是，我们要认识到架构与功能可以相互混合，取长补短。我们可以改变系统的架构并保持功能不变；抑或在提供不同功能的系统上重用同一套架构。不过，二者的组合取得的效果不尽相同，或者珠联璧合，或者水火不容。 虽然对系统架构的选择与功能是相互独立的，但糟糕的架构决策总是会给功能与质量属性的实现带来障碍。这就好比工厂制造的产品与其所处的地理位置属于两个截然不同的维度，你完全可以在二者彼此独立的情况下作出抉择。要在大漠之中修建船厂也非不可，不过要将造好的船只拖到港口，就得费九牛二虎之力了。只要你能付出足够的努力，无论选择哪种架构都可以构建出各种系统，然而，一旦架构选择失当，开发者就会举步维艰。 架构约束程序。任何系统皆有约束。某些系统需要与旧有系统进行互操作，某些系统强制要求使用指定供应商的子组件，还有的系统则必须满足内存或时间的预算。这些约束常常被视为绊脚石，它们使得开发者的工作变得更为棘手；然而，不妨换种思路去看待这些约束。 在设计系统时，你的选择会将系统限制为某种工作方式，而不是另一种。有时这些选择是随意而为的。不过有些选择却可以限制系统具有某种意图，从而引导系统到达所选择的目的地。对于系统建设、系统执行作业的能力及与时俱进的维护能力而言，此类约束条件起着导轨的作用，并且至关重要。 研究系统建设 设计系统时，可以约束实现方法的唯一性。有时候，这些选择显得随意而为；然而，有些选择却可以指导系统的设计走向期望达到的目标。这样的约束起到了指南针的作用，是构造一个系统必需的行动指南，既可以指导工作的实现，又能够随着时间的变迁，有助于维护整个系统。 系统不做什么与系统能做什么同等重要。要确保系统具备特定的质量属性，就必须施加约束，以便明示那些不能做的事情。例如，安全的系统不会与不可信的第三方交换数据，而可用的系统不会在没有提供取消选项的情况下就启动长时间运行的计算。 为了实现性能或安全等质量要求，可以主动对自己的设计进行约束。例如，火车受到轨道的约束，因而行驶路线缺乏灵活性。但是，这种约束却有助于其他的质量要求，例如，车轮与轨道的摩擦力较小，因而可以提高行进速度。随之带来的好处还有安全，因为要劫持一辆火车相对比较困难。从字面上讲，不受限制的设计可以做任何事情，因此若是希望对系统进行分析，就必须给予限制。关于约束的使用贯穿本书始终，随后我们会回来继续讨论，并提供更为详尽的例子。 工程师通过约束来保证设计的系统满足其意图。只要运用得当，就可以从约束中获益良多： 体现判断。约束有利于知识在开发者之间的传递，便于达成共识。资深工程师对行业的了解更加细致而深入，但却要花费时间才能将此类知识传递给其他人。通过对设计进行约束，就可以指导其他工程师接受解决方案，无须完整地传递他们所拥有的知识。 软件开发需要一个好的架构 促进概念完整性。FredBrooks认为，系统的概念完整性是系统设计的重要目标，因此运用一个始终如一的好主意胜过几个散布于系统各处的奇思妙想。Souza持有相同观点，他在谈到架构约束时，认为开发者应该“减少不必要的创新”，将这种创新力放到需要的地方。 降低复杂度。作为概念完整性的必然结果，约束可以化繁为简，从而使得就此构建的系统具有显而易见的基本原则。相比之下，没有约束的系统则可能以任意不同的方式在不同的地方去完成类似的工作，从而影响对系统的理解，除非能够完全掌握系统的所有细枝末节。约束提供了明确的做法，可以砍掉此类复杂性。例如，如果数据只能保存至某个数据库，那么你就能知道该去哪里找数据。 理解运行时行为。虽然可以直接审查源代码，但却难以预测其运行时行为。可以编写出晦涩艰深的代码，使其运行时行为令人费解；抑或对其加以约束，从而使其运行时行为变得显而易见。 在某些时候，你可能会抱怨系统施加的约束让人变得缩手缩脚。虽然确有约束使用不当的情况发生，然而离开了约束，设计就无从谈起。不能因噎废食，因为约束可以使得混乱归于井然有序，而这种混乱恰好是工程师的大敌。必须妥善地对系统施加约束，而不能全盘否定。对系统架构的设计就是对决策进行推敲与取舍，判断什么该做，什么不能做。任何对于施加约束的犹疑不定都不会来自对它们的明智使用，而是来自其他人草率、无知的滥用约束方式。 |
|
|
