Software Architecture（软件体系结构）简称SA

1993年D Garlan, M Shaw

D Garlan, M Shaw提出软件架构包括 component（组件）、connector（连接件）和constraint（约束**）三大要素

1992年元素（D E.Perry与A L.Wolf）

处理元素（processing elements）负责对数据进行加工

数 据元素（data elements）是被加工的信息

连接元素（connecting elements）把体系结构的不同部分组合连接起来

2011年ISO/IEC/IEEE标准

ISO/IEC/IEEE标准中定义软件架构是某一系统的基本组织结构， 其内容包括软件构件，构件间的联系，构件与其环境间的联系，以及指导上述内 容设计与演化的原理。

1999年Booch，Rumbaugh and Jacobson

Booch，Rumbaugh and Jacobson从另一个角度对软件架构的概 念进行了全新的诠释，认为架构是一系列重要决策的集合。

Anton, 2005软件架构是架构层次上所有 设计决策的集合体

Kruchten, 2006软件体系结构是设计决策+设计（设计决策的推理过程）

基于D Garlan, M Shaw的定义：软件体系结构 = 组件 + 连接件 + 约束

组件：具有某种功能的可重用的软件模块单元，表示了系统中主要的计算单元和数据存储。 连接件：表示了组件之间的交互，简单的连接件有：管道（pipe）、过程调用 （procedure-call）、事件广播（event broadcast）等。复杂的连接件有：客户－服务器 （client-server）通信协议，数据库和应用之间SQL连接等。 约束：表示了组件和连接件的拓扑逻辑和约束（constraint）。

架构

架构是为了解决软件复杂性问题。

软件系统的复杂度

软件系统的复杂度的有以下来源：高性能、高可用、可扩展、安全、 规模和低成本。

单体架构

用户比较多的单体架构

面向服务的架构SOA

微服务架构

将一个大的系统拆成若干个独立的小系统，分别进行维护和部署，都运行在自己独立的进程中。它们之间可以通过轻量级的通信协议(http等)进行通信，在功能上还是一个完整的整体，这样的设计方法称之为微服务的架构。

微服务之间的通信可以有同步和异步两种方式，同步采用RPC或（RESTful），异步采用消息队列。

软件体系结构风格

[风格]  https://zhuanlan.zhihu.com/p/39784838 

管道/过滤器风格的特点：（摘自：【百度百科】软件体系结构）

（1）使得软构件具有良好的隐蔽性和高内聚、低耦合的特点；

（2）允许设计者将整个系统的输入/输出行为看成是多个过滤器的行为的简单合成；

（3）支持软件重用。重要提供适合在两个过滤器之间传送的数据，任何两个过滤器都可被连接起来；

（4）系统维护和增强系统性能简单。新的过滤器可以添加到现有系统中来；旧的可以被改进的过滤器替换掉；

（5）允许对一些如吞吐量、死锁等属性的分析；

（6）支持并行执行。每个过滤器是作为一个单独的任务完成，因此可与其它任务并行执行。

举例（媒体播放器）

编译器

事件系统风格

事件驱动架构：当软件系统中存在的一些事件发生，导致其他部分执行或者操作的设计方法叫事件驱动架构

一个事件驱动风格实例

事件系统风格常用实现方式： 一种是无事件管理器模式，一种是有事件管理器模式。 无事件管理器模式常见的是观察者模式。有事件管理器常见的是点对点模式和发布订阅模式。

设计模式

观察者模式：

有管理器模式模式

可应用场景

点对点模式、竞争消费者模式和发布订阅模式

微服务风格

SOA

ＳＯＡ的产生背景： 企业各部门都有独立的ＩＴ系统，比如人力资源系统、销售系统等，随着企业业务的发展，更多业务需要将各部门的IT系统集成到一起工作，但是各个部门的IT系统的提供商不同、实现技术不同，有的系统用Java开发，对外提供RPC；有的系统用C#开发，对外提供SOAP协议，只能借助ESB进行格式转换了，所以ＳＯＡ就诞生了。

微服务架构特征

1）组件化与服务 每个服务运行在一个独立的进程中

2）围绕业务能力进行组织

3）产品不是项目 you build,you run it

4）智能终端弱管道 通过轻量级RESTfulAPI进行通信或通过RabbitMQ通信

