软件架构--架构模式、特征

1、概述

1.1 定义软件架构

软件架构包含系统的结构，系统必须支持的架构特征、架构决策以及设计原则。

• 系统的结构，是指实现该系统的一种或多种风格（比如微服务、分层和微内核等）。
• 架构特征，定义系统的成功标准，这些标准与系统的功能正交。（比如性能、可扩展和安全性等）
• 架构决策，一组关于如何构建系统的规则。
• 设计原则，与架构决策不同，设计原则是指导原则，而不是必须遵循的规则。

1.2 架构师的角色期望

• 制定架构决策
• 持续分析架构
• 掌握最新趋势（技术、行业）
• 确保决策被遵守
• 丰富的经历和经验
  接触多种语言、平台和技术。8分技术广度，2分技术深度。
• 具备业务领域知识
• 具备人际交往能力
• 了解并驾驭政治

2、架构思维

2.1 架构与设计

架构师与开发团队之间要双向强关联。保证架构最终落地。

2.2 技术广度

技术广度比技术深度更重要。因为架构师的职责就是根据功能做出与技术限制相匹配的决策，所以更广泛了解各种解决方案是非常有价值的。
冰封原始人反模式，在设计架构时，处于非理性的担忧状态。

2.3 分析权衡

架构中的所有事务都需要权衡，这就是为什么那个能够回答所有架构问题的著名答案是“看情况”。
架构取决于部署环境、业务驱动因素、公司文化、预算、时间表、开发人员技能集以及其他因素。

2.4 理解业务驱动因素

架构师需要理解系统成功所需的业务驱动因素，并将这些需求转换为架构特征。

2.5 平衡架构和动手编码

架构师应避免瓶颈陷阱，把关键路径和框架代码委派给团队成员。然后着重实现业务功能。

a. 频繁进行概念验证（Proof-Of-Concept，POC）。
b. 处理一些技术债或架构相关的事。
c. 通过创建简单的命令行工具和分析器进行自动化，帮助团队完成日常任务。
d. 进行代码审查。

3、模块化

3.1 定义

在讨论架构时，一般使用模块化作为通用术语来表示相关的代码分组：类、函数或其他分组方式。

3.2 度量模块化

• 内聚性
  内聚性是指模块中各部分的关联程度。
  内聚性从最佳到最坏：功能、顺序、联系/通信、程序、时间、逻辑、偶然。
  LCOM可以度量模块的内聚性，但无法指出哪些部分适合放在一起。
• 耦合
  传入耦合与传出耦合
  耦合可以衍生出抽象性和不稳定性。继而给出与主序列的距离。
• 共生性
  如果一个组件的变更需要修改另一个组件才能保持系统的整体正确性，则两个组件是共生的。

4、架构特征

4.1 重要的架构特征

• 性能效率
  已知条件下使用的资源量的性能度量。

   包括时间行为（响应的度量、处理时间的度量、吞吐率的度量）、资源利用率（使用的资源的梳理和类型）和容量（超出已建立最大限制的程度）
  

• 兼容性
  产品、系统或组件可以在共享相同硬件或软件环境的同时与其他产品、系统或组件交换信息或执行其所需功能的程度。

  包括共存（可以有效执行其所需的功能，同时与其他产品共享公共的环境和资源）和互操作性（两个或多个系统可以交换和利于信息的程度）
  

• 易用性
  用户可以针对其预期目的，从而有效、高效且令人满意的使用系统。

   包括适当性和可识别性（用户可以识别软件是否适合他们的需求）、可学习性（用户可以轻松学习如何使用软件）、用户错误保护（防止用户犯错误）和可访问性（使软件可供具有最广泛特征和功能的人员使用）
  

• 可靠性
  系统在指定条件下，指定时间段内运行的稳定程度。

  此特征包括以下子类别：成熟度（软件是否满足正常运行下的可靠性需求）、可用性（软件可运行且可访问）、容错（软件是否在硬件或软件故障的情况下仍按预期运行）和可恢复性（通过恢复任何受影响的数据并重新建立系统的所需状态，软件可以从故障中恢复）
  

• 安全性
  软件可以保护信息和数据的程度，以便人员、其他产品或系统可以根据其类型和授权级别访问数据。

   此特征包括机密性（只有获得访问权限的人才能访问数据）、完整性（防止未经授权的访问或修改软件或数据）、不可否认性（可以证明操作或事件有发生）、问责制（是否可以跟踪用户的操作）和真实性（可以证明用户的身份）
  

• 可维护性
  表示开发人员可以修改软件以对其进行改进、更正或使其适应环境和需求变化的有效性和效率。

架构不需要特别超前规划。例如一般的应用百万级用户已比较可观，千万级即是非常多。
架构应可迭代。敏捷软件开发最重要的成果之一就是迭代的价值。
可用性和可靠性在大部分情况下重叠。但请回忆UDP协议，UDP协议通过IP可用，但结果不可靠：数据包可能无序到达，接收方可能需要再次请求丢失的数据包。

5、识别架构特征

5.1 从领域问题中提取架构特征

