架构师修炼之道学习笔记

软件架构师的角色

架构师修炼之道学习笔记_第1张图片

架构师的职责

 架构师修炼之道学习笔记_第2张图片

软件架构的组成

架构师修炼之道学习笔记_第3张图片

 模块结构存在于设计阶段,组件连接器结构在软件运行时出现,分配结构展示模块元素与组件连接器元素之间,以及这些元素与现实的物理元素之间的协同与响应关系

软件架构的意义

是开发出色软件的基础。架构从以下六个方面有指导意义

架构师修炼之道学习笔记_第4张图片

架构设计思维

架构师修炼之道学习笔记_第5张图片

设计策略

架构师修炼之道学习笔记_第6张图片

首先挖掘关键架构需求

架构师修炼之道学习笔记_第7张图片

 主动选择架构

架构师修炼之道学习笔记_第8张图片

架构模式

架构师修炼之道学习笔记_第9张图片

模式 元素 关系 优点 缺点
分层模式 层:一组功能内聚的模块 哪些层可以使用其他层的模块 可运维性,可移植性,可复用性,可测试性,设计阶段的可修改性,概念上比较容易实施 每一层都引了额外的抽象,增加了复杂度,可能会影响性能,层数繁多和抽象泄露可能导致开发过程非常痛苦
端口适配器模式

层:包含业务逻辑,便它不清楚使用的数据和事件的来源

端口:层与适配器之间的接口。借助端口,层可以与具体的适配器分离

适配器:与外部数据源,设备或其他组件进行交互的代码,使得层能够访问数据和事件。

暴露:指明层可用的端口

实现:指明约束适配器的端口

注入:指明层可用的适配器

提升可测试性,可维护性,可修改性。团队可以分工完成不同的层和适配器 必须建立机制选择运行时使用的适配器。适配器决定了运行时质量。
管道过滤器模式

过滤器:读取,转换,记录数据的组件。过滤器必须定义预期输入并输出结果

管道:连接器,用于将数据从一个过滤器传输到下一个过滤器。管道具有单一输入和输出,不会改变传输的数据

一些变种还包含元素源(source)和槽(sink)。前者产生数据,后者仅接收数据

接驳:通过管道,连接一个过滤器的输出与另一个过滤器的输入 提升性能,可复用性,可修改性 管道过滤器系统不是交互式的。不会明显提升可靠性,可能会影响性能。
面向服务架构模式

服务:可独立部署的单元。通过定义好的接口提供服务功能

服务注册表:列出所有可用的服务,以便服务可查找其他可用服务

消息系统:取决于具体的系统设计

根据SOA系统的约束而变化。可能是调用,可能是发布,订阅 提升互用性,可复用笥,可伸缩性。 带有分布式计算的所有复杂性。集成复杂。
发布订阅模式

发布者:发布事件的组件

订阅者:订阅事件的组件 

事件总线:负责登记组件订阅和传递发布的事件。

发布:组件装饰事件发布到事件总线

订阅:组合登记订阅事件

提升可扩展性,可复用性,可测试性,可用性,可靠性,可伸缩性 性能很难判断
共享数据模式

数据库:保存访问器共享的数据

数据访问器组件:以某种方式使用数据的组件 

读取:数据访问器组件可以从共享数据库中读取数据。

写入:数据访问器组件将数据写入共享数据库

通过数据一致性、安全和隐私提升可靠性。如果数据库充分优化,数据访问器划分良好,也可以提升可伸缩性和可用性 单点故障,影响可用性和性能。如果数据库发生变更,可维护性也会受影响。
多层模式 层(tier):运行时组件的逻辑组。

属于:将组件归到某一层

通信:层或其内部组件与其他层的交互

允许通信:表明哪些层可以与其他层中的组件通信

分配到:将层映射到物理计算平台

提升安全性,性能,可用性,可维护性,可修改性,有利于分析成本和部署 作为运行时构造,在大型系统中实施可能会有难度,太多的层可能会抑制系统性能和可维护性。
能力中心模式

CoC团队:开发人员和架构师小组 

责任区域:架构的子集,可以是模式,技术,用例