5）去中心化 没有ESB，各自数据库独立

6）重点是自动化部署、自动化测试、熔断等技术

SOA和微服务区别

微服务是去掉ESB后的SOA。SOA的ESB太中心化，如果它有问题，整个系统就瘫痪了。所以微服务是去中心化的，当然去中心化还体现在每个微服务有自己独立的数据库。

微服务是细粒度的SOA，且通过HttpRESTful协议或RPC协议代替ESB。

微服务应用场景是互联网级，SOA应用场景是企业级。

微服务的理念是快速交付，SOA的理念是解决兼容问题。快速交付就要求采用自动化测试、持续集成、自动化部署等。

Nacos Config中的几个概念

使用Nacos Config作为配置中心，就是将Nacos当做一个服务端，将各个微服务看 成客户端，我们将各个微服务的配置文件统一放在Nacos上，然后各个微服务从 Nacos上拉去配置即可。

命名空间(namespace)：用于不同环境或用户的配置隔离 配置分组(group)：用于将不同服务归类为同一个组 配置集(data id)：一个微服务的配置文件就是一个配置集

降级、限流和熔断---保护你的微服务

降级：为了业务高可用，丢车保帅，停掉非业务功能，优先保证核心业务可用。例如：论坛可以降级 为只能看帖子，不能发帖子。

限流：只允许系统能够承受的用户量进来访问，超出系统访问能力的用户将被抛弃。

熔断：A服务的X功能依赖B服务的某个接口，当B服务的接口响应很慢的时候，A服务的X功能响应肯定 也会被拖慢，进一步导致A服务的线程都被卡在X功能处理上，此时A服务的其他功能都会被卡住或响应 非常慢。这时就需要熔断机制了，即A服务不再请求B服务的这个接口，A服务内部只要发现请求B服务 的这个接口就立即返回错误，从而避免A服务整个被拖慢甚至拖死。

熔断和降级是两个比较容易混淆的概念，降级的目的是应对系统自身的故障，而熔断的目的是应对 依赖的外部系统故障的情况。

自动化部署和自动化测试

容器化：Docker是容器引擎，起到应用隔离 作用。K8S是容器编排系统，用于容器管理， 容器间的负载均衡。

自动化测试框架有Junit（单元测试）、 Selenium（Web应用程序自动测试）等。

资源

统一资源接口要求使用标准的HTTP方法对资源进行操作，所以URI只应该来表示资源的名称，而不应该包括资源的操作。通俗来说，URI不应该使用动作来描述。例如：

GET /getUser/1 =>GET /user/1 获得资源

POST /createUser=>POST /user 创建资源

PUT /updateUser/1=>PUT /user/1更新资源

DELETE /deleteUser/1= >DELETE /user/1 删除资源

原来对资源进行操作的方法，不规范 =>方法名+资源名 标准且规范

客户端与服务端的交互必须是无状态的，并在每一次请求中包含处理该请求所需的一切信息。

RESTful风格

RESTful架构风格使得前后端分离了

使用RESTful风格可以克服传统架构风格的那4个缺陷：

①设计API工作量减少，因为功能需求一旦出来，需要操作的资源、操作的方式立刻就能分析出来，因此资源URL和API的使用方式(GET, POST...)都很容易得到。 ②没有了操作之间的依赖。资源之间虽然可能有关联，但是小得多。 ③对资源的操作也就那么几种(获取、新建、修改、删除)，API的一致性、自我描述性很强，不需要过多解释。 ④对于GET请求，我们都可以考虑使用缓存，因为在RESTful的架构中，GET请求代表获取数据，必须是安全、幂等的。

无服务风格

无服务架构风格使得“一个函数可以是一个微服务”成为现实。

BaaS 后端即服务

IaaS 基础设施即服务

FaaS 即服务

SaaS 软件即服务

PaaS 平台即服务

视图

视图是一组架构元素及其关联关系的表示。

视图”的概念为我们提供了描述体系结构的原则： 记录相关的意见 然后添加适用于多个视图的信息 从而将观点联系在一起

架构元素–软件或硬件中存在的一组实际元素 视图–由系统相关者编写和读取的一组连贯的 架构元素的表示

但并非涵盖所有架构元素。 视图绑定了体系结构描述时感兴趣的元素类型和关系类 型，并显示了它们。

