系统架构系列(一)：系统架构概念、分类和特性

一、推导系统架构的公式

1.1 系统架构概念拆分

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

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

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

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

1.2 系统架构公式

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

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

什么是木？
结构是什么？
如何连接？

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

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

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

1.3 深入系统架构公式

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

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

解决特定的问题：这个就是需求、矛盾，就是当前我们不具备的。抓住当前的主要矛盾是什么。举个简单的例子，在高并发场景下，如果查库非常多，之前是单台数据库 (读写在一起)，这时的矛盾就是单台数据库不足以支持高并发场景下同时读写。矛盾不同，解决的方法、思路也不同，关键是找到主要矛盾。
系统要素：这里的要素得分类看待，系统架构其实是有分类的，如业务架构、应用架构、技术架构、数据架构、安全架构等，这里要素就是分类中的内容，还是拿上面的例子来看，它是技术架构，要素就是数据库。如果是业务架构，要素就是业务的组成元素，通过业务流程进行分解，找出业务领域对象就是要素。
要素组合：组合是为了解决特定的问题，把要素按照一定规则连接起来，上面的例子之前是单台数据库，现在按照读写进行分离解决问题，从库通过 binlog 同步主库数据。一般而言，组合是按照层次特性来组合的。

二、系统架构分类

2.1 谈系统架构要指定类型

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

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

2.2 系统架构分类

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

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

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

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

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

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

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

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

三、系统架构的特性

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

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

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

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

四、系统架构各家之言

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

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

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

五、小结

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