by:Keegan小钢http://keeganlee.me


什么是架构

一是最高层次的系统分解；二是系统中不易改变的决定！通常也将定义总结为组成派和决策派：

组成派：架构=组件+交互：软件系统的架构将系统描述为计算组件及组件之间的交互。
决策派：架构=重要决策集：软件架构是在一些重要方面所作出的决策的集合。
简而言之，软件架构的定义就是：规划、设计和构建软件的过程和结果。



架构规划

在软件设计中，架构规划就是产品需求，需求形成了对架构的约束条件，从而也对架构设计行程了边界，可以分为三大类：商业需求、功能需求、质量需求。



商业需求

为最高层次的需求，对软件架构产生限制的商业因素也比较多，在此列决一些比较常见的：


1. 上市时间：上市时间限定了系统从设计、开发、测试到上市的时间边界。


2. 成本预算：成本预算就限定了能使用的资源边界。不同架构的开发成本肯定不同，要满足更多功能需求和更多质量需求的架构成本也更高，在预算有限的情况下，只能权衡各种需求，优先满足重要程度高的需求。


3. 人力现状：100人的开发团队和10人的开发团队，软件的架构会有很大不同。


4. 与外围系统的集成：当需要与外围系统集成时，需要认真考虑集成方法，尤其是外围系统比较老的时候，集成难度可能更高。


5. 开放性：封闭的私有系统和开放式系统对架构的要求也不同，一个系统如果选择了开放，那对架构的质量要求更高，对安全性、扩展性、性能等质量属性都应该比封闭时高。


6. 目标市场：目标用户10万、100万、1000万，不同级别的目标市场，架构也是大有不同。


7. 多端支持：现在移动端普遍支持Android、iOS、Wechat，管理端通常则支持PC Web，如果管理端也要支持Android、iOS、Wechat，或者移动端和管理端还要再支持WindowsPhone、黑莓，甚至再支持VR，则需要投入更多时间和人力，架构上相应也需要做出调整。


8. 期望的系统生存期：从主观上说，谁都希望自己的系统可以生存很久，但生存期越长，意味着系统的可修改性、可扩展性、可移植性等需要更高。


9. 阶段性计划：每一个大平台系统普遍都是分阶段完成的，因此，前期阶段的架构设计时就需要考虑好重用性、扩展性、伸缩性、移植性等特性。


10. 国际化：如果走国际化路线，那架构上就要考虑好对多国语言的支持。


11. 竞争对手：产品要比竞争对手优秀，那就要在一些关键的功能或质量上超越对方，也意味着在这些方面的架构需要投入更多。


12. 法律法规：比如，对某些关键字要进行过滤屏蔽，这是天朝独有的，大家懂的。




功能需求

功能需求描述了系统应该提供的服务，包括为用户提供的服务，也包括为其他系统提供的服务。



质量需求

质量需求是三类需求中，需求层次最低的，但却是大部分架构师最关注的，常见的质量需求属性如下：性能、鲁棒性、易用性、安全性、有效性……

     像学写文章一样，在学会字、词、句之后，就应上升到段落，就应追求文章的“布局谋篇”，这就是架构。通俗地讲，软件架构设计就是软件系统的“布局谋篇”。

    人们在软件工程实践中，逐步认识到了软件架构的重要性，从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构风格、软件架构评价和软件架构的形成方法等。

    软件设计人员学习软件架构知识旨在站在较高的层面上整体地解决好软件的设计、复用、质量和维护等方面的实际问题。

   1 软件架构概述 

    软件架构是软件抽象发展到一定阶段的产物，从编程的角度，可以清晰地看到软件抽象层次和表达工具的发展历史。


	
20 世纪 60 年代是子程序的年代：出现了原始的软件架构，即子程序，并以程序间的调用为连接关系。
	
	

	
20 世纪 70 年代是模块化的年代：出现了数据流分析、实体—关系图（E-R 图）、信息隐藏等工具和方法，软件的抽象层次发展到了模块级。
	
	

	
20 世纪 80 年代是面向对象的年代：基于模块化的编程语言进一步发展成面向对象的语言，继承性地增加了一种新元素之间的连接关系。
	
	

	
20 世纪 90 年代是框架的年代：标准的基于对象的架构以框架的形式出现了。如电子数据表、文档、图形图像、音频剪辑等可互换的黑箱对象，可以相互嵌入。
	
	

	
当前（最近 10 年来）：中间件和 IT 架构作为标准平台出现，用可购买可复用的元素来构建系统，同时，基于架构的开发方法和理论不断成熟。
	
