软件架构师的角色
架构师的职责
软件架构的组成
模块结构存在于设计阶段,组件连接器结构在软件运行时出现,分配结构展示模块元素与组件连接器元素之间,以及这些元素与现实的物理元素之间的协同与响应关系
软件架构的意义
是开发出色软件的基础。架构从以下六个方面有指导意义
架构设计思维
设计策略
首先挖掘关键架构需求
主动选择架构
架构模式
模式 | 元素 | 关系 | 优点 | 缺点 |
分层模式 | 层:一组功能内聚的模块 | 哪些层可以使用其他层的模块 | 可运维性,可移植性,可复用性,可测试性,设计阶段的可修改性,概念上比较容易实施 | 每一层都引了额外的抽象,增加了复杂度,可能会影响性能,层数繁多和抽象泄露可能导致开发过程非常痛苦 |
端口适配器模式 | 层:包含业务逻辑,便它不清楚使用的数据和事件的来源 端口:层与适配器之间的接口。借助端口,层可以与具体的适配器分离 适配器:与外部数据源,设备或其他组件进行交互的代码,使得层能够访问数据和事件。 | 暴露:指明层可用的端口 实现:指明约束适配器的端口 注入:指明层可用的适配器 | 提升可测试性,可维护性,可修改性。团队可以分工完成不同的层和适配器 | 必须建立机制选择运行时使用的适配器。适配器决定了运行时质量。 |
管道过滤器模式 | 过滤器:读取,转换,记录数据的组件。过滤器必须定义预期输入并输出结果 管道:连接器,用于将数据从一个过滤器传输到下一个过滤器。管道具有单一输入和输出,不会改变传输的数据 一些变种还包含元素源(source)和槽(sink)。前者产生数据,后者仅接收数据 | 接驳:通过管道,连接一个过滤器的输出与另一个过滤器的输入 | 提升性能,可复用性,可修改性 | 管道过滤器系统不是交互式的。不会明显提升可靠性,可能会影响性能。 |
面向服务架构模式 | 服务:可独立部署的单元。通过定义好的接口提供服务功能 服务注册表:列出所有可用的服务,以便服务可查找其他可用服务 消息系统:取决于具体的系统设计 | 根据SOA系统的约束而变化。可能是调用,可能是发布,订阅 | 提升互用性,可复用笥,可伸缩性。 | 带有分布式计算的所有复杂性。集成复杂。 |
发布订阅模式 | 发布者:发布事件的组件 订阅者:订阅事件的组件 事件总线:负责登记组件订阅和传递发布的事件。 | 发布:组件装饰事件发布到事件总线 订阅:组合登记订阅事件 | 提升可扩展性,可复用性,可测试性,可用性,可靠性,可伸缩性 | 性能很难判断 |
共享数据模式 | 数据库:保存访问器共享的数据 数据访问器组件:以某种方式使用数据的组件 | 读取:数据访问器组件可以从共享数据库中读取数据。 写入:数据访问器组件将数据写入共享数据库 | 通过数据一致性、安全和隐私提升可靠性。如果数据库充分优化,数据访问器划分良好,也可以提升可伸缩性和可用性 | 单点故障,影响可用性和性能。如果数据库发生变更,可维护性也会受影响。 |
多层模式 | 层(tier):运行时组件的逻辑组。 | 属于:将组件归到某一层 通信:层或其内部组件与其他层的交互 允许通信:表明哪些层可以与其他层中的组件通信 分配到:将层映射到物理计算平台 | 提升安全性,性能,可用性,可维护性,可修改性,有利于分析成本和部署 | 作为运行时构造,在大型系统中实施可能会有难度,太多的层可能会抑制系统性能和可维护性。 |
能力中心模式 | CoC团队:开发人员和架构师小组 责任区域:架构的子集,可以是模式,技术,用例 | 负责:聚首CoC团队及其责任区域 | 提升专家的可复用性和可伸缩性,从而提升多方面的质量属性。 | CoC让一些专家形成了知识上的孤岛,且容易因人员流失而出现知识流失,能力不足的CoC成员会引发问题,影响开发质量。 |
开源贡献模式 | 团队:提交或审核组件变更的小组 库:包含软件组件的版本普瑞玛存储率 | 拥有:团队负责审查变更并维护库的完整性。 可能贡献:表示可能向库提交变更的团队 | 提升可复用笥,可维护性,开发速度 | 与组件划分策略密切相关。在多数情况下,贡献的学习曲线极其陡峭,这种模式不太现实 。 |
大泥球模式 | 无 | 无 | 短期内提高开发速度 | 降低系统的可维护性,可扩展性,缺少设计的完整性,毫无章法的开发和缺乏架构知识 |
分层模式与多层模式的区别:
- 分层模式是模块结构,处理设计时元素,多层模式是组件连接器结构或者分配结构,处理运行时元素
建立模型
架构设计研讨会
架构设计研讨会流程
阶段内容
1、准备:提前了解要探索的问题
2、启动:向团队介绍研讨会的目标和问题背景
3、创建:制作模型,绘制草图,构建原型
4、分享:展示创建的内容,并具体描述设计如何实现目标
5、评判:团队对分享的内容进行评判,就设计能否完成目标发表意见
6、迭代:重复第3到5步,优化模型,创建新模型。
7、跟进:针对发现的想法,风险,问题决定后续处理步骤
展示设计决策
描述架构
4+1视图
逻辑视图:描述软件的功能逻辑,由哪些模块组成,模块中包含哪些类,其依赖关系如何。逻辑视图主要支持功能需求,也就是系统应该提供怎样的服务给用户。系统分解为一组关键抽象,如问题域的对象或对象类的形式。利用封装和继承的抽象原则。分解不仅是为了功能分析,也为了识别常见的服务机制和跨系统的设计元素。我们可以使用UML类图和类模板代表逻辑视图的方法
开发视图:包括系统架构层面的层次划分,包的管理,依赖的系统与第三方的程序包。开发视图某些方面和逻辑视图有一定重复性,不同视角看到的可能是同一个东西,开发视图中一个程序包,可能正好对应逻辑视图中的一个功能模块。开发视图关注实际的软件开发环境中的软件模块组织。软件打包可以小程序库或子系统等形式,子系统是由一个或少量的开发人员开发的系统。子系统有良好的组织层次结构,每一层都提供了一个狭窄的和良好定义的接口层。开发系统是由模块和子系统的架构组成的,表达了"出口"和"进口"的关系
处理视图:描述程序运行期的进程、线程、对象实例,以及与此相关的并发、同步、通信等问题。处理架构是考虑一些非功能性的需求,例如性能和可用性可扩展性Scalable。它可以解决并发性和分布系统的完整性与容错性等问题,主要指导如何从逻辑视图的抽象融入处理架构之中,比如哪个线程来控制对象的实际执行。
物理视图:描述软件如何安装并部署到物理的服务上,以及不同的服务器之间如何关联、通信。主要考虑系统的非功能性需求,如可用性、可靠性(容错)、性能(吞吐量)和可伸缩性。
场景视图:针对具体的用例场景,将上述 4 个视图关联起来,一方面从业务角度描述,功能流程如何完成,一方面从软件角度描述,相关组成部分如何互相依赖、调用。四个视图中的元素通过场景能够一起无缝工作,场景对应着用例,它实现上对应相应的脚本(流程),也就是对象之间的序列交互,使用对象场景图和对象交互图来表示
C4视图
类Classes:软件系统的最小构建块
组件Component:由一个或者多个类组成的逻辑组,由许多相互协作的类组成,位于高层协议下面。
容器Containers:表示组件运行或者驻留的地方。
系统System:是高层抽象
架构评估
架构设计实践模型
参考资料:
https://www.jdon.com/artichect/4+1view-architecture.html
https://blog.csdn.net/weixin_42248522/article/details/123381118