思考软件架构的本质

架构是什么?

架构起源于建筑领域,比如架桥,建房子,打地基。
充满智慧的古代劳动人民将复杂的建筑按其特点分解为一个个具有共性的结构构件,
同样的,软件也是一样的,
只要是人们主观的对其进行分解和组装,就运用了架构的概念。
在这里插入图片描述

下面来谈谈软件架构

软件架构是软件工程师在设计一个软件系统时,定义系统架构的一种科学方法。
它指的是软件系统在软件工程师关注功能,性能和安全质量属性的条件下,组织系统的方式。
换句话说,软件架构是一种把软件系统划分为模块,以实现特定功能的技术手段。
在这里插入图片描述

1:软件架构主要由三个要素组成
模块结构:模块结构是把软件系统划分为不同的模块的一种结构,以实现特定功能

框架结构:框架结构是把软件系统的各个模块按照一定的组织形式组织起来的一种结构,以实现特定功能。

组件结构:组件结构是把软件系统由不同的组件组成的一种结构,
以实现特定功能

2:架构分层
2.1:业务架构
包括业务规划,业务模块,业务流程,对整个系统的业务拆分,对领域模型进行涉及,把现实的业务转化成抽象对象

没有最优的架构,只有最合适的架构,一切系统的设计原则都要以解决业务问题为最终目标,脱离实际业务的技术情怀架构往往会给系统带入大坑。

要搞清楚业务量有多大,增长走势是什么样,而且解决高并发的过程,一定是一个循序渐进逐步的过程。
在这里插入图片描述

2.3:应用架构
硬件到应用的抽象,包括抽象层和编程接口。应用架构和业务架构是相辅相成的关系。业务架构每一部分都有应用架构
在这里插入图片描述
应用架构作为独立部署的单元,为系统划分了明确的边界,深刻影响系统功能组织,代码开发,部署和运维等各方面,应用架构定义系统有哪些应用,以及应用如何分工和合作

2.3:数据架构
数据架构指导数据库的设计. 不仅仅要考虑开发中涉及到的数据库,实体模型,也要考虑物理架构中数据存储的设计。

在这里插入图片描述

2.4:代码架构

①. 代码单元

配置设计

框架、类库。

②. 代码单元组织

编码规范,编码的惯例。

项目模块划分

顶层文件结构设计,比如mvc设计。

依赖关系

在这里插入图片描述
2.5. 技术架构

技术架构:确定组成应用系统的实际运行组件(lvs,nginx,tomcat,php-fpm等),这些运行组件之间的关系,以及部署到硬件的策略。

技术架构主要考虑系统的非功能性特征,对系统的高可用、高性能、扩展、安全、伸缩性、简洁等做系统级的把握。

系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识,这也是架构设计工作中最为困难的工作。

2.6. 部署拓扑架构图(实际物理架构图)

拓扑架构,包括架构部署了几个节点,节点之间的关系,服务器的高可用,网路接口和协议等,决定了应用如何运行,运行的性能,可维护性,可扩展性,是所有架构的基础。这个图主要是运维工程师主要关注的对象。
在这里插入图片描述
物理架构主要考虑硬件选择和拓扑结构,软件到硬件的映射,软硬件的相互影响。

3: 架构的级别
系统级:即整个系统内各部分的关系以及如何治理:分层

应用级:即单个应用的整体架构,及其与系统内单个应用的关系等。

模块级:即应用内部的模块架构,如代码的模块化、数据和状态的管理等。

代码级:即从代码级别保障架构实施。

4:战略设计与战术设计

基于架构金字塔,我们有了系统架构的战略设计与战术设计的完美结合:

战略设计:业务架构用于指导架构师如何进行系统架构设计。

战术设计:应用架构要根据业务架构来设计。

战术实施:应用架构确定以后,就是技术选型。

架构是系统性的思考,权衡利弊之后现有资源约束下的最合理的决策,最终明确系统骨架:包括子系统,模块,组件以及他们之间的协作关系
约束规范,直到原则,涉及4个方面:
01:系统性思考的合理决策:比如技术选型,解决方案等等

02:明确的系统骨架:明确系统有哪些部分组成。

03:系统协作关系:各个组成部分如何协作来实现业务请求

04:约束规范和指导原则:保证系统有序,高效,稳定的运行。

猜你喜欢

转载自blog.csdn.net/weixin_49543015/article/details/131244258
今日推荐