八、软考·系统架构师——架构设计

系列文章

一、程序员进阶架构师的基础知识【计算机基础】
二、程序员进阶架构师的基础知识【操作系统】
三、程序员进阶架构师的基础知识【计算机网络基础】
四、程序员进阶架构师的专业知识【软件工程基础】
五、程序员进阶架构师的专业知识【UML建模工具】
六、程序员进阶架构师的专业知识【系统分析】
七、程序员进阶架构师的专业知识【系统设计】
八、程序员进阶架构师的专业知识【架构设计】
九、程序员进阶架构师的专业知识【架构质量及评估】
十、程序员进阶架构师的专业知识【软件测试及维护】

前言

软件架构设计主要关注软件构件的结构、属性、交互作用，并通过多种视图全面描述特定系统的架构。何为构件？构件可以小到一个类，也可以是一个系统、中间件。多种视图可以使不同角色的人员站在不同角度了解系统。本文围绕着架构设计的生命周期、架构的设计方法以及架构的风格以及架构的质量属性等几个方面进行说明，描述架构设计的工作以及如何设计出高质量的架构。

生命周期

《软件工程》中有写到软件开发的生命周期，架构设计同样有生命周期，他两之间是相互交叉、包容的,通常架构设计处于分析和详细设计中间，也就是说对整个系统的需求以及整体结构确定后就可以对系统的架构进行设计。软件架构设计的生命周期：

1. 需求分析：根据需求模型构建架构模型，保证模型转移的可追踪性。
2. 设计阶段：分析系统的组成要素与相互关系，通过体系结构描述语言ADL和4+1视图的描述架构。
3. 实现阶段：制定项目的组织结构，实现配置化管理，通过置顶向下逐步求精的方式完成构件开发。
4. 构件组装阶段：根据系统的整体逻辑组装构件，构建完整的系统。
5. 部署阶段：部署应用。
6. 后开发阶段：演化、迭代、复用。

4+1视图

体系结构描述语言ADL目前常用的就是UML建模语言。 "4+1"视图从5个不同的视角包括逻辑视图、进程视图、物理视图、 开发视图和场景视图来描述系统架构。每一个视图只关心系统的一个侧面，只有5个视图结合在一起才能反映系统架构的全部内容。

• 场景（用例）视图： 从外部世界的角度描述系统的功能。 所有其他视图都依靠该来指导它们，这就是将模型称为4+1的原因。该视图通常包含用例图，描述和概述图。
• 逻辑视图：描述系统各部分的抽象描述，主要支持功能性需求。用于系统的组成部分以及各组成部分之间的交互方式。该视图通常包含类图，对象图，状态图和协作图。
• 进程（过程）视图：描述系统中的进程或活动。细化到某个构件中，如果存在业务流程需要被可视化时，使用此视图描述。进程架构需要考虑一些非功能性需求，如可用性、性能。该视图通常包含活动图。
• 开发视图：描述系统的各部分如何被组织为模块和组件。该视图通常包含包图和组件图。
• 物理视图：描述如何将逻辑视图、进程（过程）视图、开发视图中所展示的抽象部分如何映射到最终部署的系统中。该视图通常包含部署图。

基于架构的软件设计方法ABSD

ABSD方法由构成体系结构的（商业、质量）非功能需求和功能需求驱动的。ABSD方法采用视角与视图来描述软件架构，采用用例来描述功能需求，采用质量场景来描述质量需求。
使用ABSD方法三个基础：

• 第一个基础是功能的分解。在功能分解中，ABSD方法使用模块的内聚和耦合技术。
• 第二个基础是通过选择架构风格来实现质量和商业需求。
• 第三个基础是软件模板的使用。设计的过程中可以采用之前的软件模板进行复用。
  每个方法论都有对应的开发模型，比如结构化开发对应瀑布模型，面向对象开发方法对应喷泉模型。ABSD方法的开发模型是ABSDM，ABSDM把整个基于软件体系结构的过程分为体系结构需求、设计、文档化、复审、演化等6个子过程，得到细化，知道能产生构件和类。模型如下：
  
  其中需求包括功能性需求和非功能性需求；体系结构文档化过程的主要输出结果是体系结构规格说明和测试体系结构需求的质量设计说明书这两个文档；体系结构复审是一个迭代过程。目的是标识出潜在的风险尽早发现体系结构设计中的缺陷和错误。在一个主版本的软件体系结构设计之后，要安排一次由外部人员(用户代表和领域专家)参加的复审。下图为具体过程：
  

特定领域软件体系架构DSSA

特定领域软件架构是在一个特定应用领域中，为一组应用提供组织结构参考的标准软件体系结构。
DSSA通常是一个具有三个层次的系统模型，包括领域开发环境(领域架构师)、领域特定应用开发环境(应用工程师)和应用执行环境(操作员)。其基本活动为：

