软件架构
2024-09-28 14:00:09 0 举报AI智能生成
架构模式、特征及实践指南
作者其他创作
大纲/内容
架构师有一个重要的责任，即质疑从过去的年代遗留下来的假设和公理
前言：失效的公理
是指实现该系统的一种或多种架构风格（比如微服务、为微内核）
系统的结构
定义了系统成功的标准，这些标准往往与系统功能正交
系统必须支持的架构特征
定义了一组如何构建系统的规则。构成了系统的约束，并指导开发团队可以做哪些，不可以做哪些
架构决策（必须要做的事）
是指导原则，而不是必须遵守的规则
设计原则（指导原则）
软件架构包含
架构师需要制定架构决策和设计原则，以指导团队、部门或者整个企业进行技术决策
制定架构决策
架构师必须从整体上分析技术和问题的变化，以确定架构的稳定性
持续分析架构
架构师需要掌握最新的技术和行业趋势
掌握最新趋势
确保决策被遵守
架构师应该专注于技术广度，而不是技术深度
丰富的经历和经验
架构师还要了解问题背后的业务领域。不专业的架构师无法得到利益相关方和业务用户的信任，毫无竞争力
最成功的架构师一定是那些具备广泛且实际的技术支持和特定领域的丰富业务知识的架构师。通过使用对方熟悉的领域知识和语言，这些架构师能够与高级别高管和业务用户进行有效沟通。这种专业度让高管和业务用户对架构师充满信息，如此才有合作的可能。
具备业务领域知识
具备人际交往能力
了解并驾驭政治
架构师的角色期望（工作内容、定位）
工程实践
运维与DevOps
即构建软件的方式
流程
数据
与架构的交集
软件架构中的一切都是在做权衡
原因比方法更重要
软件架构定律
第1章：概述
用架构的眼光或视角来看待事务
通过架构师与设计师的合作，使系统落地
了解架构与设计的区别
架构师必须具有非常广的技术广度才能像架构师搬思考，并以架构的角度看待事务
未知的未知
已知的未知
已知
知识金字塔
对于架构师而言，明智的做法是做到“博而不专”，除了一些必要的专业知识，架构师要把时间更多的放在扩展行业内的不同知识上
需要在具备一定技术广度的同时，仍保持一定水平的技术深度
要在每种解决方案中进行取舍，无论是技术解决方案还是其他解决方案，然后分析这些方案的利弊，最终形成并确定最佳解决方案
架构中的所有事务都需要权衡。架构中没有对错，唯有取舍
架构取舍取决于部署环境、业务驱动因素、公司文化、预算、时间表、开发人员技能以及其他因素
需要理解、分析和协调各种解决方案和技术之间的权衡
需要了解业务驱动的重要性以及他们是如何转化为架构问题的
四个重要方面
架构思维
每个架构师都应该动手编写代码，并保持一定水平的技术深度
编写关键路径或框架代码
负责一些技术债或架构相关的故事
进行频繁的代码审查
三种平衡方式
平衡架构和动手编码
第2章：架构思维
描述代码的逻辑分组，类、函数或其他分组方式等
定义
模块中各部分的关联程度。
内聚性
耦合
抽象性、不稳定性以及与主序列的距离
如果一个组件的变更需要修改另一个组件才能保持系统的整体正确性，则这两个组件是共生的。
源代码级的耦合
静态共生性
运行时的耦合
动态共生性
共生性
度量模块化
第3章：模块化
领域需求：业务需求
明确非领域涉及的某个注意事项
影响设计的某些结构项
是否对应用的成功至关重要
架构特征：
一个软件解决方案包含领域需求和架构特征
可用性
连续性
可恢复性
可靠性/安全性
健壮性
可伸缩性
运营性架构特征
可配置性
可扩展性
可安装性
可利用性/可恢复使用性
本地化
可维护性
可移植性
可支持性
可升级性
结构性架构特征
可访问性
可归档性
认证
授权
法律
隐私性
安全性
易用性/可实现性
跨领域架构特征
现有的、已经定义出来的架构特征
永远不要为最好的架构而努力，而要要为最擦汗可用的架构而努力
架构师应该设计尽可能迭代的架构，如果可以更轻松地对架构进行更改，则可以减少在第一次尝试中发现确切正确内容的压力
第4章：现有的架构特征
不要执迷于架构特征的数量，而要保证设计尽量简单
最好的方法是让领域利益相关者从最终列表中以任意顺序选择前三个重要的特征
领域关注点
需求
隐式领域知识
从三个方面提取架构特征
架构师不应该过分强调发现一组完全争取的架构特征。
架构师必须记住：没有最佳的架构设计，只有最差可用的权衡取舍
在架构中没有错误的答案，只有昂贵的答案
第5章：识别架构特征
高水平的团队不只是建立出色的性能数字，他们的定义基于统计分析
运营性度量
结构性度量
过程度量
度量架构特征
架构治理的范围涵盖了架构师（包括企业架构师之类的角色）想要在软件开发过程中施加影响的任何方面
治理架构特征
一种目标函数，用于评估输出与目标的接近程度
任何对某些架构特征或架构特征组合进行客观的完整性评估的机制
适应度函数
治理和适应度函数
第6章：度量和治理架构特征
如果一个组件变更需要修改另一个组件才能保持系统的整体正确性，则两个组件时共生的
静态共生性：通过静态代码分析发现
动态共生性：设计运行时行为
耦合与共生性
一个架构量子包括所有必须的组件，与架构的其他部分独立
可独立部署
组件设计的内聚是指包含的代码在目的上的统一程度
高功能内聚
在应用上下文内或形成此架构量子的分布式服务之间进行同步调用
同步共生性
具有高功能内聚和同步共生性的可独立部署的工件
领域驱动设计，是一种建模技术，可以对复杂的问题域进行有组织的分解。
DDD中定义了有界上下文，该领域相关的所有内容在内部都是可见的，但对其他有界上下文是不可见的
DDD：Domain Driven Design
架构量子与粒度
第7章：架构特征的范围
组件在架构中也作为子系统或层出现，是许多事件处理器的可部署工作单元
架构师必须做出的主要决策之一是考虑架构中组件的顶级划分
组件范围
架构师在决策上不能事必躬亲
架构师必须将组件标识为新项目的首要任务之一。但是，在架构师能够识别组件之前，必须知道如何划分架构
架构师角色
按领域划分架构
按技术划分架构
架构划分
识别初始组件 → 将需求分配给组件 → 分析角色和职责 → 分析架构特征 → 重组组件 → 组件粒度
组件识别流程
第8章：组件化思维
第一部分
包罗如何组织用户界面和后端源码以及源代码如何与数据存储中心之间进行交互的总体结构
架构风格（有时也称为架构模式）描述包含了各种架构特征的组件的命名关系
所有代码作为单个部署单元
单体架构
通过远程访问协议连接的多个部署单元
分布式架构
被认为或假定正确但实际上错误的一种言论
1、网络是可靠的
2、零延迟
3、带宽是无限的
4、网络是安全的
5、拓扑结构从不改变
6、只有一个管理员
7、传输成本为0
8、网络是同构的
分布式计算的8个谬误
谬误
分布式日志
分布式架构依赖于所谓的最终一致性，以确保由不同部署单元处理的数据在有个未指定的时间点的时间全部同步到一致状态
分布式架构的折中思路：以牺牲数据一致性和数据完整性为代价实现高可伸缩性、高性能和高可用
分布式事务
其他考虑的方面
关于分布式
单体架构与分布式架构
分层架构
管道架构
微内核架构
基于服务的架构
事件驱动架构
基于空间的架构
面向服务的架构
微服务架构
第9章：基础
大多数分层架构由4个标准层组成：展示层、业务层、持久层、数据库层
分层架构是一种 技术分区 架构（与领域分区的架构相反）。组件不是按领域（业务需求、客户）分组的，而是按其在架构中的技术角色分组的。
分层隔离性：在架构的一个分层中所做的更改通常不会影响其他分层中的组件，前提是这些层之间的契约保持不变
小型、简单的需求。
对预算和时间非常紧张的情况。
在不确定哪种架构风格最好时
试用场景：
总体成本和简单性是分层架构特征的主要优点
划分类型：技术
架构量子数量：1
可部署性：⭐
弹性：⭐
演化性：⭐
容错：⭐
模块化：⭐
总体成本：⭐⭐⭐⭐⭐
性能：⭐⭐
可靠性：⭐⭐⭐
可伸缩性：⭐
简单性：⭐⭐⭐⭐⭐
可测试性：⭐⭐
架构特征
架构特征评级
第10章：分层架构风格
管线-过滤器架构，由管线和过滤器组成。管线通过点对点的方式在过滤器之间形成单向通信。MapReduce
过滤器之间的通信通道
单向的、点对点的
管线
自包含的、独立于其他过滤器
通常是无状态的
生产者
转换器
测试器
消费者
4种类型
过滤器
总体成本和简单性与模块化相结合是管道架构特征的主要优点
可部署性：⭐⭐
演化性：⭐⭐⭐
模块化：⭐⭐⭐
可测试性：⭐⭐⭐
第11章：管道架构风格
运行系统所需的最小功能集合
核心系统
单机、独立的组件，包含专门的处理逻辑、附加功能和用于增强或扩展核心系统的定制代码
插件组件和核心系统之间的通信通常是点对点的
插件组件可以是基于编译的，也可以是基于运行时的
插件组件
由2个架构组件组成：
核心系统提供注册中心，包含每个插件组件的模块信息。名称、数据契约和远程访问协议细节等
注册
跨插件组件域的标准契约，包括从插件组件返回的行为、输入输出数据格式等。
契约
总体成本和简单性是微内核架构特征的主要优点，而可伸缩性、容错能力和可扩展性是其主要缺点
划分类型：域 和 技术
可部署性：⭐⭐⭐
性能：⭐⭐⭐
简单性：⭐⭐⭐⭐
注册&契约
第12章：微内核架构风格
基于服务的架构风格是微服务架构风格的混合，其拓扑遵循分布式宏分层结构，该结构由单独部署的用户界面、单独部署的远程粗粒度服务和单体数据库组成。这种架构风格的服务通常是粗粒度的“应用程序的一部分”（通常称为域服务），他们是独立部署的。
是最实用的架构风格之一，在进行域驱动设计时，基于服务的架构也非常合适
划分类型：域
架构量子数量：＞1
可部署性：⭐⭐⭐⭐
弹性：⭐⭐
容错：⭐⭐⭐⭐
模块化：⭐⭐⭐⭐
总体成本：⭐⭐⭐⭐
可靠性：⭐⭐⭐⭐
可伸缩性：⭐⭐⭐
可测试性：⭐⭐⭐⭐
第13章：基于服务的架构风格
一种流行的分布式异构架构风格，用于构建可伸缩性和高性能的应用程序。由异步接收和处理事件的解耦事件处理组件组成
即发即弃处理，不需要响应
异步通信的主要问题是错误处理。虽然响应能力得到了显著的提升，但是很难处理错误，从而增加了事件驱动的系统的复杂性。
异步能力：
防止数据丢失
广播功能
由2个队列组成：请求队列、应答队列
请求-应答
核心组件是事件中介，它管理和控制初始事件和工作流。当需要对事件流程的工作流进行控制时，通常使用中介拓扑
初始事件
事件队列
事件中介
事件通道
事件处理器
主要的架构组件
工作流控制
错误处理
重启能力
更好的数据一致性
主要优点
事件处理器更加耦合
较低的可伸缩性
较低的性能
较差的容错
对负载工作流进行建模
主要缺点
中介拓扑
没有中心事件中介。当需要对事件的处理进行高度响应和动态控制时，则使用代理拓扑
事件代理
待处理事件
高度解耦的事件处理器
高可伸缩性
高性能
高容错性
数据不一致性
代理拓扑
2种主要拓扑：
弹性：⭐⭐⭐
演化性：⭐⭐⭐⭐⭐
容错：⭐⭐⭐⭐⭐
总体成本：⭐⭐⭐
性能：⭐⭐⭐⭐⭐
可伸缩性：⭐⭐⭐⭐⭐
简单性：⭐
第14章：事件驱动的架构风格
基于空间的架构风格专门为解决涉及高可伸缩性、弹性和高并发问题而设计的。对于具有可变且不可预测的并发用户数量的应用程序，它也是一种有用的架构风格。
高可伸缩性、高弹性和高性能是通过删除中央数据库作为系统种的同步约束实现的，取而代之的是利用复制的内存数据网络。应用程序数据保存在内存中，并在所有活动的处理单元之间复制。当处理单元更新数据时，它通过带有持久队列的消息传递异步地将该数据发送到数据。随着用户负载的增加和减少，处理单元动态的启动和关闭，从而解决了可伸缩性问题。由于在应用程序中的标准事务处理中不涉及中央数据库，因此消除了数据库瓶颈，从而在应用程序中提供了近乎无限的可伸缩性。
程序处理代码
处理单元
管理处理单元的虚拟化平台
虚拟化中间件
异步发送数据到数据库
数据泵
执行从数据泵产生的更新
数据写入器
读取数据库的数据并在处理单元启动时交付数据
数据读取器
架构组件
划分类型：域和技术
弹性：⭐⭐⭐⭐⭐
容错：⭐⭐⭐
总体成本：⭐⭐
可测试性：⭐
第15章：基于空间的架构风格
在架构中建立服务分类，每个分层都有特定的职责。编制引擎构成了这种分布式架构的核心，它利用编制（包括事务协调和消息转换等功能）将业务服务实现组合在一起。这种架构通常绑定一个或几个关系数据库，而不是像微服务架构中那样每个服务对应一个数据库。因此，事务行为是在编制引擎中（而不是在数据库中）以声明的方式处理的。
此架构的一个主要目标是在服务级别上实现重用——逐渐构建可以随着时间的推进实现增量重用的业务行为
总体成本：⭐
可靠性：⭐⭐
可伸缩性：⭐⭐⭐⭐
第16章：编制驱动的面向服务的架构
深受DDD（领域驱动设计）启发，微服务中，服务边界的目的是识别域或者工作流
微服务这个词是一个标签，而不是描述。
在有界上下文中，内部部分耦合在一起进行工作，但是他们不与有界上下文之外的任何事务耦合
每个服务建模一个域或者工作流。因此，每个服务都包含在应用程序中运行所需的一切，包括类、其他子组件和数据库模式
有界上下文
微服务的驱动哲学：
有界上下文驱动的微服务的另一个需求是数据隔离
数据隔离：
虽然API层可以有多种用途，但是如果架构师想终于这个架构的基本理念（单一功能、有界上下文），则不应该将API层用作中介或编制工具。
API层
sidecar
微服务的存在离不开DevOps革命，以及实现运维自动化的不懈努力
运维重用
划分类型：领域
模块化：⭐⭐⭐⭐⭐
第17章：微服务架构
视情况而定！
架构风格的选择是对架构特征、域考虑、战略目标等多方面进行的权衡，深入分析和思考后得出的结果
以史为鉴
生态变化
新功能
加速度
领域变化
技术变化
外部因素
架构风格会随着时间的推移而改变，这些驱动因素包括：
指定的域：业务需求、运营要求
使系统成功所需的所有其他结构元素：架构特征
架构师主要做2件事：
域
影响结构的架构特征
数据架构
组织因素
了解团队和运维关注点
主要考虑因素
单体还是分布式？
数据应该放在哪里？
服务之间的通信风格使什么？同步还是异步？
需要做出的决定
架构决策标准
第18章：选择合适的架构风格
第二部分：架构风格
介绍架构决策的反向案例、架构决策过程中用到的工具
第19章：架构决策
工具：风险矩阵
风险评估
识别风险
达成共识
缓解风险
风险风暴
分析风险的步骤：
第20章：分析风险架构
绘图工具
绘图准则
第21章：架构绘图和演示
第22章：打造高效团队
沟通：Communication
协作：Collaboration
清晰：Clarity
简洁：Conciseness
架构4C原则：
第23章：谈判和领导力
架构师必须在职业生涯中不断学习
架构师也应该在他们的日常工作中留出一些时间来保持知识广度
对架构师i来说，技术的广度比深度更重要
每天花20分钟来学习新知识或深入研究某个特定主题，从而为你的架构师职业生涯做出贡献
20分钟规则
永远学习、永远实践！！！
第24章：打造职业发展路径
第三部分：技巧和软技能
软件架构-架构模式、特征及实践指南
0 条评论
回复 删除
下一页
