硬件强大了，但数据量在增加，计算复杂度也在提高，所以增加硬件未必能解决问题。

相反，计算与计算往往不是孤立的，它们之间存在着复杂的“生产者-消费者”关系，所以软件的实际服务能力不仅受到“硬件资源”的制约，也受到了“数据短缺”和“数据争用”的制约。每个架构师都应该懂得：

多视图方法中，物理架构视图着重考虑运行软件的计算机、网络、硬件设施等情况，还包括如何将软件包部署（如果是嵌入系统则是烧写）到这些硬件资源上，以及它们运行时的配置情况。另外，物理架构还要考虑软件系统和包括硬件在内的整个IT系统之间是如何相互影响的，由于一部分运行质量属性需要硬件或网络的支持，所以物理架构必须关注如何配置硬件和网络来满足软件系统的可靠性、可伸缩性、持续可用性、性能、安全性等方面要求。

物理架构设计主要有3项任务：

相对逻辑架构设计而言，物理架构视图的设计是不是就乏善可陈呢？不，一般架构师最缺的就是物理架构的设计思路。

从设计结果层面，决策无非围绕物理节点、网络、软件单元、数据单元等内容展开。

但是，思维当中经历了哪些思考、判断和权衡呢？

从最终目标层面，决策要兼顾多方涉众的不同利益，可从“攻”与“守”两个方面理解：

从思维要点层面，“开销”和“争用”是核心。架构师正是通过“降低开销”、“避免争用”来实现高性能、高伸缩性等最终目标。

这样，我们了解了物理架构设计的理性思维框架。

如果系统中，并不准备引入任何并行或并发处理，并且系统也没有基于SDK、API等基础软件进行定制开发，那就不需要设计运行架构的设计--这相当于将5视图方法裁剪为4个视图。

相反，很多系统为了应对复杂的业务逻辑或复杂的互操作逻辑（含硬件交互），或者为了优化关键资源使用效率，而必须借助多条控制流或并发执行时，就需要设计运行架构。

根据具体情况不同，运行架构设计可能包括下列工作内容

控制流（Control Flow）是一个在处理机上顺序执行的动作系列。确定引入哪些控制流，并没有固定不变的套路，但有几点考虑是必不可少：

一旦系统中存在不止一条控制流，就产生了附近的工作量，例如控制流的创建、控制流的销毁、建立共享内存或消息等不同控制流之间的通信机制。

控制流图显示了系统中不同控制流之间的关系。控制流的起点是“主动单元”，它会调用其他“被动单元”......如此层层调用，就形成了一个控制流。明确了系统中所有的主动单元，就抓住了每个控制流的源头，从而可以把并发执行的所有控制流梳理清楚。

运行架构设计的工作看似多而杂，但其实只要把握“控制流图”，就能提供提纲擎领的开展其他相关设计。

在实践中，最常用于实现控制流的手段有3种。

例如，下图所示的多条控制流设计用到了线程，以及中断服务程序的技术（背景为设备调试系统）:

以前，很多企业不重视架构：现在，重视架构的企业远比不重视架构的企业多。但是，许多企业发现一个棘手的问题：开发人员不按照架构进行详细设计和编程。

大家一起来思考下面的问题。

此题的答案是：A、B、D

一句话，架构师在抱怨研发管理、职位权力之前，还需自查！

首先，最基本的一点，架构师必须重视开发架构视图，并行开发所需的“程序单元”、“源码目录结构”等概念，是不同程序团队开展具体工作的基础。如果程序员们总不能从架构中农看到上述内容，就会认为架构是一类“高来高去”的概念，自然不会有积极态度。（A 正确）

另外，能不能更具体的“定义”架构设计应该达到的程度呢？答案是：能支持并行的详细设计。所以，架构师投标成功之后，切不可将投标中演示的“市场架构”直接作为架构设计的全部。因为这意味着很多影响全局的设计决策被“漏”到了后边，最终到大规模并行开发阶段才发现，造成“程序员碰头临时决定”的情况大量出现，必然导致软件质量下降甚至项目失败。（B正确）