类型

分解视图–显示与“关联的子模块”关系相关联的模块

使用视图–显示与“使用”关系相关联的模块

（即，一个模块使用另一模块提供的服务） 分层视图–显示被划分为相关和连贯功能的模块组。 每个组代表整体结构中的一个层。 类/泛化视图–显示称为类的模块，这些模块通过关系的 “继承”或“实例”关联。

进程视图–显示通过通信、同步和排除操作连接的进程或线程

并发视图–显示组件和连接器，其中连接器代表“逻辑线程” 共享数据（存储库）视图–显示创建、存储和访问持久数据的组件 和连接器 客户端-服务器视图–显示协作的客户端和服务器以及它们之间的 连接器（即它们共享的协议和消息）

部署视图–显示软件元素及其对硬件和通信元素的分配 实施视图–显示开发、集成和配置控制环境中的软件元 素及其到文件结构的映射 工作分配视图–显示模块及其如何分配给负责实施和集 成它们的开发团队

4+1视图

Rational公司的Kruchten在1995年提出了用于体系结构描述的“4 + 1”模型。该模型建立在由 Perry&Wolf和Berry Boehm提出的体系结构定义的基础上。

逻辑视图：支持行为要求。 关键抽象，是对象或对象类。 过程视图：解决并发和分发。 将线程映射到对象。 开发视图：组织软件模块，库，子系统，开发单元。 物理视图：将其他元素映射到处理和通信节点。 用例视图：将其他视图映射到重要的用例（这些用例被称 作场景）上对体系结构加以说明，它们构成了第5个视图。

逻辑视图

1）支持系统的功能需求，即系统提供给最终用户的服务。 2）通常是系统职责划分 3）通常用功能模块图和分析类图表示逻辑视图。 分析类图就是抽象级别较高的类图，而设计类图更具体

开发视图

1）为开发人员准备的 ​ 2）关注程序包，不仅包括要编译的源程序还包括第三方库、框架 ​ 3）要考虑软件内部的需求，如可扩展性、可重用性、易理解性、易测试性、可移植性 ​ 4）考虑开发工具的不同而带来的局限性 ​ 5）通常用设计类图、包图、组件图表示开发视图。

类图的麻烦在于它们特别多样化，这里有一些 使用技巧： 不要使用所有可用的符号。 从简单的东西开始： 类，关联，属性，泛化和约束。 仅在需要时才引 入其他符号。 分析类图在探索业务语言时非常有用。 类之间的关系有：依赖、关联、组合、聚合、泛化和实现。

部署视图

1）关注如何安装和部署到物理机器 ​ 2）如何部署目标程序，尽量考虑高可用、高性能和高并发（三高） ​ 3）通常用部署图表示

过程视图

1）也称进程视图、并发视图 2）侧重系统的运行特性，关注运行期的非功能需求，如性能和可用性 ​ 3）强调并发性、分布式、系统集成性和容错能力 ​ 4）关注进程、线程等运行时概念，以及相关的并发、异步和通信等问题 ​ 5）通常用活动图表示

逻辑视图&开发视图&过程视图

1）逻辑视图中的一个职责可能映射开发视图多个程序包 ​ 2）逻辑视图的一个分析类可能映射开发视图的多个设计类 ​ 3）开发视图关注程序包的静态依赖关系，而过程视图关注的是这些程序包运行之后的交互关系。

用例视图

主要用用例图表示

质量属性

Quality Attributes（QA）质量属性

属于非功能性需求，并不被功能所决定 实现功能特性必须给构成系统中的各个部分（模块） 赋予正确的职责、正确的资源和正确的调度顺序 先实现功能，再谈质量属性

质量场景

质量属性场景的6个组成部分 刺激源（source）：谁造成的刺激 刺激（stimulus）：一个影响系统的情况 制品（artifact）：系统被影响的部分 环境（environment）：刺激发生时系统所处的状态 响应（response）：刺激所产生的结果 响应衡量指标（response measure）：如何评估响应

可用性

可用性的关注点 故障 提升可用性的策略 故障检测 故障恢复 故障避免

衡量指标： 可用（或故障）时间百分比 修复故障所需的时间 平均无故障时间

提升可用性的策略

