首页  思维导图  详情

软件架构

2024-09-28 14:00:09   0  举报





AI智能生成

架构模式、特征及实践指南

技术、框架

作者其他创作

大纲/内容

前言：失效的公理

架构师有一个重要的责任，即质疑从过去的年代遗留下来的假设和公理

第一部分

第1章：概述

软件架构包含

系统的结构

是指实现该系统的一种或多种架构风格（比如微服务、为微内核）

系统必须支持的架构特征

定义了系统成功的标准，这些标准往往与系统功能正交

架构决策（必须要做的事）

定义了一组如何构建系统的规则。构成了系统的约束，并指导开发团队可以做哪些，不可以做哪些

设计原则（指导原则）

是指导原则，而不是必须遵守的规则

架构师的角色期望（工作内容、定位）

制定架构决策

架构师需要制定架构决策和设计原则，以指导团队、部门或者整个企业进行技术决策

持续分析架构

架构师必须从整体上分析技术和问题的变化，以确定架构的稳定性

掌握最新趋势

架构师需要掌握最新的技术和行业趋势

确保决策被遵守

丰富的经历和经验

架构师应该专注于技术广度，而不是技术深度

具备业务领域知识

架构师还要了解问题背后的业务领域。不专业的架构师无法得到利益相关方和业务用户的信任，毫无竞争力

最成功的架构师一定是那些具备广泛且实际的技术支持和特定领域的丰富业务知识的架构师。通过使用对方熟悉的领域知识和语言，这些架构师能够与高级别高管和业务用户进行有效沟通。这种专业度让高管和业务用户对架构师充满信息，如此才有合作的可能。

具备人际交往能力

了解并驾驭政治

与架构的交集

工程实践

运维与DevOps

流程

即构建软件的方式

数据

软件架构定律

软件架构中的一切都是在做权衡

原因比方法更重要

第2章：架构思维

架构思维

用架构的眼光或视角来看待事务

四个重要方面

了解架构与设计的区别

通过架构师与设计师的合作，使系统落地

需要在具备一定技术广度的同时，仍保持一定水平的技术深度

架构师必须具有非常广的技术广度才能像架构师搬思考，并以架构的角度看待事务

知识金字塔

未知的未知

已知的未知

已知

对于架构师而言，明智的做法是做到“博而不专”，除了一些必要的专业知识，架构师要把时间更多的放在扩展行业内的不同知识上

需要理解、分析和协调各种解决方案和技术之间的权衡

要在每种解决方案中进行取舍，无论是技术解决方案还是其他解决方案，然后分析这些方案的利弊，最终形成并确定最佳解决方案

架构中的所有事务都需要权衡。架构中没有对错，唯有取舍

架构取舍取决于部署环境、业务驱动因素、公司文化、预算、时间表、开发人员技能以及其他因素

需要了解业务驱动的重要性以及他们是如何转化为架构问题的

平衡架构和动手编码

每个架构师都应该动手编写代码，并保持一定水平的技术深度

三种平衡方式

编写关键路径或框架代码

负责一些技术债或架构相关的故事

进行频繁的代码审查

第3章：模块化

定义

描述代码的逻辑分组，类、函数或其他分组方式等

度量模块化

内聚性

模块中各部分的关联程度。

耦合

抽象性、不稳定性以及与主序列的距离

共生性

如果一个组件的变更需要修改另一个组件才能保持系统的整体正确性，则这两个组件是共生的。

静态共生性

源代码级的耦合

动态共生性

运行时的耦合

第4章：现有的架构特征

一个软件解决方案包含领域需求和架构特征

领域需求：业务需求

架构特征：

明确非领域涉及的某个注意事项

影响设计的某些结构项

是否对应用的成功至关重要

现有的、已经定义出来的架构特征

运营性架构特征

可用性

连续性

可恢复性

可靠性/安全性

健壮性

可伸缩性

结构性架构特征

可配置性

可扩展性

可安装性

可利用性/可恢复使用性

本地化