将领域问题转换为架构特征。

5.2 从需求中提取架构特征

卡塔练习为架构师提供一个用领域术语和额外的上下文陈述的问题（可能不会出现在需求中但会影响设计）。

5.3 从隐式领域知识中提取架构特征

例如在网上购物时，要保证交易能正常执行。也隐藏要求交易过程和数据的安全性。

6、度量和治理架构特征

6.1 度量架构特征

• 运营性度量，基于统计分析。
• 结构性度量，代码的可测量方法是复杂度，由循环复杂度（CC）度量。java可以用Crap4J。
• 过程度量，部分架构特征与软件开发过程相交。

6.2 治理和适应度函数

适应度函数是一种目标函数，用于评估输出与目标的接近程度。适应度函数使架构管理的很多方面实现自动化。
架构适应度函数，任何对某些架构特征或架构特征组合进行客观的完整性评估的机制。
指标工具JDepengd可以检查包之间的依赖关系。

7、架构特征的范围

7.1 耦合与共生性

共生性，如果一个组件的变更需要修改另一个组件才能保证系统的整体正确性，则两个组件是共生的。包括静态共生性和动态共生性。

7.2 架构量子与粒度

组件级耦合不是将软件绑定在一起的唯一方法。许多业务概念在语义上将系统的各个部分绑定在一起，从而形成功能上的内聚。
架构量子，具有高功能内聚和同步共生性的可独立部署的工件。

8、组件化思维

组件是模块的物理表现形式。

8.1 组件范围

1、最简单的组件是将代码封装在比类更高的模块级别。
2、组件在架构中也作为子系统或层出现，是许多事件处理器的可部署单元。
3、另一种组件倾向于在它自己的地址空间中运行，并通过底层的网络协议或更高层的格式（REST或消息队列）进行通信，从而在微服务等架构中形成独立、可部署的单元。
组件是架构中的基本模块。代表一种通用的容器机制。

架构师角色

两种顶级架构划分—分层（技术）和模块化（领域）
在领域驱动设计中，架构师识别相互独立和分离的领域或工作流。微服务架构风格就是基于这种哲学。
分层架构的组织原则之一是技术关注点分离。

组件识别流程

识别初始组件，将需求分配给组件，分析角色和职责，分析架构特征，重组组件

组件粒度

细粒度，导致组件之间的通信过多。
粗粒度，导致很高的内部耦合，从而导致部署和测试困难，以及对模块化的负面影响。

组件设计(发现)

实体陷阱反模式
把数据库关系标识为应用程序中得工作流时，就会出现实体陷阱反模式。这种反模式是没有考虑应用程序的实际工作流。
演员/动作方法
将需求映射到组件，用于发现系统的典型用户以及他们可能使用系统做什么。在常见架构设计中使用。
事件风暴
在事件风暴中，假定项目将使用消息或事件在各个组件之间进行通信。为此，团队尝试根据需求和识别出的角色确定系统中发生的事件，并围绕这些事件和消息处理程序构建组件。在微服务架构设计中经常使用。
工作流方法
这是事件风暴的替代方法，为不使用领域驱动设计或消息传递的架构师提供更通用的方法。工作流方法识别关键角色，确定这些角色参与的工作流类型，并围绕识别的活动构建组件。

9、架构决策

9.1 架构决策反模式

反模式，看起来是一个好主意，但却会带来麻烦的模式。
掩盖你的资产，架构师担心做出错误选择，而避免或推迟做出架构决策。
土拨鼠日，当不知道为什么要做出某个决策时，因此它被反复讨论。
四个常见的业务合理性包括成本、上市时间、用户满意度和战略定位。。
电子邮件驱动架构，因遗弃、忘记或不知道已经做出的架构决策而无法实现该架构决策。

9.2 具备架构意义

软件架构师Michael Nygard通过创造术语“具备架构意义”，解决架构师应该负责哪些决策。具备架构意义的决策是影响结构，架构特征、依赖性、接口或构建技术的决策。

9.3 架构决策记录

架构决策记录（ADR）包括标题、状态、背景、决策、后果、合规性和备注。

10、分析架构风险

10.1 风险矩阵

风险的整体影响和发生的可能性。

10.2 风险评估

风险评估是对架构总体风险的汇总报告。

10.3 风险风暴

风险风暴是一种协作活动，用于确定特定维度内的架构风险。常见维度包括：未经验证的技术、性能、可扩展性、可用性、数据丢失、单点故障和安全性。
风险风暴与风险评估结合，是识别并跟踪风险、改进架构以及处理主要利益相关者之间谈判的一个极好媒介。

11、架构绘图和演示

11.1 绘图

绘图标注，UML、C4
UML中只有类图和序列图继续被使用。
C4旨在解决UML的不足，包括Context、Container、Component和Class。

11.2 演示

在演示中，由演示者控制如何展开一个想法的陈述，而文档是由读者来控制。
在演示时，幻灯片只包含一半的信息，另一半则由演讲者补充。

参考

《软件架构–架构模式、特征及实践指南–Mark Richards、Neal Ford》