系统架构系列之用公式定义概念

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

一、推导系统架构的公式

1.1 系统架构概念拆分

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

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

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

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

1.2 系统架构公式

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

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

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

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

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

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

1.3 深入系统架构公式

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

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

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

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

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

二、系统架构分类

2.1 谈系统架构要指定类型

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

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

2.2 系统架构分类

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

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

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

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

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

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

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

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

三、系统架构的特性

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

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

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

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

四、系统架构各家之言

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

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

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

一、系统架构的本质目的

我们已经知道系统架构是什么，有必要讲一下系统架构的目的，即为什么要进行系统架构。对于简单的系统而言，可能没有什么所谓的系统架构，这里的 " 没有 " 可能对我们来讲是常识，如简单的系统分层。系统架构的本质目的从公式定义中就可以看出：解决特定的问题，这个特定的问题有技术上的问题、业务上的问题、项目管理上的问题。

还有一个问题不知道开发者是否注意到：怎么知道自己的架构设计是对的？这个问题很尖锐，架构设计具备严谨的逻辑性，从逻辑上讲是对的，实现起来基本上八九不离十，再根据实际使用情况做出调整。所以，系统架构从本质上讲具备逻辑性，虽然还没有真正实践，但从架构方案上能看得出是否合理、正确。

结论一：系统架构的本质目的就是解决问题和具备逻辑性。

二、系统架构的难点

系统架构并不是任何初学者都可以一学就会的概念，它具备一定要求，所以这里说的难点换个角度就是要掌握的能力。

2.1 技术上的难点

技术上的难点对于开发来讲比较好理解，在有些场景下，技术会成为架构的难点之一，如笔者之前在阿里店铺团队，双 11 高达十几万的 QPS，如果处理不当，可能就会导致访问的店铺页面打不开。所以，对于高并发场景，我们面临很多挑战，以下列举常见的技术难点：

• 高并发场景：有限的资源应对大量请求。
• 高可用场景：即使在极端条件下，强调系统的可用性。
• 高扩展场景：如何应对变化的问题，以最少的代价支撑业务发展。
• 分布式一致性场景：一致性问题在分布式场景下经常遇到，选用哪种技术方案要结合当前的业务、条件来选择。
• 高性能场景：快速地处理请求。
• …

技术上可以有意识地在平时去总结、练习，每种问题都应该有一套立体化的解决方法而不是一个散点去应对，如高并发场景，有些同学立马说用缓存、用消息队列等，这些只是手段，如果从本质问题出发，在每个环节上思考如何去做，这样就会提出系统性的解决方案，这一点会在后续文章中展开说明。

2.2 业务上的难点

有些业务是非常复杂的，不是简单的 CRUD，涉及到的链路非常长、涉及到的业务关联方也非常多，很有可能一个系统的代码行数超过 100 万，还包括很多历史逻辑在里面，这个在新业务中出现的概率较小，一般是大型系统并且你是后面加入团队的时候会遇到。尤其是用户量大、涉及到交易业务的系统，错一点就会造成巨大资损。作为一个新人，加入这样的团队面临的挑战会比较大，如果没有文档，只能靠自己去问、去看、去 debug、去踩坑。

在业务架构的基础上，笔者提出业务能力地图的观点，如何让一个新人以最少的成本熟悉业务系统，除了业务系统设计得非常好，有详细的文档可参考外，还要有可视化的能力地图，从一个业务场景出发，中间涉及到的调用逻辑全部通过可视化界面展示出来，一个新人就可以很清晰地知道整个业务流程如何运转，先从宏观上理解产品、业务运转，再去看代码要轻松得多。

2.3 项目管理的难点

一个大型系统设计的业务方比较多，如果系统架构方案已经产出，剩下的就是落地执行，项目管理也有可能是我们的一个难点，如何协调资源、处理冲突、关键项目里程碑、问题跟踪和解决、上线灰度策略、业务监控…这些在系统架构设计时都要考虑到，并且在执行的过程中要有反馈。

一个项目如果没有人管理延期的风险会很大，其实大部分开发不善长做管理、沟通等事情，在一个组织里，不同的人、不同的事形成一个较复杂的环境，所以也有人说管理是一门艺术。

上面着重从技术、业务、项目三个层面讲解系统架构的难点，这些难点就是我们后面要解决的问题，反过来就是我们应该具备的基础。

三、换个思维看系统架构的过程

通过语文的阅读理解来类比领域建模的过程，有些读者反馈这种方式较好，通俗易懂，想起来好像还是那么一回事。笔者一直推崇的理念是大道至简，通过过往经验类比复杂的问题，有一个铺垫会降低学习的复杂度。