可维护性

可移植性

可支持性

可升级性

跨领域架构特征

可访问性

可归档性

认证

授权

法律

隐私性

安全性

可支持性

易用性/可实现性

永远不要为最好的架构而努力，而要要为最擦汗可用的架构而努力

架构师应该设计尽可能迭代的架构，如果可以更轻松地对架构进行更改，则可以减少在第一次尝试中发现确切正确内容的压力

第5章：识别架构特征

从三个方面提取架构特征

领域关注点

不要执迷于架构特征的数量，而要保证设计尽量简单

最好的方法是让领域利益相关者从最终列表中以任意顺序选择前三个重要的特征

需求

隐式领域知识

在架构中没有错误的答案，只有昂贵的答案

架构师不应该过分强调发现一组完全争取的架构特征。

架构师必须记住：没有最佳的架构设计，只有最差可用的权衡取舍

第6章：度量和治理架构特征

度量架构特征

运营性度量

高水平的团队不只是建立出色的性能数字，他们的定义基于统计分析

结构性度量

过程度量

治理和适应度函数

治理架构特征

架构治理的范围涵盖了架构师（包括企业架构师之类的角色）想要在软件开发过程中施加影响的任何方面

适应度函数

一种目标函数，用于评估输出与目标的接近程度

任何对某些架构特征或架构特征组合进行客观的完整性评估的机制

第7章：架构特征的范围

耦合与共生性

如果一个组件变更需要修改另一个组件才能保持系统的整体正确性，则两个组件时共生的

共生性

静态共生性：通过静态代码分析发现

动态共生性：设计运行时行为

架构量子与粒度

具有高功能内聚和同步共生性的可独立部署的工件

可独立部署

一个架构量子包括所有必须的组件，与架构的其他部分独立

高功能内聚

组件设计的内聚是指包含的代码在目的上的统一程度

同步共生性

在应用上下文内或形成此架构量子的分布式服务之间进行同步调用

DDD：Domain Driven Design

领域驱动设计，是一种建模技术，可以对复杂的问题域进行有组织的分解。

DDD中定义了有界上下文，该领域相关的所有内容在内部都是可见的，但对其他有界上下文是不可见的

第8章：组件化思维

组件范围

组件在架构中也作为子系统或层出现，是许多事件处理器的可部署工作单元

架构师必须做出的主要决策之一是考虑架构中组件的顶级划分

架构师角色

架构师在决策上不能事必躬亲

架构师必须将组件标识为新项目的首要任务之一。但是，在架构师能够识别组件之前，必须知道如何划分架构

架构划分

按领域划分架构

按技术划分架构

组件识别流程

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

第二部分：架构风格

包罗如何组织用户界面和后端源码以及源代码如何与数据存储中心之间进行交互的总体结构

第9章：基础

架构风格（有时也称为架构模式）描述包含了各种架构特征的组件的命名关系

单体架构与分布式架构

单体架构

所有代码作为单个部署单元

分布式架构

通过远程访问协议连接的多个部署单元

关于分布式

谬误

被认为或假定正确但实际上错误的一种言论

分布式计算的8个谬误

1、网络是可靠的

2、零延迟

3、带宽是无限的

4、网络是安全的

5、拓扑结构从不改变

6、只有一个管理员

7、传输成本为0

8、网络是同构的

其他考虑的方面

分布式日志

分布式事务

分布式架构依赖于所谓的最终一致性，以确保由不同部署单元处理的数据在有个未指定的时间点的时间全部同步到一致状态

分布式架构的折中思路：以牺牲数据一致性和数据完整性为代价实现高可伸缩性、高性能和高可用

单体架构

分层架构

管道架构

微内核架构

分布式架构

基于服务的架构

事件驱动架构

基于空间的架构

面向服务的架构

微服务架构

第10章：分层架构风格

大多数分层架构由4个标准层组成：展示层、业务层、持久层、数据库层

分层架构是一种技术分区架构（与领域分区的架构相反）。组件不是按领域（业务需求、客户）分组的，而是按其在架构中的技术角色分组的。

