从0学架构01--架构到底是什么?

       

目录

1、系统和子系统

2、模块和组件

3、框架和架构

4、4R架构

5、总结


         按照百度百科的解释是:架构,又名软件架构是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。从这个定义来看,它是一个设计,那么我们在实际的软件开发过程中,我们谈的架构,它的范围又是怎样的呢?他跟框架有什么关系?接下来我们详细解释如下几个概念和概念之间的关系。

  • 系统与子系统
  • 模块与组件
  • 框架与架构

1、系统和子系统

什么是系统:

维基百科定义的系统:系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。它的意思是总体”“整体联盟

  1. 关联:系统是由一群有关联的个体组成的,没有关联的个体堆在一起不能成为一个系统。例如,把一个发动机和一台 PC 放在一起不能称之为一个系统,把发动机、底盘、轮胎、车架组合起来才能成为一台汽车。
  1. 规则:系统内的个体需要按照指定的规则运作,而不是单个个体各自为政。规则规定了系统内个体分工和协作的方式。例如,汽车发动机负责产生动力,然后通过变速器和传动轴,将动力输出到车轮上,从而驱动汽车前进。
  1. 能力:系统能力与个体能力有本质的差别,系统能力不是个体能力之和,而是产生了新的能力。例如,汽车能够载重前进,而发动机、变速器、传动轴、车轮本身都不具备这样的能力。

什么是子系统:

维基百科定义:子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分

其实,子系统的定义和系统定义是一样的,只是观察的角度有差异,一个系统可能是另外一个更大系统的子系统。

按照这个定义,系统和子系统比较容易理解,我们以微信为例来做一个分析:

  1. 微信本身是一个系统,包含聊天、登录、支付、朋友圈等子系统。
  1. 朋友圈这个系统又包括动态、评论、点赞等子系统。
  1. 评论这个系统可能又包括防刷子系统、审核子系统、发布子系统、存储子系统。
  1. 评论审核子系统不再包含业务意义上的子系统,而是包括各个模块或者组件,这些模块或者组件本身也是另外一个维度上的系统。例如,MySQL、Redis 等是存储系统,但不是业务子系统。

一个系统的架构,只包括顶层这一个层级的架构,而不包括下属子系统层级的架构。所以微信架构,就是指微信系统这个层级的架构。当然,微信的子系统,比如支付系统,也有它自己的架构,同样只包括顶层

2、模块和组件

从业务逻辑的角度来拆分系统后,得到的单元就是模块;从物理部署的角度来拆分系统后,得到的单元就是组件。划分模块的主要目的是职责分离;划分组件的主要目的是单元复用。

其实,“组件”的英文 Component 也可翻译成中文的“零件”一词。“零件”更容易理解一些,它是一个物理的概念,并且具备“独立且可替换”的特点。

我以一个最简单的网站系统来为例。假设我们要做一个学生信息管理系统,这个系统从逻辑的角度来拆分,可以分为“登录注册模块”“个人信息模块”和“个人成绩模块”;从物理的角度来拆分,可以拆分为 Nginx、Web 服务器和 MySQL。

如果你是业务系统的架构师,首先需要思考怎么从业务逻辑的角度把系统拆分成一个个模块角色,其次需要思考怎么从物理部署的角度把系统拆分成组件角色,例如选择 MySQL 作为存储系统。但是对于 MySQL 内部的体系架构(Parser、Optimizer、Caches&Buffers 和 Storage Engines 等),你其实是可以不用关注的,也不需要在你的业务系统架构中展现这些内容。

模块:

从0学架构01--架构到底是什么?_第1张图片

组件:

从0学架构01--架构到底是什么?_第2张图片

3、框架和架构

框架是一整套开发规范,架构是某一套开发规范下的具体落地方案,包括各个模块之间的组合关系以及它们协同起来完成功能的运作规则。

44R架构

软件架构指软件系统的顶层(Rank)结构,它定义了系统由哪些角色(Role)组成,角色之间的关系(Relation)和运作规则(Rule)。

从0学架构01--架构到底是什么?_第3张图片

第一个 R,Rank。它是指软件架构是分层的,对应“系统”和“子系统”的分层关系。通常情况下,我们只需要关注某一层的架构,最多展示相邻两层的架构,而不需要把每一层的架构全部糅杂在一起。无论是架构设计还是画架构图,都应该采取“自顶向下,逐步细化”的方式。以微信为例,Rank 的含义如下所示:

从0学架构01--架构到底是什么?_第4张图片

第二个 R,Role。它是指软件系统包含哪些角色,每个角色都会负责系统的一部分功能。架构设计最重要的工作之一就是将系统拆分为多个角色。最常见的微服务拆分其实就是将整体复杂的业务系统按照业务领域的方式,拆分为多个微服务,每个微服务就是系统的一个角色。

第三个 R,Relation。它是指软件系统的角色之间的关系,对应到架构图中其实就是连接线,角色之间的关系不能乱连,任何关系最后都需要代码来实现,包括连接方式(HTTP、TCP、UDP 和串口等)、数据协议(JSON、XML 和二进制等)以及具体的接口等。

第四个 R,Rule。它是指软件系统角色之间如何协作来完成系统功能。我们在前面解读什么是“系统”的时候提到过:系统能力不是个体能力之和,而是产生了新的能力。那么这个新能力具体如何完成的呢?具体哪些角色参与了这个新能力呢?这就是 Rule 所要表达的内容。在架构设计的时候,核心的业务场景都需要设计 Rule。

5、总结:

架构是顶层设计;框架是面向编程或配置的半成品;系统是相互协同可运行的实体;子系统是实体内部的一部分;组件是从技术维度上的复用;模块是从业务维度上职责的划分;

内容来源:学习极客时间课程整理。

你可能感兴趣的:(架构以及设计模式,架构,从零学架构,4R架构)