当然，有能力的架构师，再加上聪明的管理策略就更好。既然每个程序经理都深入理解架构，那何不让他们参与到架构实践的工作中来，免去了大量“单纯的架构交流”的工作量。更不必说，“了解产生爱”（程序人员不了解你的架构又如何喜欢你的架构）和“成就感”的心理因素会让程序经理支持架构设计方案。（D正确）

一般而言，开发架构的设计应完成下列工作。

值得说明的是，此处的“Project”不是指Project Manager管的“项目”，而是指IDE等开发环境所支持的“Develop Studio Project”类似的概念。

广大软件企业系统通过为客户提供合格的软件系统达到获取利润的目标，于是，他们非常关注“可重用性”。但从重用的现实效果来看，显然远远不能令人满意......

在很多企业（包括很多程序员本人）都声称“我们很重视重用”的背景之下，下面这个问题尤其值得深思：

事出有因。以下两个问题是根源所在。

所以，请记住这个公式：

不要只关心重用的次数，为了重用而重用，而是时刻关注节省成本--这才是重用的目标所在。于是，当我们想到“维护是最昂贵的环境”，当我们看到经典书籍显示维护成本占总成不的67%之巨时，会作何感想？

图片来源：App Maintenance Cost Can Be Three Times Higher than Development Cost

想必你的结论和我一样：为了从根本上降低维护成本，重用测试是关键。这意味着大粒度重用。也就是，在重用这些代码时，并不对代码任何修改--它们的测试也被重用了。具体而言，Framework、Service、Server、平台、中间件都算大粒度重用技术，它们已经成为，并继续是重用技术的未来方向。

最后，评论有一个有趣的现象：很多架构师一提到重用首先会想到设计模式。那么，设计moose在重用技术中占据了什么位置呢？先看看Lethbridge在《面向对象软件工程》中的一段话：

设计模式属于上面的“专家经验”和“标准的设计”级别的重用策略--《面向对象软件工程》明白无误的告诉我们：这种“重用类型”节省的潜在工作量是比较有限的。

为什么呢？下图说明了“设计模式”和“框架”等技术在重用方面区别的根源：前者通用程度高和编程语言无关，后者实现程度高代码已提供。没有代码--无论是系统软件或平台内部的实现，还是库或者框架这种外部实现--就没有办法重用测试，就会面临较多的Bug而花费较高的维护成本。

继续PASS系统的架构设计。

回顾之前第9章的“ 9.4. 贯穿案例 ”部分，你可能会有疑问：物理架构不是在概念架构时已设计吗？为什么又要设计？

所以，下面首先分析医学：概念架构设计和5视图方法是什么关系。

总之，概念架构与5视图方法的区别及联系可以用两句话概况。

至此，我们明白了PASS系统的物理架构设计已经在概念架构时进行了一部分，进一步明确不同物理层(Tier)之间的协议类型、每一物理层是否需要部署集群、软件单元（例如Layer）到物理节点的映射关系等物理架构设计的内容即可。

非功能需求的支持不可能是“速决战”。

对细化架构设计阶段而言，这意味着非功能目标的考虑时刻伴随着5视图的设计。例如，为了支持“用药规则的实时更新”这一功能，会涉及不同视图的考虑，中间穿插着无数次“质疑-分析-决策”的“微过程”。

我们通过“目标-场景-决策表”来“重放”了我们的思维过程。

对大系统而言，开发架构设计中的“Project划分”是不可或缺的，因为即使一个Project可以“胜任”（例如没有多节点因素），我们也不推荐这样做。更何况，将一个系统组织成多个Project的形式进行开发，可以方便的单独控制每一个Project源码的保密性--这是很多软件企业都关心的一个问题。

我们将PASS系统划分为5个Project，分别为：

确定了PASS系统划分成哪几个Project，就可以进一步确定每个Project所包含的程序单元、这些程序单元的依赖关系、源码的基本结构等问题，并为每个Project选定具体的技术及所用到的Framework。

最终，架构设计应进行到什么程度呢？

架构设计的程度应考虑3方面的问题。