分层隔离性：在架构的一个分层中所做的更改通常不会影响其他分层中的组件，前提是这些层之间的契约保持不变

试用场景：

小型、简单的需求。

对预算和时间非常紧张的情况。

在不确定哪种架构风格最好时

架构特征评级

总体成本和简单性是分层架构特征的主要优点

架构特征

划分类型：技术

架构量子数量：1

可部署性：⭐

弹性：⭐

演化性：⭐

容错：⭐

模块化：⭐

总体成本：⭐⭐⭐⭐⭐

性能：⭐⭐

可靠性：⭐⭐⭐

可伸缩性：⭐

简单性：⭐⭐⭐⭐⭐

可测试性：⭐⭐

第11章：管道架构风格

管线-过滤器架构，由管线和过滤器组成。管线通过点对点的方式在过滤器之间形成单向通信。MapReduce

管线

过滤器之间的通信通道

单向的、点对点的

过滤器

自包含的、独立于其他过滤器

通常是无状态的

4种类型

生产者

转换器

测试器

消费者

架构特征评级

总体成本和简单性与模块化相结合是管道架构特征的主要优点

架构特征

划分类型：技术

架构量子数量：1

可部署性：⭐⭐

弹性：⭐

演化性：⭐⭐⭐

容错：⭐

模块化：⭐⭐⭐

总体成本：⭐⭐⭐⭐⭐

性能：⭐⭐

可靠性：⭐⭐⭐

可伸缩性：⭐

简单性：⭐⭐⭐⭐⭐

可测试性：⭐⭐⭐

第12章：微内核架构风格

由2个架构组件组成：

核心系统

运行系统所需的最小功能集合

插件组件

单机、独立的组件，包含专门的处理逻辑、附加功能和用于增强或扩展核心系统的定制代码

插件组件和核心系统之间的通信通常是点对点的

插件组件可以是基于编译的，也可以是基于运行时的

核心系统提供注册中心，包含每个插件组件的模块信息。名称、数据契约和远程访问协议细节等

契约

跨插件组件域的标准契约，包括从插件组件返回的行为、输入输出数据格式等。

架构特征评级

总体成本和简单性是微内核架构特征的主要优点，而可伸缩性、容错能力和可扩展性是其主要缺点

架构特征

划分类型：域和技术

架构量子数量：1

可部署性：⭐⭐⭐

弹性：⭐

演化性：⭐⭐⭐

容错：⭐

模块化：⭐⭐⭐

总体成本：⭐⭐⭐⭐⭐

性能：⭐⭐⭐

可靠性：⭐⭐⭐

可伸缩性：⭐

简单性：⭐⭐⭐⭐

可测试性：⭐⭐⭐

第13章：基于服务的架构风格

基于服务的架构风格是微服务架构风格的混合，其拓扑遵循分布式宏分层结构，该结构由单独部署的用户界面、单独部署的远程粗粒度服务和单体数据库组成。这种架构风格的服务通常是粗粒度的“应用程序的一部分”（通常称为域服务），他们是独立部署的。

架构特征评级

是最实用的架构风格之一，在进行域驱动设计时，基于服务的架构也非常合适

架构特征

划分类型：域

架构量子数量：＞1

可部署性：⭐⭐⭐⭐

弹性：⭐⭐

演化性：⭐⭐⭐

容错：⭐⭐⭐⭐

模块化：⭐⭐⭐⭐

总体成本：⭐⭐⭐⭐

性能：⭐⭐⭐

可靠性：⭐⭐⭐⭐

可伸缩性：⭐⭐⭐

简单性：⭐⭐⭐⭐

可测试性：⭐⭐⭐⭐

第14章：事件驱动的架构风格

一种流行的分布式异构架构风格，用于构建可伸缩性和高性能的应用程序。由异步接收和处理事件的解耦事件处理组件组成

异步能力：

即发即弃处理，不需要响应