3.1 写作的过程

在这里依然用一个大家都熟知的经验来类比系统架构。我们从小都写作文，写作文的步骤是什么呢？

• 审题：根据要求写作。
• 谋篇布局：知道要写什么之后，就思考整体文章的结构是什么 (这个最关键，手法不同，文章的结构就不同，如总分总、设悬念、先抑后扬等)，分几段来写，每段的内容是什么，段与段的链接怎样。
• 素材选择：为了支撑表达我们的思想，素材有多个，如何选择最贴切的素材也是至关重要的。
• 写作：最后成文。

3.2 提炼写作的要点

所以到这里，不知道你发现了什么没，最关键的是什么？就是文章结构，这里的结构就体现出不同的逻辑，不同的人看后会有不同的感觉，有的文章读后为什么能让你拍案叫绝，就是他的行文思路非常好、剧情引人入胜。

可以换个角度来说：学好系统架构就如同写出一篇妙笔生花的文章出来。再来看如何写出一篇妙笔生花的文章出来的过程，我们大体在学生时代做了两件主要的事：

• 词汇语句的积累：积累了大量的词汇和经典语句，我们是从出生就开始积累。
• 文章结构：我们学习了大量的文章，分析文章的结构就是为了让我们学习这种结构。

至此，写作的核心要点就两个：词汇语句和文章结构。那么类比到架构设计，其实已经快呼出之出了，先等一下，我们对这两个点再抽象一下。词汇语句抽象了要素，文章结构抽象成模式。再来看系统架构，它的核心点也是上面两种：

• 要素：解决问题的点和具体手段，如技术架构中的缓存、消息队列等。
• 模式：就是最终呈现的结构，常见的有分层架构模式、管道模式、代理模式、事件模式等。

通过写作类比，应对系统架构的方法已经初步成型，接下来再细细道来。

四、应对系统架构的方法

本部分应该是最重要的，但经过前面的铺垫，现在显得并不是特别重要，因为不同的人看到这里，心里的想法肯定不一样。

应对系统架构的方法：系统性思考、分解、抽象、模式。

• 系统性思考：我们考虑的目标是系统，不是单一的点，所以要系统性思考。这个听起来比较虚，还是拿一个技术架构中的秒杀场景来说明。秒杀的本质是有限的资源应对大量的请求，解决这个问题资源肯定不能加大，就 100 个商品，不可能加到 10000 个商品。所以怎么应对大量的请求就是解决问题的关键点，我们可以直接从两个方面来考虑：用户和系统两个角度。用户大量的请求直接涌入，系统可能承担不住，能不能打散用户请求？系统方面能不能更快的处理用户请求，之前要 100ms 处理完的，能不能用 10ms 处理完？所以这样分析下来，从接入层、处理层、存储层考虑，而不是单一考量。

• 分解：一个复杂的问题分而治之是一个宝贵的经验，同样在系统架构中也经常使用到，还是拿上面的例子继续说，上面从用户和系统两个角度考虑，那么从用户角度如何去做？从系统角度又该怎么去做，两个独立的可以单独拿出来设计。技术架构可以按照这种方法来做，业务架构也会使用分解的方法，业务流程的分解，分解出更小的流程，从流程中找出产物是什么。

• 抽象：抽象这个词本身就很抽象，经常说就不知道它是什么，笔者对抽象的理解就是抽出来要像，如人在医院中重要的是身份信息 + 健康信息，在学校中重要的是身份信息 + 成绩信息，在工作中重要的是身份信息 + 工作经验 +KPI，所以不同的场景要抽象出本质的东西来描述事物。那么复杂的一个系统，要抓住核心的点，可能核心点不超过 10 个，这样就大大降低理解的复杂度了。

• 模式：好比写作一样，有不同的模式，架构设计也有不同的模式，这种模式是约定俗成的，一看就能理解，常见的是分层架构模式，一些比较少用的模式了解即可，把重要的精力花在常见的模式上，遵循二八原则。

再来看我们之前对系统架构的定义： 系统架构 = 解决特定的问题 + 连接 + 要素，现在再去看它，会显得特别亲切，用一句话概括系统架构的方法：明确我们要解决的问题，通过系统化的思考方式找到关键的点，对不同的关键点进行分而治之，再通过抽象找出要素，最后通过一定的模式表现出来。

结论二：应对系统架构的方法：系统性思考、分解、抽象、模式。

from  https://www.infoq.cn/article/NON4ahRV9pC3Feoc0-VC

https://www.infoq.cn/article/fwhQ-dIN2xTUH6zNLYZp