• 领域分析：获得领域模型。领域模型描述领域中系统之间共同的需求，即领域需求。
• 领域设计：获得特定领域软件架构。DSSA描述领域模型中表示需求的解决方案。
• 领域实现：依据领域模型和DSSA开发组织可重用信息，并对基础软件架构进行实现。

其中参与角色有:领域专家、领域分析人员、领域设计人员、领域实现人员。

架构风格

软件体系结构风格是描述某一特定应用领域中系统组织方式的惯用模式。从建筑角度来说有中式风格、英式风格、哥特式风格等，软件角度同样如此，同一领域的软件在体系结构中也有多种风格。
软件体系结构风格中定义了一个系统家族，每个风格有一个词汇表和一组约束。词汇表中包含一些构件和连接件类型。约束指出系统是如何将这些构件和连接件组合起来的。
体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。

数据流风格

所有的数据按照流的形式在执行过程中前进，不存在结构的反复和重构，在流动过程中，数据经过序列间的数据处理组件进行处理，然后将处理结果向后传送，最后进行输出。就像工厂中的汽车流水线一样，汽车零部件在流水线的各个节点上被加工，最终输出所需要的结果(一部完整的汽车)。
数据流动方式：

• 数据自由流动：构件之间随意传输数据，这样的流动方式可能会出现死循环。
• 数据近线性流动：构件之间只向后传输数据。
• 数据有限循环流动：构件之间传输数据可以存在2、3次的反复流动。
  

数据流风格中包含两种风格：

• 批处理：批处理风格的每一步处理都是独立的，并且每一步是顺序执行的。只有当前一步处理完，后一步处理才能开始。数据必须是完整的，以整体的方式传递。如日志分析、计费程序等。
• 管道过滤器：与批处理一样都是顺序执行。每个构件都有一组输入和输出，前一个输出是后一个输入，增量传送。如传统的编译器、 UNIX管道等。下图为编译器执行
  

批处理	管道过滤器
整体数据传送	增量
构件粒度大	构件粒度小
延迟高、实时性差	实时性好
无并发	可并发

调用返回风格

系统中采用了调用与返回机制，开发中用到最多的风格。调用返回风格中包含三种风格：

• 主程序/子程序：主程序发起调用，子程序返回结果，主程序的正确性取决于它调用的子程序的正确性。如开发语言。
• 面向对象：数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作中。对象具有封装性，一个对象的改变不会影响其他对象。如面向对象开发语言。
• 分层：只能见到与自己邻接的层，每层为上一层提供服务，使用下一层的服务，修改某一层，最多影响其相邻的上下两层(通常只能影响上层)。上层必须知道下层的身份，不能调整层次之间的顺序。如TCP/IP协议，B/S、 C/S、MVC等。

独立构件风格

独立构件风格主要包括:进程通信和事件驱动。

• 进程通信：进程间消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。
• 事件驱动：当某个事件被触发时，系统自动调用注册在这个事件中的所有过程。这是一种隐式调用的方式，优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便，其缺点是构件放弃了对系统计算的控制。如断点调试、新闻，公众号等的订阅信息。
  
  事件驱动特点：

特点	描述
分离的交互	事件发布者并不会意识到事件订阅者的存在
一对多通信	采用发布/订阅消息传递，一个特定时间可以影响多个订阅者
基于事件的触发器	由事件触发过程调用
异步	支持异步操作

虚拟机风格

虚拟机风格主要有解释器风格和规则系统风格两种

• 解释器：解释器通常包括一个完成解释工作的解释引擎、一个将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个源代码被解释执行进度的数据结构。缺点是执行效率比较低。如JVM。传统编译器会产生可执行文件而解释器不会。
  

• 规则系统：基于规则的系统包括规则集、规则解释器、规则选择器和工作内存。一般用在人工智能领域和DSS中。
  

仓库风格

仓库风格包含一个数据仓库和若干其他构件，数据仓库位于该体系结构的中心，其他构件访问该数据仓库并对其数据进行增删改等操作。主要有数据库系统、黑板和超文本系统三种风格。

• 数据库系统：构件分为中央共享数据源、独立处理单元。构件控制中央共享数据。如IDE集成开发环境。

• 黑板：黑板系统包括知识源、黑板和控制三个部分。

  • 知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板。
  • 黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介;
  • 知识源响应是通过黑板状态的变化来控制的。
    

  黑板系统通常应用在对于解决问题没有确定性算法的软件中。如语音识别，信号处理。

• 超文本系统：超文本系统通常应用在静态页面中。

C2风格

C2体系结构风格属于一个分层结构，通过连接件绑定在一起按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：

1. 系统中的构件和连接件都有一个顶部和一个底部。
2. 构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部。而构件与构件之间的直接连接是不允许的。
3. —个连接件可以和任意数目的其他构件和连接件连接。
4. 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
   

二层/三层架构风格

C/S架构

二层 C/S 架构由客户机和数据库服务器组成，客户机直接与数据库服务器交互。主要缺点有：

1. 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
2. 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。

