读微软架构指南1

1 什么是软件架构

如下是几个对软件架构的理解：

• 应用软件架构（architecture）是指一个过程，在这个过程中来定义一个合理的软件结构，这个结构满足所有的技术和操作需求，同时保证更优的软件质量。软件质量参数包括性能，安全性，可管理性，以及保证应用软件最后能够成功问世等内容。
• 应用软件架构过程是围绕着一系列的重要决策进行，这些决策包括：系统构件的选择，构件间接口的设计，构件间如何进行组合，各个构件的行为以及它们之间如何配合工作，如何将这些构件以及行为元素组成更大的子系统，以及选择一个总领全局的架构风格。软件架构过程还包括功能性，可靠性，性能，可重用，可理解，经济性以及技术条件约束，各种决策的取舍以及审美的考量。
• 从这个系统的顶层出发，将系统分解为若干小的子系统，分解后的每个子系统又有其自身的架构方案，且这些方案通常会随软件系统的生命期不断变化，最后，架构即浓缩为最终剩下的一些最为重要的系统内容。
• 软件架构过程即一个动态决策和设计进化的过程。
• 软件架构也可以理解为是一个最终形态，即软件或系统的结构。其中的组成元素即各种软件组件。这些组件从外部看，只有其公共接口，以及不同组件间的关系。架构只是这些公共的，外部直接可见的接口及关系（或协作）。而组件的内部细节，并非架构所关注的内容。

1.1 软件架构的重要性

其实软件的架构和现实世界中的工程的架构都是一个意思，即进行构建。

任何软件都必须在一个坚实的基础上建立起来。虽然现代软件工具可以简化构建的实施过程，但它们无法简化或自动完成软件的架构设计。

软件架构过程中需要考虑的因素有三点：

• 用户
• 底层支撑平台
• 具体业务要求

而在架构过程中，时常在这三者间进行折中，进行平衡。例如，总体的用户体验总是由业务和底层平台来实现的，如果将业务或者底层平台做修改，就可能引起用户体验的极大变化。另外，如果对用户体验需求进行改变，也可能极大影响到业务的设计以及底层系统的选择。

性能可能是一个主要的用户体验目标以及业务目标，但对于底层系统来说，这个目标不会总是在考虑范围之内。必须针对这个目标，在三者中进行一个平衡。

软件架构的一个主要关注点是构成系统的构件之间如何进行交互。

而构件的数据结构和算法或实现细节则是设计过程中的关注点。

不过有些时候，架构关注点和设计关注点时常重叠，一般情况下，不要去硬生生将二者分离，而是将二者结合考虑。只有在特征十分明显的前提下，才分架构关注点和设计关注点来分别进行考虑。

在进行软件架构过程时，考虑如下高层次的关注内容：

• 用户是如何使用这个app的？
• 应用如何被部署到生产环境，如何在部署后进行管理？
• 应用的质量属性需求都有哪些？比如安全性、性能、多线程能力、国际化以及可配置性。
• 如何进行架构，以保障应用随时间推移的情况下，仍然有足够的灵活性来应对未来的维护要求？
• 当前业界架构的趋势是什么？这种趋势是否会对应用的未来产生影响？

1.2 软件架构的目标

软件架构的任务是在业务需求和技术需求间架设一座桥梁。即架构过程中首先会明确用例，而后寻找实现这些用例的途径，最终构成一个可用的软件系统。

架构的目标是识别需求中会影响到软件结构的各种内容。

好的软件架构能够在技术实现过程中，尽量降低有关业务风险。

一个好的设计必须足够灵活，能够适应随时间推移由软硬件技术改变所引起的变化。

架构必须考虑总体的设计决定，以及各种决策的权衡。

记住如下架构原则：

• 暴露系统结构，隐藏实现细节
• 明确所有可能的用例及使用场景
• 尽可能搜集到更多目标用户的需求
• 要处理功能性和质量性的需求

1.2.1 软件架构概览

首先要了解软件架构过程中影响到决策的一些因素，以及其中哪些因素会在未来对软件架构产生影响。

这些决定性因素主要由用户的意愿，产品性能以及环境的适应性所驱动。

以下是一些决定性因素：

• 使用场景
• 市场成熟度
• 设计灵活性
• 未来趋势

1.3 架构设计的一些主要原则

首先，在进行架构设计时，前提条件是这个设计会随时间不断发生变化，而当前的你无法预知之后的各种可能情况，也就是说无法在当前就设计一个架构可以满足未来的一切需求。

架构的设计需要随着系统的施工过程不断进化，因为这个过程中，会对面对的问题不断加深理解，并且现实世界中的需求也不断驱动架构的更新。

所以在架构设计过程中，必须要抱着进化的观点来看问题（新奥法施工隧道），这样的架构才能适应未来各种新需求。

在架构设计时，时刻关注如下问题：

• 在整个架构设计过程中，有哪些内容是不能被理解错的（如果理解错了就会导致整个软件系统无效，或是会给整个系统带来巨大风险）？
• 架构中有哪些部分是可变的？或者是哪些部分能够在未来延迟设计而不会影响到当前整个架构？
• 架构设计过程中，都有哪些基本假设？你又是如何测试这些假设的？
• 当什么情况发生时，会驱使你重构这个设计？

不要过度设计！不要做一些无法被验证或测试的假设！如果遇到这样的情况，将这些选项保留，在未来的架构中再加入它们。

需要明确哪些是架构中的基础性内容！如果这些内容设计错误，将会导致架构的重新设计，进而造成巨大损失。

1.3.1 架构设计准则

在架构设计时，需要记住如下原则：

• 以变化为前提进行设计，而非一次设计永远不变。
• 建模分析（如UML），降低风险。首先这个建模只是分析模型，不要过早进行详细设计，更不要以分析模型作为设计过早定型。
• 利用模型和视图作为交流和沟通工具。好的架构设计内容、决策内容以及未来设计变化三者的有机结合。利用模型、视图以及其他可视化工具来将架构呈现给更多的人，并将决策所引起的变化更快引入到已设计的架构中。
• 认真学习前人总结的关键工程决策内容，融入再总结。

尽量考虑使用一种增量的和迭代的方式来改善架构。

首先由一个架构骨架开始，对架构有一个总体的正确性验证，而后不断变化，生成更多的迭代架构，再对这些架构进行测试和修改优化。

不要尝试在第一次就把所有东西都全部完善，迭代有一个过程，设计过程中的每个决定都是建立在对需求和假设可测试的基础上的。

将设计细节加入，测试通过，再进行下一轮迭代，加入设计细节，再测试通过，如此往复。这样的过程可以保证设计决定的大方向是对的，之后只需要再次对设计细节进行完善即可。

一个常犯的错误是过早进入到设计细节中，然后却由于错误的假设将设计引向万劫不复的深渊。

另外一个常见错误就是没有或者是无法对架构进行评估。

故在测试架构时，需要记住问自己如下问题：

• 这个架构中的假设都有哪些？
• 架构中显式地或隐含地满足了哪些需求？
• 这样的架构中有哪些关键风险？
• 为缓和这些关键风险，可以有哪些对策？
• 和上一个迭代架构相比，这个架构在哪些方面有所提升？

另外一些推荐阅读书籍：

Software Architecture in Practice

Patterns of Enterprise Application Architecture