写点什么

一文看懂什么是架构

作者:EquatorCoco
  • 2024-09-12
    福建
  • 本文字数:2778 字

    阅读完需:约 9 分钟

对程序员来说,架构是一个常见词汇。如果想成为一名架构师,对架构概念的理解必须清晰。否则,在制定架构方案时,肯定会漏洞百出,问题频发,这将对你的面试、晋升和团队领导产生负面影响。


我们看下维基百科关于架构的定义:


软件架构是抽象描述系统的一组结构,以及构建这些结构的规则。这些结构包括:软件要素、要素之间的关系以及它们的属性。


在这个定义中,核心概念为系统、要素、关系。


系统


在软件架构中,"系统"是指由多个相互作用的部分组成的复杂整体,这些部分共同完成特定的功能或任务,而架构设计就是对某个系统的抽象描述。


要素


“要素”是构成系统的基本单元,通常有子系统、模块、组件。


  • 子系统是一个较大系统的一部分,具有特定的功能责任,通常可以独立于整个系统操作。每个子系统可以包含多个模块或组件,且通常围绕特定的业务领域或技术功能进行组织。


  • 模块是软件架构中的逻辑单元,它封装了一组相关的功能或服务。模块通常通过定义良好的接口与其他模块交互,支持高内聚和低耦合的设计原则。


  • 组件是自包含的、可编程的、可重用的、与语言无关的软件单元,软件组件可以很容易被用于组装应用程序中,是可以独立完成部署的最小单元。


可能有人对模块、组件的概念比较懵。简单来说,模块是从业务逻辑维度上的划分,组件是从技术维度上的复用。下面还会用一个例子说明它们的区别。


关系


”关系“指的是系统中各个要素(如子系统、组件、模块、类等)之间的连接和交互方式。这些关系定义了要素如何协作,以及它们如何共同实现系统的功能。


我们以新零售 SaaS 系统为例,解释一下各个概念:


  • 子系统包括:线上商城子系统、POS 收银子系统、订单管理子系统、商品管理子系统、客户管理子系统、仓储管理子系统、配送子系统、中央库存子系统、客服子系统、采购子系统等。


  • 订单履约系统,从业务维度可划分为以下模块:C 端履约服务模块、订单派单模块、订单管理模块、拣货管理模块、发货管理模块、逆向履约模块等。


  • 订单管理模块从技术维度上,依赖 Mysql、Redis、Elasticsearch、安全组件等技术组件。


  • 各子系统、各模块、各组件都可能产生关系,通过协作关系共同完成系统功能。


架构的视图与视角


在工作当中,我们经常会听到以下说法:


  • 产品负责人说,现在的业务架构太复杂,需要仔细梳理一下。

  • 技术领导说,这个项目很复杂,需要做下架构方案评审。

  • 研发经理说,这次秒杀活动方案,需要用到高并发架构方案。

  • 一线研发说,互联网大厂都会用到微服务架构,我要学好微服务。


上面提到的架构到底是指什么?这些说法究竟对还是错?


其实上面的说法都是对的,只是采取的视角不一样。


因为复杂系统涉及的利益干系人众多,例如:客户、产品经理、研发、销售、运营、管理层等。由于背景不同,认知不同,每个人看待系统的角度、方法都不相同。


为了控制复杂度,我们需要设计一整套架构描述物,并且为它们做好分类和定义,让每种架构描述物都有自己的侧重,让每个利益干系人都能快速获取关注的信息。


为了达成这个目标,首先需要理解视图与视角的概念。


架构视角


什么是视角?大白话就是你站在什么地方看。


我们以城市系统为例,你站在城市的某条马路上,能看到什么?


能看到几座楼房,几排树木,几条大马路,熙熙攘攘的一些人。


但是你坐在飞机上看,能看到什么?


能看到一片片的楼盘,能看到群山,能看到江河湖海。所以,你能看到什么和你站在什么地方看有很大关系,同时也会影响你看待事物的粒度。