与二层C/S架构相比，在三层 C/S 架构中增加了应用服务器，可以使整个应用逻辑驻留在应用服务器上，而只有表现层在客户机上。三层C/S 结构将应用功能分成表示层、功能层和数据层三个部分。

• 表示层是应用的用户接口部分，它担负着用户与应用间的对话功能。它用于检查用户从键盘等输入的数据，并显示应用输出的数据。在变更用户接口时，只需改写显示控制和数据检查程序，而不影响其他两层。检查的内容也只限于数据的形式和取值的范围，不包括有关业务本身的处理逻辑。
• 功能层相当于应用的本体，它是将具体的业务处理逻辑编入程序中。而处理所需的数据则要从表示层或数据层取得。表示层和功能层之间的数据交往要尽可能简洁。
• 数据层就是数据库管理系统，负责管理对数据库数据的读写。数据库管理系统必须能迅速执行大量数据的更新和检索。因此，一般从功能层传送到数据层的要求大都使用 SQL 语言。

与二层C/S架构相比，三层 C/S 架构具有以下优点：

1. 允许合理的划分三层的功能，在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
2. 允许更灵活的、有效的选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于清晰的三层架构上，并且这些平台可以具有良好的升级性和开放性。
3. 系统的各层可以并行开发并且可以选择适合各自的开发语言，使之能并行高效的开发达到较高的性价比，对每一层处理逻辑的开发和维护也会更容易些。
4. 利用功能层可以隔开表示层和数据层，未授权的表示层用户难以绕过功能层利用数据库工具或非法的黑客手段访问数据层，为严格的安全管理奠定了基础。

B/S架构

B/S架构是三层 C/S架构的一种实现方式，其具体结构为“浏览器/web服务器/数据库服务器”。其特点为：

1. B/S 架构主要是利用不断成熟的 WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本。
2. 在 B/S 模式的计算机应用系统中，应用(程序)在一定程度上具有集中特征。在 B/S 结构中，除了数据库服务器外，应用程序以网页形式存放于 Web 服务器上，用户运行某个应用程序时只需在客户端上的浏览器中键入相应的网址，调用 Web 服务器上的应用程序并对数据库进行操作完成相应的数据处理工作，最后将结果通过浏览器显示给用户。
3. 基于 B/S 架构的软件，系统安装、修改和维护全在服务器端解决。用户在使用系统时，仅需要一个浏览器就可运行全部的模块，真正达到了“零客户端”的功能，很容易在运行时自动升级。

多层架构优缺点

优点	缺点
开发人员可以只关注整个结构中的其中某一层	严格的分层可能导致性能问题，具体取决于层数
可以很容易的用新的实现来替换原有层次的实现	建立清晰的分层架构并不总是很容易
可以降低层与层之间的依赖
有利于标准化
利于各层逻辑的复用
扩展性强。不同层负责不同的层面
安全性高。用户端只能通过逻辑层来访问数据层，减少了入口点，把很多危险的系统功能都屏蔽了
项目结构更清楚，分工更明确，有利于后期的维护和升级

SOA架构

SOA是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使在系统中构建的服务可以有统一和通用的方式进行交互。
服务总线ESB是SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合，其功能如下：

• 描述服务的元数据和服务注册管理。
• 在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等。
• 发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力包括对安全的支持、服务质量保证、可管理性和负载平衡等。

SOA架构中的关键技术:

• SOAP：简单对象访问协议，Simple Object Access Protocol。
• WSDL：Web服务描述语言，Web Services Description Language。
• UDDI：统一描述、发现和集成，Universal Description Discovery and Integration。

WSDL用来描述服务，UDDI用来注册和查找服务，而SOAP作为传输层，用来在消费者和服务者之间传送消息，一个消费者可以在UDDI注 册表查找服务，取得服务的WSDL描述，然后通过SOAP来调用该服务。

微服务架构

微服务是一种架构风格，将单体应用划分成一组小的服务，服务之间相互协作实现业务功能，每个服务运行在独立的进程中，服务间采用轻量级的通信机制协作(通常是HTTP/JSON)，每个服务围绕业务能力进行构建，并且 能够通过自动化机制独立地部署。 微服务中很少有集中式的服务管理，每个服务可以使用不同的语言开发，使 用不同的存储技术。

微服务中的基本组件：

• 服务描述。常用的服务描述方式包括RESTful API、XML配置和IDL文件三种。
• 注册中心。服务者发布服务，消费者订阅服务。返回服务列表、通知变更。
• 服务框架。通信协议、数据传输方式等。
• 服务监控。指标收集(请求耗时、每秒服务请求量等)、数据展示。
• 服务追踪。追踪服务经过的链路，以便进行追踪与故障定位。
• 服务治理。节点管理、负载均衡、制定服务路由规则、服务容错等。

微服务优缺点

优点	缺点
每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。	很难在不采用分布式事务的情况下跨服务实现功能。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。	测试工作更加困难。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。	跨服务实现要求团队之间的紧密协作。
微服务能使用不同的语言开发。	部署复杂。
去中心化。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。