1  软件架构的定义 

    软件架构仍在不断发展中，还没有形成一个统一的、公认的定义，这里仅举出几个较权威的定义。

    定义 1：软件或计算机系统的软件架构是该系统的一个（或多个）结构，而结构由软件元素、元素的外部可见属性及它们之间的关系组成。

    定义 2：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。

    定义 3：软件架构是指一个系统的基础组织，它具体体现在：系统的构件，构件之间、构件与环境之间的关系，以及指导其设计和演化的原则上。（IEEE1471- 2000）

   前两个定义都是按“元素—结构—架构”这一抽象层次来描述的，它们的基本意义相同，其中定义 1 较通俗，因此，本章采用这一定义。该定义中的“软件元素”是指比“构件”更一般的抽象，元素的“外部可见属性”是指其他元素对该元素所做的假设，如它所提供的服务、性能特征等。

    为了更好地理解软件架构的定义，特作如下说明：

    （1）架构是对系统的抽象，它通过描述元素、元素的外部可见属性及元素之间的关系来反映这种抽象。因此，仅与内部具体实现有关的细节是不属于架构的，即定义强调元素的“外部可见”属性。

    （2）架构由多个结构组成，结构是从功能角度来描述元素之间的关系的，具体的结构传达了架构某方面的信息，但是个别结构一般不能代表大型软件架构。

    （3）任何软件都存在架构，但不一定有对该架构的具体表述文档。即架构可以独立于架构的描述而存在。如文档已过时，则该文档不能反映架构。

    （4）元素及其行为的集合构成架构的内容。体现系统由哪些元素组成，这些元素各有哪些功能（外部可见），以及这些元素间如何连接与互动。即在两个方面进行抽象：在静态方面，关注系统的大粒度（宏观）总体结构（如分层）；在动态方面，关注系统内关键行为的共同特征。

    （5）架构具有“基础”性：它通常涉及解决各类关键的重复问题的通用方案（复用性），以及系统设计中影响深远（架构敏感）的各项重要决策（一旦贯彻，更改的代价昂贵）。

    （6）架构隐含有“决策”，即架构是由架构设计师根据关键的功能和非功能性需求（质量属性及项目相关的约束）进行设计与决策的结果。不同的架构设计师设计出来的架构是不一样的，为避免架构设计师考虑不周，重大决策应经过评审。特别是架构设计师自身的水平是一种约束，不断学习和积累经验才是摆脱这种约束走向自由王国的必经之路。

    在设计软件架构时也必须考虑硬件特性和网络特性，因此，软件架构与系统架构二者间的区别其实不大。但是，在大多情况下，架构设计师在软件方面的选择性较之硬件方面，其自由度大得多。因此，使用“软件架构”这一术语，也表明了一个观点：架构设计师通常将架构的重点放在软件部分。

    将软件架构置于商业背景中进行观察，可以发现软件架构对企业非常重要。

    （1）影响架构的因素。软件系统的项目干系人（客户、用户、项目经理、程序员、测试人员、市场人员等）对软件系统有不同的要求开发组织（项目组）有不同的人员知识结构、架构设计师的素质与经验、当前的技术环境等方面都是影响架构的因素。

这些因素通过功能性需求、非功能性需求、约束条件及相互冲突的要求，影响架构设计师的决策，从而影响架构。

    （2）架构对上述诸因素具有反作用，例如，影响开发组织的结构。架构描述了系统的大粒度（宏观）总体结构，因此可以按架构进行分工，将项目组为几个工作组，从而使开发有序；影响开发组织的目标，即成功的架构为开发组织提供了新的商机，这归功于：系统的示范性、架构的可复用性及团队开发经验的提升，同时，成功的系统将影响客户对下一个系统的要求等。这种反馈机制构成了架构的商业周期。

2 软件架构的重要性 

    从技术角度看，软件架构的重要性表现为如下几方面。

    （1）项目关系人之间交流的平台。软件系统的项目关系人分别关注系统的不同特性，而这些特性都由架构所决定，因此，架构提供了一个共同语言（公共的参考点），项目关系人以此作为彼此理解、协商、达成共识或相互沟通的基础。架构分析既依赖于又促进了这个层次上的交流。

    （2）早期设计决策。从软件生命周期来看，软件架构是所开发系统的最早设计决策的体现，主要表现为：


	