负责:聚首CoC团队及其责任区域 提升专家的可复用性和可伸缩性,从而提升多方面的质量属性。 CoC让一些专家形成了知识上的孤岛,且容易因人员流失而出现知识流失,能力不足的CoC成员会引发问题,影响开发质量。
开源贡献模式

团队:提交或审核组件变更的小组

库:包含软件组件的版本普瑞玛存储率

拥有:团队负责审查变更并维护库的完整性。

可能贡献:表示可能向库提交变更的团队

提升可复用笥,可维护性,开发速度 与组件划分策略密切相关。在多数情况下,贡献的学习曲线极其陡峭,这种模式不太现实 。
大泥球模式 短期内提高开发速度 降低系统的可维护性,可扩展性,缺少设计的完整性,毫无章法的开发和缺乏架构知识

 分层模式与多层模式的区别:

  • 分层模式是模块结构,处理设计时元素,多层模式是组件连接器结构或者分配结构,处理运行时元素

建立模型

架构师修炼之道学习笔记_第10张图片

 架构设计研讨会

架构设计研讨会流程

架构师修炼之道学习笔记_第11张图片

阶段内容

架构师修炼之道学习笔记_第12张图片

1、准备:提前了解要探索的问题

2、启动:向团队介绍研讨会的目标和问题背景

3、创建:制作模型,绘制草图,构建原型

4、分享:展示创建的内容,并具体描述设计如何实现目标

5、评判:团队对分享的内容进行评判,就设计能否完成目标发表意见

6、迭代:重复第3到5步,优化模型,创建新模型。

7、跟进:针对发现的想法,风险,问题决定后续处理步骤

展示设计决策

描述架构

 架构师修炼之道学习笔记_第13张图片

4+1视图

架构师修炼之道学习笔记_第14张图片

 逻辑视图:描述软件的功能逻辑,由哪些模块组成,模块中包含哪些类,其依赖关系如何。逻辑视图主要支持功能需求,也就是系统应该提供怎样的服务给用户。系统分解为一组关键抽象,如问题域的对象或对象类的形式。利用封装和继承的抽象原则。分解不仅是为了功能分析,也为了识别常见的服务机制和跨系统的设计元素。我们可以使用UML类图和类模板代表逻辑视图的方法

开发视图:包括系统架构层面的层次划分,包的管理,依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性,不同视角看到的可能是同一个东西,开发视图中一个程序包,可能正好对应逻辑视图中的一个功能模块。开发视图关注实际的软件开发环境中的软件模块组织。软件打包可以小程序库或子系统等形式,子系统是由一个或少量的开发人员开发的系统。子系统有良好的组织层次结构,每一层都提供了一个狭窄的和良好定义的接口层。开发系统是由模块和子系统的架构组成的,表达了"出口"和"进口"的关系

处理视图:描述程序运行期的进程、线程、对象实例,以及与此相关的并发、同步、通信等问题。处理架构是考虑一些非功能性的需求,例如性能和可用性可扩展性Scalable。它可以解决并发性和分布系统的完整性与容错性等问题,主要指导如何从逻辑视图的抽象融入处理架构之中,比如哪个线程来控制对象的实际执行。

物理视图:描述软件如何安装并部署到物理的服务上,以及不同的服务器之间如何关联、通信。主要考虑系统的非功能性需求,如可用性、可靠性(容错)、性能(吞吐量)和可伸缩性。

场景视图:针对具体的用例场景,将上述 4 个视图关联起来,一方面从业务角度描述,功能流程如何完成,一方面从软件角度描述,相关组成部分如何互相依赖、调用。四个视图中的元素通过场景能够一起无缝工作,场景对应着用例,它实现上对应相应的脚本(流程),也就是对象之间的序列交互,使用对象场景图和对象交互图来表示

C4视图

架构师修炼之道学习笔记_第15张图片

类Classes:软件系统的最小构建块

组件Component:由一个或者多个类组成的逻辑组,由许多相互协作的类组成,位于高层协议下面。

容器Containers:表示组件运行或者驻留的地方。

系统System:是高层抽象

架构评估

架构师修炼之道学习笔记_第16张图片 

架构设计实践模型

架构师修炼之道学习笔记_第17张图片

参考资料:

https://www.jdon.com/artichect/4+1view-architecture.html

https://blog.csdn.net/weixin_42248522/article/details/123381118

你可能感兴趣的:(架构,大数据)