如果把视角比作一个坐标点,那它需要一套坐标系,坐标系通常有 4 个维度:广度、深度、视图类型、时间。


广度是指看待事物的宽度,以业务流程为例,根据出发点不同,有时需要看一个部门内的流程,有时需要看多个部门的协作流程,有时需要看端到端跨部门的流程。


深度是指看待事物时,要到达哪个细节层次,例如看业务流程,需要看到组织级、部门级、还是某个岗位的具体操作步骤。看软件系统,需要看到系统级、模块级、还是一行行的代码。


广度和深度一般是相互影响的,如果看待事物的广度越宽,那么层次就会越抽象,这和组织架构的设计也是相辅相成的,一般高层管理者看问题非常全面,但对细节不关注,一线执行人员,对问题的细节非常了解,但视角却非常窄。


视图类型是为利益干系人量身打造的一组关注点的集合,下文中会详细介绍。


时间维度比较好理解,就是看待事物的时间点,过去、现在、还是未来。



架构视图


什么是视图?大白话就是你想看到什么。


视图是为利益干系人量身打造的一组关注点的集合。


同样以城市系统为例,想要赶早高峰的上班族,他的关注点是哪条路线最快,因此他需要一副地铁公交路线图。


想要租房的租客,他的关注点是公司附近有哪些小区,租金多少,因此他需要一副租房地图。


同一个城市系统,不同角色的关注点是完全不一样的,想要获取的信息也是完全不一样,如果把所有信息杂糅在一起,不做视图隔离,导致的结果就是信息太庞杂,每个人都很难获取想要的信息。


同理,不同干系人看待软件系统的关注点也是迥然不同的,为了把不同人的关注点区分开,诞生了很多软件视图的分类方法,比较著名的有“4+1”视图,TOGAF 的业务架构、应用架构、数据架构、技术架构等视图分类法。


我们重点说下 TOGAF 的视图类型:业务架构,应用架构,数据架构,技术架构。


其中业务架构是灵魂,应用架构,数据架构,技术架构都是支撑业务架构而存在的,后三者也统称 IT 架构。



  • 业务架构:为了实现企业的业务战略,企业将自身业务结构化表达为全面的、多维度的抽象模型,包括:业务能力、端到端的价值交付、信息和组织结构,它们之间的关系,以及它们与战略、产品、策略、项目执行、利益干系人之间的关系。


  • 应用架构:基于业务架构,设计出应用系统的层次结构,包括系统、应用、模块、组件等构件的划分规范,它们的定义、边界、相互间的交互协议,以及它们和业务活动的关系。


  • 数据架构:数据架构描述了一系列的模型、策略、规则、标准,它们决定数据如何获取、如何存储、如何分布、如何集成,以及数据如何在系统和组织中使用。数据架构是企业架构中非常重要的一块架构领域,通常包括 3 个架构过程,概念模型设计(设计业务概念模型)、逻辑模型设计(设计模型间的逻辑关系与自身属性)、物理模型设计(设计数据的技术实现细节)。


  • 技术架构:技术架构描述了一系列的可部署的软件包、硬件能力,以及它们之间的协作关系,通过它们可以支撑起企业对业务、数据、应用服务的需求,它们包括但不限于 IT 基础设施、中间件、网络、通信设施、运算能力、硬件标准等。


通过视图与视角,我们可以分离关注点,将复杂问题进行拆解,让每个局部的复杂度控制在一个可以接受的范围。


同时,团队有了统一的认知坐标系,进一步促成了业务标准化,以业务标准化为基础,通过分离不变点与变化点,提炼出可复用的组件,快速响应业务需求变化。


文章转载自:架构师汤师爷

原文链接:https://www.cnblogs.com/tangshiye/p/18409014

体验地址:http://www.jnpfsoft.com/?from=infoq

用户头像

EquatorCoco

关注

还未添加个人签名 2023-06-19 加入

还未添加个人简介

评论

发布
暂无评论
一文看懂什么是架构_架构_EquatorCoco_InfoQ写作社区