架构明确了对系统实现的约束条件：架构是架构设计师对系统实现的各方面进行权衡的结果，是总体设计的体现，因此，在具体实现时必须按架构的设计进行。
	
	

	
架构影响着系统的质量属性：要保证系统的高质量，具有完美的架构是必要的（虽然不充分）。
	
	

	
架构可以用来预测系统的质量，例如，可以根据经验对该架构的质量（如性能）作定性的判断。
	
	

	
架构为维护的决策提供根据。在架构层次上能为日后的更改决策提供推理、判断的依据。一个富有生命力的架构，应该是在最有可能更改的地方有所考虑（架构的柔性），使其在此点最容易进行更改。
	
	

	
架构有助于原型开发。可以按架构构造一个骨架系统（原型），例如，在早期实现一个可执行的特例，确定潜在的性能问题。
	
	

	
借助于架构进行成本与进度的估计。
	
    （3）在较高层面上实现软件复用。软件架构作为系统的抽象模型，可以在多个系统间传递（复用），特别是比较容易地应用到具有相似质量属性和功能需求的系统中。产品线通常共享一个架构。产品线的架构是开发组织的核心资产之一，利用架构及其范例进行多系统的开发，在开发时间、成本、生产率和产品质量方面具有极大的回报。基于架构的开发强调对各元素的组合或装配。系统开发还可以使用其他组织开发的元素，例如购买商业构件。

    （4）架构对开发的指导与规范意义不容忽略。架构作为系统的总体设计，它指导后续的详细设计和编码。架构使基于模板的开发成为可能，有利于开发的规范化和一致性，减少开发与维护成本。架构可以作为培训的基础，有利于培养开发团队和培训相关人员。

   从软件开发过程来看，如果采用传统的软件开发模型（生命周期模型），则软件架构的建立应位于概要设计之前，需求分析之后。

    基于架构的软件开发模型则明确地把整个软件过程划分为架构需求、设计、文档化、评审（评估）、实现、演化等 6 个子过程。本章各节将分别对这些子过程进行讨论。

3 架构的模型

    软件架构作为一个有机的整体，可以分解成多个侧面来认识，每个侧面强调它的不同方面的特征，从而使架构设计师能整体地把握它的重点。我们可以将软件架构归纳成 5 种模型：结构模型、框架模型、动态模型、过程模型和功能模型。最常用的是结构模型和动态模型。

    （1）结构模型。这是一个最直观、最普遍的建模方法。这种方法以架构的构件、连接件和其他概念来刻画结构，并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格、性质。研究结构模型的核心是架构描述语言。

    （2）框架模型。框架模型与结构模型类似，但它不太侧重描述结构的细节而更侧重于整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应该问题的结构。

    （3）动态模型。动态模型是对结构或框架模型的补充，研究系统“大颗粒”的行为性质。例如，描述系统的重新配置或演化。动态可能指系统总体结构的配置、建立或拆除通信通道或计算的过程。

    （4）过程模型。过程模型研究构造系统的步骤和过程。因而结构是遵循某些过程脚本的结果。

    （5）功能模型。该模型认为架构由一组功能构件按层次组成，且下层向上层提供服务。它可以看作是一种特殊的框架模型。

    这 5 种模型各有所长，也许将 5 种模型有机地统一在一起，形成一个完整的模型来刻画软件架构更合适。即将软件架构视为这些模型的统一体，通过这些模型的表述（文档）来完整反映软件架构。例如，Kruchten 在 1995 年提出了一个“4+1”的视图模型。“4+1” 视图模型从 5 个不同的视角包括逻辑视图、进程视图、物理视图、开发视图和场景视图来描述软件架构。每一个视图只关心系统的一个侧面，5 个视图结合在一起才能反映系统的软件架构的全部内容。“4+1”视图模型如图 9-1 所示。



    （1）逻辑视图：主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在面向对象技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，逻辑视图设计中要注意的主要问题是要保持一个单一的、内聚的对象模型贯穿整个系统。

    （2）开发视图：也称为模块视图，主要侧重于软件模块的组织和管理。软件可通过程序库或子系统进行组织，这样，对于一个软件系统，就可以由不同的人进行开发。开发视图要考虑软件内部的需求，如软件开发的容易性、软件的重用和软件的通用性，要充分考虑由于具体开发工具的不同而带来的局限性。开发视图通过系统输入输出关系的模型图和子系统图来描述。可以在确定了软件包含的所有元素之后描述完整的开发角度，也可以在确定每个元素之前，列出开发视图原则。

    （3）进程视图：侧重于系统的运行特性，主要关注一些非功能性的需求，例如系统的性能和可用性。进程视图强调并发性、分布性、系统集成性和容错能力，以及逻辑视图中的主要抽象的进程结构。它也定义逻辑视图中的各个类的操作具体是在哪一个线程中被执行的。进程视图可以描述成多层抽象，每个级别分别关注不同的方面。

    （4）物理视图：主要考虑如何把软件映射到硬件上，它通常要考虑到解决系统拓扑结构、系统安装、通信等问题。当软件运行于不同的节点上时，各视图中的构件都直接或间接地对应于系统的不同节点上。因此，从软件到节点的映射要有较高的灵活性，当环境改变时，对系统其他视图的影响最小。

    （5）场景：可以看作是那些重要系统活动的抽象，它使四个视图有机地联系起来，从某种意义上说，场景是最重要的需求抽象。在开发架构时，它可以帮助设计者找到架构的构件和它们之间的作用关系。同时，也可以用场景来分析一个特定的视图，或描述不同视图构件间是如何相互作用的。场景可以用文本表示，也可以用图形表示。

    希赛教育专家提示：逻辑视图和开发视图描述系统的静态结构，而进程视图和物理视图描述系统的动态结构。对于不同的软件系统来说，侧重的角度也有所不同。例如，对于管理信息系统来说，比较侧重于从逻辑视图和开发视图来描述系统，而对于实时控制系统来说，则比较注重于从进程视图和物理视图来描述系统。

    

                    

                    

                    
                    
                    
