系统架构系列(一):如何用公式定义该概念?

阅读数:11940 2019 年 6 月 17 日 08:30

系统架构系列(一):如何用公式定义该概念?

系统架构概念非常大,谈论时显得虚无飘渺,它不像一个具体的技术点能很好地衡量掌握了没有。系统架构的定义有很多,问不同的人得到的回答也不一样,这也越发让人迷惑:到底什么是系统架构。本篇文章没有太高深的理论,从推导系统架构的公式开始,层层铺进、环环相扣,揭开系统架构的神秘面纱。

系统架构系列(一):如何用公式定义该概念?

一、推导系统架构的公式

1.1 系统架构概念拆分

在学习一门技术的时候,一定要知道是什么、为什么、怎么做。系统架构这个概念本身就非常大,而且有各种各样的定义,初学者会遇到这样的困境:到底什么是系统架构?不管什么样的定义,笔者相信知识只有内化成为自己的才最重要,否则我们只是不断地输入而没有消化。先不看之前的定义是什么,从 " 系统架构 " 这四个字开始推导其公式。

" 系统架构 " 可以拆分成两部分:“系统 " 和 " 架构”。“系统 " 在百科中的定义是" 系统就是若干相互联系、相互作用、相互依赖的要素结合而成的,具有一定结构和功能,并处在一定环境下的有机整体”,从这句话可以提炼出两点内容:一是整体与部分 (由要素结合而成的)二是结构性 (具有一定的结构和功能)。所以谈系统一定具有多个组成部分,并且这些部分是相互作用的,这点非常重要。

再看架构在百科中的定义是" 架构,又名软件架构,是有关软件整体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计 "。初看到这个定义,从中获取的有效信息不大,只知道这个很厉害,用于指导大型软件系统各个方面的设计。细细分析,它又和系统有类似表述,有一个重要的词是抽象描述,换言之,架构是把系统中的整体结构和组件之间的关系体现出来。

至此,总结出第一个结论:系统架构是描述系统要素之间的关系

1.2 系统架构公式

接着上文再深入分析什么是系统架构,理解系统的概念没有什么疑问,在架构上还是有点迷糊。没关系,换个角度再看。架构又拆分成两个字 " 架 " 和 " 构 ",“架 " 就是 " 加 " 和 " 木”,它源于建筑领域,把木头连接起来就是架," 构 " 就是结构的意思。

所以," 架构 " 就是把 " 木 " 按照一定的结构连接起来。到这里,系统架构的公式已经呼之欲出,先不急给出公式,还有几个问题没有理清楚:

  • 什么是木?
  • 结构是什么?
  • 如何连接?

刚才说了,架构源于建筑,结合软件中的系统架构来回答上面的几个问题:

  • “木 " 就是系统中的要素,这个很容易推导出来的,既然是 " 加”,肯定不只一个," 系统 " 是 " 架构 " 的修饰词,换言之,所谓的系统架构就是把 " 系统 " 架构出来," 系统 " 又由各个要素组成,所以这里的 " 木 " 就是系统中的要素。
  • " 结构 " 是架构的产物,建筑是有结构的,往深层次想为什么不同的建筑有不同的结构,就是为了解决不同场景的问题,所以系统架构是为了解决实际问题而设计的。
  • " 连接 " 是过程,把 " 木 " 有机的连接起来。实施过程是有一定的方法,并不是随意地连接。

到这里,总结出第二个结论,给出系统架构的公式, 系统架构 = 要素 + 连接 + 解决特定问题

1.3 深入系统架构公式

上面已经给出系统架构的公式,用文字来表述就是系统架构是为了解决特定的问题,把系统中的要素找出来,通过一定的手段把这些要素组合起来

那么问题又来了:解决特定的问题是什么、系统的要素又是什么、如何把要素组合起来,回答了这三个问题,系统架构就非常清晰了。

  • 解决特定的问题:这个就是需求、矛盾,就是当前我们不具备的。抓住当前的主要矛盾是什么。举个简单的例子,在高并发场景下,如果查库非常多,之前是单台数据库 (读写在一起),这时的矛盾就是单台数据库不足以支持高并发场景下同时读写。矛盾不同,解决的方法、思路也不同,关键是找到主要矛盾。

  • 系统要素:这里的要素得分类看待,系统架构其实是有分类的,如业务架构、应用架构、技术架构、数据架构、安全架构等,这里要素就是分类中的内容,还是拿上面的例子来看,它是技术架构,要素就是数据库。如果是业务架构,要素就是业务的组成元素,通过业务流程进行分解,找出业务领域对象就是要素。

  • 要素组合:组合是为了解决特定的问题,把要素按照一定规则连接起来,上面的例子之前是单台数据库,现在按照读写进行分离解决问题,从库通过 binlog 同步主库数据。一般而言,组合是按照层次特性来组合的。