异步通信的主要问题是错误处理。虽然响应能力得到了显著的提升，但是很难处理错误，从而增加了事件驱动的系统的复杂性。

防止数据丢失

广播功能

请求-应答

由2个队列组成：请求队列、应答队列

2种主要拓扑：

中介拓扑

核心组件是事件中介，它管理和控制初始事件和工作流。当需要对事件流程的工作流进行控制时，通常使用中介拓扑

主要的架构组件

初始事件

事件队列

事件中介

事件通道

事件处理器

主要优点

工作流控制

错误处理

可恢复性

重启能力

更好的数据一致性

主要缺点

事件处理器更加耦合

较低的可伸缩性

较低的性能

较差的容错

对负载工作流进行建模

代理拓扑

没有中心事件中介。当需要对事件的处理进行高度响应和动态控制时，则使用代理拓扑

主要的架构组件

初始事件

事件代理

事件处理器

待处理事件

主要优点

高度解耦的事件处理器

高可伸缩性

高性能

高容错性

主要缺点

工作流控制

错误处理

可恢复性

重启能力

数据不一致性

架构特征

划分类型：技术

架构量子数量：＞1

可部署性：⭐⭐⭐

弹性：⭐⭐⭐

演化性：⭐⭐⭐⭐⭐

容错：⭐⭐⭐⭐⭐

模块化：⭐⭐⭐⭐

总体成本：⭐⭐⭐

性能：⭐⭐⭐⭐⭐

可靠性：⭐⭐⭐

可伸缩性：⭐⭐⭐⭐⭐

简单性：⭐

可测试性：⭐⭐

第15章：基于空间的架构风格

基于空间的架构风格专门为解决涉及高可伸缩性、弹性和高并发问题而设计的。对于具有可变且不可预测的并发用户数量的应用程序，它也是一种有用的架构风格。

高可伸缩性、高弹性和高性能是通过删除中央数据库作为系统种的同步约束实现的，取而代之的是利用复制的内存数据网络。应用程序数据保存在内存中，并在所有活动的处理单元之间复制。当处理单元更新数据时，它通过带有持久队列的消息传递异步地将该数据发送到数据。随着用户负载的增加和减少，处理单元动态的启动和关闭，从而解决了可伸缩性问题。由于在应用程序中的标准事务处理中不涉及中央数据库，因此消除了数据库瓶颈，从而在应用程序中提供了近乎无限的可伸缩性。

架构组件

处理单元

程序处理代码

虚拟化中间件

管理处理单元的虚拟化平台

数据泵

异步发送数据到数据库

数据写入器

执行从数据泵产生的更新

数据读取器

读取数据库的数据并在处理单元启动时交付数据

架构特征

划分类型：域和技术

架构量子数量：＞1

可部署性：⭐⭐⭐

弹性：⭐⭐⭐⭐⭐

演化性：⭐⭐⭐

容错：⭐⭐⭐

模块化：⭐⭐⭐

总体成本：⭐⭐

性能：⭐⭐⭐⭐⭐

可靠性：⭐⭐⭐⭐

可伸缩性：⭐⭐⭐⭐⭐

简单性：⭐

可测试性：⭐

第16章：编制驱动的面向服务的架构

在架构中建立服务分类，每个分层都有特定的职责。编制引擎构成了这种分布式架构的核心，它利用编制（包括事务协调和消息转换等功能）将业务服务实现组合在一起。这种架构通常绑定一个或几个关系数据库，而不是像微服务架构中那样每个服务对应一个数据库。因此，事务行为是在编制引擎中（而不是在数据库中）以声明的方式处理的。

此架构的一个主要目标是在服务级别上实现重用——逐渐构建可以随着时间的推进实现增量重用的业务行为

架构特征

划分类型：技术

架构量子数量：1

可部署性：⭐

弹性：⭐⭐⭐

演化性：⭐

容错：⭐⭐⭐

模块化：⭐⭐⭐

总体成本：⭐

性能：⭐⭐

可靠性：⭐⭐