企业规模的软件系统该如何设计呢？在开始写代码之前，我们需要选择一个合适的架构，这个架构将决定软件实施过程中的功能属性和质量属性。因此，了解软件设计中的不同架构模式对我们的软件设计会有较大的帮助。

什么是架构模式？根据维基百科：架构模式是针对特定软件架构场景常见问题的通用、可重用解决方案。架构模式类似于软件设计模式，但范围更广。本文将简要解释10种常见架构模式及其用法、优缺点。
分层模式（Layered pattern）
客户端-服务器模式（Client-server pattern）
主从模式（Master-slave pattern）
管道-过滤器模式（Pipe-filter pattern）
代理模式（Broker pattern）
点对点模式（Peer-to-peer pattern）
事件-总线模式（Event-bus pattern）
模型-视图-控制器模式（Model-view-controller pattern）
黑板模式（Blackboard pattern）
解释器模式（Interpreter pattern）

1. 分层模式
此模式用于可分解为子任务的结构化程序，每个子任务都位于特定的抽象层级，每一层都为上一层提供服务。一般信息系统最常见的4个层次如下。
表示层(也称为UI层)
应用层(也称为服务层)
业务逻辑层(也称为领域层)
数据访问层(也称为持久层)

应用场景：
一般的桌面应用程序
电子商务web应用程序
一般的移动App
分层模式

2. 客户端-服务器模式
这种模式由两部分组成：服务器和多个客户端。服务器将向多个客户端提供服务。客户端从服务器请求服务，服务器向这些客户端提供相关服务。此外，服务器继续侦听客户端请求。

应用场景：
电子邮件、文档共享和银行等在线应用程序。
基于IPC的应用程序
客户端-服务器模式

3.主从模式
这种模式由两部分组成：主节点和从节点。主节点将工作分配给相同的从节点，并根据从节点返回的结果计算最终结果。

应用场景：
在数据库复制中，主数据库被视为权威源数据库，从数据库与之同步。
通过总线连接到计算机系统(主驱动器和从驱动器)的外围设备。
进程内的多线程应用。
主-从模式

4.管道-过滤器模式
这种模式可用于构造生成和处理数据流的系统。每个处理步骤都包含一个过滤器组件。要处理的数据通过管道传递。这些管道可用于缓冲或同步目的。

应用场景：
编译器。连续过滤器执行词法分析、词法解析、语义分析和代码生成。
生物信息学的工作流
工具链式的应用程序
管道-过滤器模式

5. 代理模式
这种模式通过解耦组件来构造分布式系统。这些组件可以通过远程服务调用彼此交互。代理组件负责协调组件之间的通信。服务器向代理发布功能(服务和特征)。客户端向代理请求服务，然后代理将客户端重定向到合适的服务。需要注意broker，agent，proxy以及delegate的区别。

应用场景：
消息代理软件，例如：Apache ActiveMQ、Apache Kafka、RabbitMQ和JBoss消息传递。
网络传输中的代理软件。
代理模式

6. P2P模式
在这种模式中，每个组件都称为对等节点。对等节点既可以作为客户机(从其他对等节点请求服务)，也可以作为服务器(向其他对等节点提供服务)。对等节点可以充当单个客户机或服务器，也可以同时充当客户机和服务器，并且可以随着时间变化动态地更改角色。

使用场景：
文件共享网络，例如Gnutella和G2等。
多媒体协议，如P2PTV和PDTP。

P2P模式

7. 事件-总线模式
这种模式也被称为订阅发布模式，主要处理事件，有4个主要组件：事件源、事件监听者、通道和事件总线。事件源将消息发布到事件总线上的特定通道，监听者订阅特定的通道。消息发布到监听者之前订阅的通道，监听者将收到消息的通知。

使用场景：
安卓开发
通知服务
注册中心
事件-总线模式

8. 模型-视图-控制器模式
这种模式，也称为MVC模式，将一个交互应用程序分为三个部分：
模型-包含核心功能和数据
视图——向用户显示信息(可以定义多个视图)
控制器——处理来自用户的输入
这样做是为了将信息的内部表示、信息呈现给用户的方式、接受用户输入的方式分离开来。这种模式解耦组件并允许有效的代码重用。