二、系统架构分类

2.1 谈系统架构要指定类型

平时我们在谈论系统架构时一定要指定类型,如业务架构还是技术架构还是其它类型的架构,要不然,别人跟你讲业务架构,但你期望的是技术架构,这样两个认识就不一样,这也是初学者比较困惑的地方,看到的和自己理解的不一样。不同的架构类型侧重点是不一样的,这个具体在下一节中讲到。

总结出第三个结论:谈系统架构一定要指定类型,否则两个认识就不一致

2.2 系统架构分类

系统架构有不同的分类,之所以有这些分类,是为了站在不同的角度去看系统,这样就可以更全面、更深入地了解和理解系统,从而设计出来的系统满足需求。系统架构并不虚,它不仅从最顶层考虑系统,而且在关键实现上也有考虑。

系统架构和我们学的函数很相似,y =f(x), y 就是架构的产物,f() 就是思考、设计的过程,x 就是系统要素。从这一点看和上面提到的公式很像,本质来讲就是为了解决特定问题而进行的架构设计。

一般架构分为:业务架构、应用架构、数据架构、技术架构、安全架构、部署架构。TOGAF 对下面四种架构有如下描述:

业务架构 : 定义业务战略、治理、组织和关键业务流程。

数据架构 : 描述组织的逻辑与物理数据资产及数据管理资源的结构。

应用架构 : 应用之间结构和交互的描述。

技术架构 : 描述支持业务、数据和应用服务部署所需的逻辑的软件与硬件能力,包括 IT 基础设施、中间件、网络、通信、处理和标准等。

所以,聊系统架构要指定架构类型,因为不同的架构类型侧重点不一样,明显的业务架构和技术架构就不一样,业务架构偏重的是业务愿景、业务价值、业务流程;而技术架构偏重的是运用哪些技术组件来解决实际问题。

三、系统架构的特性

基本上到这里,对系统架构没有之前的混沌认识,通过一个简单的公式可以知道系统架构是什么。上面也说了系统架构有不同的分类,但本质来讲还是叫系统架构,那么,系统架构的物性是什么呢?

从上面的公式出发:系统架构 = 要素 + 连接 + 解决特定问题,解决特定问题是目标,所以,系统架构具有很强的目标性;要素是系统组成部分,体现了整体与部分的关系,表明系统架构具有可分解的特性;连接是把拆分的要素再有机的组装出来,这里组装不是简单的还原,是有一定的抽象在里面,是按照一定层次来抽象的,体现了系统架构的层次性。总结如下:

  • 目标性:目标是我们的灯塔,指引我们向什么方向走。
  • 可分解性:这与分而治之是一样的意思,不管是系统架构在设计还是实施都具有可解性,一方面不同的人可以专注于某一方面深入研究;另一方面是可以并行工作,提升效率。
  • 层次特性:层次特性是系统架构的基本特性,像网络协议、计算机系统结构,都是有一定的层次的,所以系统架构也有这样的层次。比如在业务架构中,笔者习惯按场景层、业务能力层、业务模型层、依赖层来划分。

从系统架构的特性反过来可以帮助进行更好的架构设计,好的系统架构设计一定有序的,不好的系统架构一定是混沌的。

四、系统架构各家之言

提出一种方法并非标新立意,其实很多东西在本质上是一样的,只是表述不一样,表述不一样是为了更好的让人去理解。上面提到了系统架构 = 要素 + 连接 + 解决特定问题,现在看看其它的定义是什么:

  • 软件系统架构是将系统描述为计算机组件及组件之间的交互
  • 软件架构是在一些重要方面所做的决策的集合
  • 软件架构是分和合的过程

再去想想这些定义,可能你会有新的想法。

五、小结

这篇文章只是系统架构的开篇,重点讲解系统架构是什么,系统架构被误解成很虚的东西,笔者把它简化成一个公式来理解,虽然在这里并没有告诉如何去实践,但是理解清楚这个概念往下推导如何做就会水到渠成,接下来的系列就是讲解系统架构如何去落地实践。

作者简介

高福来,目前在滴滴小桔车服加油团队负责营销基础 (优惠券、奖励金),在分布式中间件和系统架构方面积累了一定的经验,擅长用通俗易懂的语言描述复杂问题。

评论

发布
用户头像
”知识只有内化成自己的才是最重要的“,深有同感
2019 年 07 月 16 日 10:17
回复
没有更多了