降低故障造成的影响 方向1：故障检测 如何第一时间发现故障 方向2：故障恢复 如何恢复正确的结果 方向3：故障避免 如何主动减少故障的发生

心跳

被监控组件定期向监控组件发出心跳消息 在节点间保持周期性的心跳信号以检测各个节点的状态。若连续未收到的 心跳信号到了一定的数目，就认为相应的系统已经出现故障。

异常

抛出 + 捕获 + 处理 需要编程语言支持

主动冗余

A、B服务器完成同样的运算（A和B的状态时刻保持一致），平时只取 A算出的结果 当A出现故障时，系统可以极快地切换到B

被动冗余

A服务器完成运算后的一定时间内把自身状态告知B，B再把自身状态更 新为A的状态。 当A出现故障时，首先需要确认B的状态是最新的。 在重新上线前，都需要做状态的重新同步

内测

开发人员修正bug，并在内部进行测试，确认无误后再发布补丁

进程监控（故障避免）

检查点/回滚

定期保存，便于恢复

可修改性

衡量指标：

修改完成的时间 修改所花的人力成本 修改所花的经济成本 ……

刺激源：谁进行的修改（开发者/管理员/用户） 刺激：要进行的具体修改

提升可修改性策略

目标：降低修改的时间和成本

方向1：限制修改范围 让修改所影响的 软件范围尽可能的小 方向2：延迟绑定时间 让软件在运行期间仍可进行灵活修改

可修改性的关注点 修改的成本 提升可修改性的策略 限制修改范围 延迟绑定时间

性能

关注点： 系统响应事件的速度 和事件的数量和到达模式有关

响应衡量指标： 处理事件所花的时间 单位时间内处理事件的数目 处理的错误率/丢失率

提升性能策略

目标 在限定时间内响应事件

获取资源 + 使用资源 方向1：资源的需求 方向2：资源的管理 方向3：资源的仲裁

安全性

关注点 在保证合法用户使用系统的前提下，抵抗对系统的攻击 攻击（威胁） 试图突破系统安全性防护的尝试

响应 合法用户正常使用，拒绝非法用户的使用 对攻击有威慑

响应衡量指标 发起攻击的难度 从攻击中恢复的难度

可测试性

关注点 让软件的bug容易被测试出来 验证软件产品与它的需求规格是否匹配（存在不符或缺失） 使用最小的成本和工作量来验证软件的质量

响应 理想的响应是可以进行测试，并且可以观察到测试结果 当测试结果无法被观察到时，测试难度很大

响应衡量指标 白盒测试中的覆盖率 语句覆盖 判定覆盖/分支覆盖（判定可能是多个条件组合） 条件覆盖：覆盖判定中的每个条件 路径覆盖、判定条件覆盖、条件组合覆盖…… 未来继续发现bug的概率

提升可测试性

目标：让测试更轻松

方向1：黑盒测试 方向2：白盒测试

黑盒：记录 / 回放、把接口和实现分离开、提供专用的测试路径

白盒：内部监控、Appium（APP UI测试）、Selenium（Web UI测试）、JMeter（接口测试、性能测试）

可测试性的关注点 让bug容易被测试出来 提升可测试性的策略 黑盒 白盒

易用性

关注点：让用户使用软件的难度降低 不同方面： 如何方便用户入门? 如何提高用户使用软件的效率? 如何降低用户出错造成的影响？ 如何让软件适应用户的需求？ 如何提高用户的自信和舒适度？

响应： 系统响应用户的要求 响应衡量指标： 用户完成任务的时间 用户出错的次数 用户满意度 用户操作的成功率

提升易用性

目标 让用户轻松 方向1：运行时策略 方向2：设计时策略

体系结构评估

软件架构决定了系统的质量属性。可修改性、性能、可用性等随着软件架构的确定而确定。如果软件架构有问题，无论使用多么高超的实现技术，一些质量属性都无法实现。

敏感点、权衡点、风险点

敏感点是一个或多个构件（和/或构件之间的关系）的特性 权衡点是影响多个质量属性的特性，是多个质量属性的敏感点系统的体系结构涉及到很多人的利益，这些人都对体系结构施加各种影响，以保证自己的目标能够实现。

架构评估

◇ 基于调查问卷或检查表的评估方式 ◇ 基于场景的评估方式 ◇ 基于度量的评估方式

比较如下：

质量效应树