应用场景：
一般的web应用程序架构
Django和Rails等Web框架
一般的GUI 应用程序
模型-视图-控制器模式

9. 黑板模式
这种模式对于没有确定解决方案策略的问题非常有用。黑板图案由三个主要部分组成：
黑板：一个结构化的全局内存，包含来自解决方案空间的对象
知识源：具有自己表示形式的专门化模块
控制组件：选择、配置和执行模块
所有的组件都可以到达黑板。组件可以生成添加到黑板上的新数据对象。组件在黑板上查找特定类型的数据，并通过与现有的知识源进行模式匹配找到这些数据。

应用场景：
语音识别
车辆识别及追踪
蛋白质结构识别
声纳信号的解释
黑板模式

10. 解释器模式
这种模式用于设计一个解释专用语言编写的程序组件。它主要指定如何评估每一行程序，即用特定语言编写的句子或表达式。其基本思想是语言的每个符号都有一个类。

应用场景：
数据库查询语言，如SQL。
用于描述通信协议的语言。
解释器模式

下面的表格总结了每种架构模式的优缺点。
希望觉得这篇文章有用，我们也很想听听你的想法。
                
  

1. 软件架构设计的What & Why

● 啥是软件架构（Software Architecture）？

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

软件架构设计就是从宏观上说明一套软件系统的组成与特性。

软件架构设计是一系列有层次的决策 ，比如：功能与展现的决策；技术架构的决策；自主研发还是合作；商业软件还是开源软件 。

 

 

● 为啥要进行软件架构设计？

业务需求层出不穷；软件系统越来越复杂；参与的人越来越多；共性和特殊性的问题越来越多；技术发展日异月新；……

 

2. 软件架构师

 

2.1. 软件架构师是干什么的

 

介于需求与开发的中间人    
			
良好的沟通能力
		
能够统领全局的大牛
			
良好的大局观
		
能够将需求转换为技术    
			
洞悉前沿与市场嗅觉
		
能够为软件研发提供指导   
			
 见多识广的大牛
		
需要全面思考软件系统方方面面的问题    
			
缜密地思考问题
		
能够攻关和搞定重要技术难题    
			
公司可信赖的支柱
		
 

2.2. 架构师的素质

 


			
全局思维  
			
			

			
从业务、市场，到技术实现；

			
从软件的过去、现在，到将来；

			
从外部客户，到内部研发；

			
从软件研发，到硬件部署；

			
从功能实现，到运行效率  
			
		

			
战略思维  
			
			

			
在所在行业的发展战略；

			
在业务领域的发展战略；

			
在技术方向的发展战略；

			
在潜在市场的发展战略。
			
		

			
前瞻思维  
			
			

			
市场趋势的发展动向；

			
前沿技术的发展动向；

			
竞争对手的发展动向；

			
合作伙伴的发展动向。
			
		

			
抽象思维  
			
			

			
各项业务需求：抽象成功能模块；

			
各项功能的实现：抽象成软件架构。 
			
		

			
逆向思维
			
			

			
假如不实现会怎样？

			
假如没搞定会怎样？

			
假如没有它会怎样？

			
假如被延期会怎样？
			
		
 

2.3.  架构师的分类

随着行业和社会的发展，架构师的定义和分类越来越广泛和细分，广泛和细分其实并不矛盾，如果“广泛”是x轴，“细分”是y轴，则二维坐标系x和y轴中间的任一点就是一种架构师类别。但总体来说，或目前来说，集合业界的大致认知，总结如下：

 

No.
			
分类
			
描述
		
1
			
解决方案架构师
			
与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。
		
2
			
系统架构师
			
也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范 为研发工作澄清技术细节并扫清技术障碍 。
		
3
			
平台架构师
			
这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其 实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。
		
4
			
业务架构师
			
业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。
		
5
			
网络架构师
			
过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。
		
6
			
移动架构师
			
移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。
		
7
			
前端架构师
			

			
这也是互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指Web开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/…），跨浏览器设计，性能优化等等。

			
注：这些年，在很多互联网一线大厂，Web前端和移动客户端有融合为大前端的趋势和内在需求，所以，大前端架构师的知识领域和职责范围也有不同的涵盖和侧重。
			
		
8
			
...
			
...
		
 

3.  软件需求

软件架构设计中常说需求驱动架构设计，可见需求在整个架构设计中起到了关键指引和方向的作用，如果以目标导向为原则，则需求的满足和实现就是架构设计的终极目标。

OK，在进行架构设计之前，我们先看下软件需求。

3.1.  软件需求怎么来的（软件需求的过程）

 


			
阶段
			
			

			
需求阶段
			
			

			
说明
			
			

			
什么人做什么事
			
			

			
可能产生的文档
			
		

			
客户方
			
			

			
实施方
			
			

			
客户方
			
			

			
实施方
			
		

			
1
			
			

			
业务需求
			
			

			
高纬度抽象的需求，也是来自客户的原始需求，背景描述，业务诉求和期望目标。
			
			

			
项目负责人或接口人描述需求或提供客户方需求文档。
			
			

			
销售或售前接触客户，听取和记录需求。
			
			

			
工作说明书（SOW），或邀标书
			
			

			
售前的方案建议书
			
		

			
2
			
			

			
用户需求
			
			

			
通常是在问题定义的基础上进行用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。
			
			

			
项目负责人或接口人接受访谈和调研。
			
			

			
需求分析师或项目经理等进行需求调研。
			
			

			
 
			
			

			
调研计划、用户需求调研提问库、调研日志、用户需求说明书
			
		

			
3
			
			

			
软件需求
			
			

			
从系统实现的角度描述的需求。开发人员（设计和分析人员）在业务需求、用户需求的基础上形成的。
			
			

			
 
			
			

			
需求分析师或项目经理、架构师等讨论和细化需求，编写需求文档
			
			

			
 
			
			

			
SRS（Software Requirement Specification）软件需求规格说明书
			
		
 

3.2.  软件需求的分类：

 





另外，也有McCall软件质量模型：



注：在架构设计中，对非功能性需求的重视程度，也会影响架构设计的好与劣；但也要平衡过渡设计和适可而止的关系。

 

4.  软件架构的过程

业界软件架构设计的方法论很多，各有各自的应用场景和特点，下文结合ADMEMS（Architecture Design Method has been Extended to Method System）架构设计方法论说明软件架构的过程：

 


			
架构阶段
			
			

			
目标
			
			

			
方式方法
			
			

			
现实工作场景
			
		

			
预架构阶段
			
			

			
全面理解需求；需求结构化，摒弃“需求列表”，建立二维需求观（ADMEMS矩阵）。
			
			

			
使用ADMEMS矩阵方法，捋清需求间关系和发现衍生需求。
			
			

			
1、与人：与项目经理、需求分析师等内部需求人员了解需求；与客户了解需求（不建议架构师做需求分析师角色）。

			2、与物：了解《需求规格说明书》等需求文档。"

			3、对需求有什么问题，反馈给售前或销售，可能会参与拜访客户或电话会议。

			4、销售或售前有时会要求提供一个大致的工作量，以便他们初步评估项目可行性。
			
		

			
概念架构
			
			

			
高层组件及其关系
			
			

			
1、初步设计，基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计（不是必须）。

			2、高层分割，将复杂系统切分为多个二级系统或多个子系统。

			3、考虑非功能需求，采用ADMEMS推荐的目标-场景-决策表。
			
			

			
1、参与内部讨论：项目可行性分析、讨论，从需求、技术、人力、风险等角度提供建议。

			2、项目投标准备：参与投标团队的技术方案编写，编写系统架构章节，解决招标书上技术问题的问答。

			3、参与项目讲标：作为讲标团队成员参与项目讲标，负责技术问答环节的应对。
			
		

			
细化架构
			
			

			
 
			
			

			
5视图法
			
			

			
在项目概要设计阶段，进行架构设计，制定规范和约定，为详细设计提供指导。
			
		

			
实现
			
			

			
详细设计

			编码实现
			
			

			
架构设计形成详细设计文档
			
			

			
在项目实现阶段，对开发人员提供规范指引和技术支持。
			
		
 

注：架构设计的过程和内容的不是固定不变的，现实中，比如售前提供解决方案中，很多时候需要架构师提供细化架构中才会深思的逻辑架构、物理架构等，这时候，架构师就需要有螺旋思维和跳跃思维的方式，就像武功中，招式是死的，人是活的，要学会灵活运用。

 

 

5.  软件架构设计的方式方法

 

5.1.  多视图法



多视图方法是业界广泛认同的一种架构设计思路，包括：

● SEI的3视图法：

模块视图、组件-连接器视图、分配视图。

● 西门子的4视图法：

概念视图、模块视图、代码视图、执行视图。

● RUP的4+1视图法：

用例视图、逻辑视图、开发视图、进程视图、物理视图。

● 联邦企业架构框架：

技术架构视图、信息架构视图、应用架构视图、业务架构视图。

● ……

5.2.  5视图法



5视图法分析的意义：

● 全面分析软件系统方方面面的问题

● 尽早地发现和排除项目风险与不确定因素

● 从不同角度去展现要设计的软件系统

● 为项目进行中不同的干系人提供指导：

    -- 逻辑架构描述系统功能，并指导系统测试

    -- 开发架构规范软件的层次及代码风格

    -- 数据架构指导数据库的设计

    -- 运行架构定义了一些关键过程的设计

    -- 物理架构明确软件如何部署与实施

5.3.  5视图法设计步骤

两种观念：

 


			
观念
			
			

			
设计步骤
			
		

			
观念一
			
			

			
顺序进行：

			
1、逻辑架构。

			
2、开发架构

			
3、数据架构

			
4、运行架构

			
5、物理架构
			
		

			
观念二
			
			

			
5个视图是穿插进行设计的，对复杂系统而言，根本不可能将逻辑视图设计完了后再考虑其它视图。
			
		

			
笔者观念
			
			

			
观念一和观念二的情况在现实状况中都可能存在，要根据具体情况具体分析，但总体而言，5视图穿插进行思考更有利于思考的全局性和完整性。
			
		
 

5.4.  如何进行5视图法的设计

 

以下5视图表格中的工具和方法每个架构师或略有差异，以下仅为参考。

5.4.1.  逻辑架构

逻辑架构的重点是考虑软件功能性需求。

 


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
系统功能划分为几个子系统与功能模块？
			
			

			
系统功能树
			
			

			
树型结构图
			
			

			
 
			
		

			
2
			
			

			
向什么用户提供什么样的功能？
			
			

			
用例模型
			
			

			
UML用例图
			
			

			
体现用户和行为
			
		

			
3
			
			

			
每个功能都是怎样的操作流程与分支？
			
			

			
用例描述
			
			

			
用例描述表

			
 
			
			

			
含输入输出、事件流分析；

			
不要有界面描述
			
		

			
UML活动图
			
			

			
进行业务流程分析，包括泳道图
			
		

			
4
			
			

			
如何通过界面与用户交互？怎样交互？
			
			

			
鲁棒分析
			
			

			
鲁棒图
			
			

			
通过对“用例描述表”进行原文分析法拣出名词和动词
			
		

			
5
			
			

			
应当设计哪些类与界面？怎样设计？
			
			

			
领域模型
			
			

			
UML类图
			
			

			
 
			
		

			
6
			
			

			
与哪些外部系统接口？怎样接口？
			
			

			
接口描述
			
			

			
UML类图
			
			

			
 
			
		
 

5.4.2.  开发架构

 

开发架构重点关注的是开发编码实现方面的问题。

 


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
分层结构设计
			
			

			
分层架构图（开发架构图）
			
			

			
各种绘图工具
			
			

			
好的分层结构支持自动化测试
			
		

			
2
			
			

			
开发技术选项
			
			

			
开发语言

			
开发框架

			
开发工具
			
			

			
 
			
			

			
考虑商用产品、开源框架、自研框架
			
		

			
3
			
			

			
模块划分
			
			

			
源码工程；Project目录结构；

			
分包(分库)
			
			

			
 
			
			

			
 
			
		

			
4
			
			

			
开发规范
			
			

			
开发/编码规范文档；
			
			

			
 
			
			

			
 
			
		

			
5
			
			

			
软件质量属性
			
			

			
分析和决策结果
			
			

			
 
			
			

			
考虑运行期和开发期软件质量属性，并权衡利弊进行决策。
			
		
 

5.4.3.  数据架构

 

数据架构不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
数据是集中还是分布存储的？如何考虑分布式存储？
			
			

			
数据架构图
			
			

			
 
			
			

			
 
			
		

			
2
			
			

			
领域模型到数据库表的转换？表结构关系的设计？
			
			

			
逻辑模型

			
物理模型

			
ER图
			
			

			
Power Designer

			
Visio
			
			

			
 
			
		

			
3
			
			

			
实体如何设计？充血模型和贫血模型？
			
			

			
UML类图
			
			

			
 
			
			

			
 
			
		

			
4
			
			

			
使用什么数据库？关系型还是非关系型？
			
			

			
选型结果
			
			

			
 
			
			

			
 
			
		
 

 

 


			
关系型数据库
			
			

			
非关系型数据库（NoSQL）
			
		

			
Oracle（首次发行：1980年）

			
MySQL（首次发行：1995）

			
MS SQL Server（首次发行：1989）

			
PostgreSQL（首次发行：1989）

			
IBM DB2（首次发行：1983）

			
Microsoft Access（首次发行：1992）

			
Sybase ASE（首次发行：1987）

			
SQLite（首次发行：2000）

			
…… 
			
			

			
MongoDB（首次发行：2009）

			
Cassandra（首次发行：2008）

			
Apache CouchDB

			
Hbase

			
Redis

			
db4o

			
BaseX

			
…… 
			
		
 

 

 

5.4.4.  运行架构

 

运行架构关注的不再是全局而是局部，着重关注那些关键点与难点，常常需要技术攻关与预研。主要考虑控制流、通讯机制、资源争用、锁机制、同步异步、并发、串行，同时也要考虑质量属性。


			
No.
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
运行：同步vs.异步；并发vs.串行
			
			

			
考虑开发架构中代码的实现。
			
			

			
 
			
			

			
 
			
		

			
2
			
			

			
交互：对象间交互；状态转换
			
			

			
考虑开发架构的合理性，到类、到接口、到代码。
			
			

			
 
			
			

			
 
			
		

			
3
			
			

			
质量：安全；可靠；可伸缩
			
			

			
考虑开发架构的合理性
			
			

			
 
			
			

			
 
			
		

			
4
			
			

			
性能：响应时间；吞吐量
			
			

			
估算：

			
在线人数、并发人数；

			
每秒事务量；

			
响应时间。
			
			

			
 
			
			

			
 
			
		
 

 

 

5.4.5.  物理架构

 

物理架构主要考虑硬件选择和拓扑结构，软件到硬件的映射，软硬件的相互影响。


			
 
			
			

			
考虑的方面
			
			

			
产出物
			
			

			
工具
			
			

			
说明
			
		

			
1
			
			

			
网络方面：网络拓扑；网络设备；安全机制
			
			

			
拓扑图

			
安全规范
			
			

			
 
			
			

			
 
			
		

			
2
			
			

			
性能方面：可靠性、可伸缩性
			
			

			
需要什么样设备性能
			
			

			
 
			
			

			
 
			
		

			
3
			
			

			
部署方面：集中式还是分布式；组件部署
			
			

			
部署图

			
 
			
			

			
 
			
			

			
 
			
		
 

 

 

6.  一个思考，谁驱动了架构设计？

 

需求驱动了架构设计？

质量属性了驱动了架构设计（ADD）？

领域驱动了架构设计（DDD）？

风险驱动了架构设计？

质疑驱动了架构设计？

……

到底是谁驱动了架构设计？我们以船舶设计建造为例，来看这些问题：


			
目标和结果
			
			

			
问题
			
			

			
回答
			
			

			
小结
			
		

			
设计和制造一艘远洋货轮，能经历数月海上颠簸和长途跋涉，并保证货物的安全和完整，最后能顺利抵达目标港口。
			
			

			
我们为什么要设计和制造这样的大船？
			
			

			
市场有这个需求；

			
获利很丰厚；

			
解决就业；

			
……
			
			

			
不管是外部需求还是内部的需求，都是需求。不正是需求驱动吗？
			
		

			
如何保证货船能长途航行并经受波涛和风雨？
			
			

			
船要造的结实；
			
			

			
鲁棒性
			
			

			
这些不正是质量属性驱动设计吗？
			
		

			
引擎设计的强劲；
			
			

			
性能
			
		

			
船的燃料充足；
			
			

			
持续可用性
			
		

			
装备卫星电话、GPS、雷达等设备
			
			

			
互操作性
			
		

			
货物和人员要安全
			
			

			
安全性
			
		

			
船舶设计师怎么设计这样的船舶？
			
			

			
现在都会通过计算机进行船舶的CAD和3D模型设计。
			
			

			
是不是佷似领域模型驱动了设计？
			
		

			
造船一定有很多风险吧？
			
			

			
那是，比如订货方客户有时提出改装船舶的意见（需求变化的风险）；有时某些工艺成品率不稳定（质量风险）；等等。
			
			

			
所有可能的风险点在设计时都要考虑到，做好预案，才能保证架构设计的可行性和灵活性，风险驱动了架构设计。
			
		

			
上面怎么提了那么多问题，其实还有很多问题，比如……
			
			

			
嗯，你现在有不少疑问了。
			
			

			
不断的质疑架构设计中可能存在各种问题，有质疑才有思考，才有解决方案，从而推动架构设计的不断完善。
			
		
 

总结：

 

以上几个方面都能驱动架构设计，并不是零和的规则，而是一个立方体从不同方向看的问题。以上方面有些是指导思想，有些是行动方式，有的兼而有之，阐述方式看似不同，终极目标还是造出大船（实现需求），造出好船（质量属性），怎么造（领域模型），造的顺利（风险控制），挑不出毛病（架构师自己先质疑问题并解决了）。

 

 

7.  软件架构设计的误区

 

● 高开高走落不到实处

● 理想与现实需要折中

● 遗漏关键性约束与非功能需求

● 为虚无的未来埋单而过度设计

● 过早做出关键性决策

● 客户说啥就是啥成为酱油哥

● 埋头干活儿缺乏前瞻性

● 架构设计还要考虑系统可测性

● 架构设计不要企图一步到位

 

 

8.  部分参考资料

 

温昱的《一线架构师实践指南》

 

注：有网友问：这是自己总结，还是看书总结呢？

我的回答是：看书是学习的过程，概念是不变真理，架构是工作内容，经验是多年积累，教训是切身体会，内容是自己总结，文章是自己码字，^_^。